このトピックでは、メモリ使用量の表示方法と、一般的なメモリ問題の原因および解決策について説明します。
背景情報
メモリ使用量とバッファープールヒット率は、ApsaraDB RDS for MySQL インスタンスの重要なメトリクスです。高いメモリ使用量はメモリ枯渇につながる可能性があります。バッファープールヒット率が低い場合、多くのデータページがバッファープール内で見つからず、ディスクから読み取る必要があります。これにより、I/O スループットとレイテンシーが増加します。
メモリ使用量の表示
RDS 管理コンソールでは、いくつかの方法でアクティブなスレッドを表示できます：
モニタリングとアラート
コンソールで、[監視とアラート] ページに移動します。[標準モニタリング] タブで、インスタンスの [MySQL CPU/メモリ使用率] と [InnoDB バッファープールヒット率] を表示できます。
Database Autonomy Service (DAS)
コンソールで、 ページに移動します。[パフォーマンストレンド] タブをクリックして、[MySQL CPU/メモリ使用率] と [InnoDB バッファープールヒット率] を表示します。
また、performance_schema を使用してメモリーインストゥルメントを設定することもできます。これにより、メモリーサマリーテーブルでメモリ使用量の統計情報を表示できます。詳細については、「MySQL の公式ドキュメント」をご参照ください。
メモリモニタリングを有効にするには、コンソールで performance_schema パラメーターを変更します。RDS for MySQL 5.6 の場合は ON に、RDS for MySQL 5.7 および 8.0 の場合は 1 に設定します。詳細については、「インスタンスパラメーターの表示」をご参照ください。変更を有効にするには、インスタンスを再起動します。
インスタンスの実行中にメモリ監視を有効にするには、次のコマンドを実行します。
update performance_schema.setup_instruments set enabled = 'yes' where name like 'memory%';
以下のテーブルは、さまざまなディメンションごとのメモリ消費量をまとめたものです。
memory_summary_by_account_by_event_name：アカウント (ユーザーとホストの組み合わせ) とイベント名別にイベントを集計します。
memory_summary_by_host_by_event_name：ホストとイベント名別にイベントを集計します。
memory_summary_by_thread_by_event_name：スレッドとイベント名別にイベントを集計します。
memory_summary_by_user_by_event_name：ユーザーとイベント名別にイベントを集計します。
memory_summary_global_by_event_name：イベント名別にイベントを集計します。
RDS for MySQL でメモリ使用量が高くなる一般的な原因
通常、InnoDB バッファープールが最も多くのメモリを消費します。バッファープールの最大メモリ使用量は、設定パラメーターによって制限されます。しかし、リクエストの実行中には、かなりの量のメモリが動的に割り当てられ、調整されます。これには、インメモリ一時テーブル、プリフェッチキャッシュ、テーブルキャッシュ、ハッシュインデックス、および行ロックオブジェクト用のメモリが含まれます。メモリ使用量とパラメーターの制限に関する詳細については、「MySQL の公式ドキュメント」をご参照ください。
複数ステートメントクエリ
MySQL では、セミコロン (;) で区切られた複数の SQL ステートメントをまとめて送信できます。MySQL は各 SQL ステートメントを順次処理します。ただし、割り当てられたメモリの一部は、すべての SQL ステートメントの実行が完了した後にのみ解放されます。
一度に多くの複数ステートメントクエリ (たとえば、数百メガバイト) を送信すると、実行中にさまざまなオブジェクトによって消費される累積メモリが非常に大きくなる可能性があります。これにより、MySQL プロセスはメモリが枯渇しやすくなります。
通常、大量の複数ステートメントクエリは、ネットワークトラフィックの急激な増加を引き起こします。ネットワークトラフィックの監視と SQL Explorer を使用して、このパターンを確認できます。アプリケーションロジックで複数ステートメントクエリを使用することは避けてください。
バッファープールの問題
テーブルのすべてのデータページはバッファープールに格納されます。クエリが実行されるとき、必要なデータページがバッファープールで見つかれば、物理的な I/O は発生しません。これにより、SQL を効率的に実行できます。バッファープールは、データページの管理に LRU (Least Recently Used) アルゴリズムを使用します。すべてのダーティページはフラッシュリストに配置されます。
デフォルトでは、RDS for MySQL の InnoDB バッファープールのサイズは、インスタンスのメモリの 75% に設定されています。これは通常、インスタンスが消費するメモリの大部分を占めます。
バッファープールに関連する一般的な問題：
データページの事前ウォーミングが不十分な場合、クエリのレイテンシーが高くなる可能性があります。この問題は、インスタンスの再起動後、コールドデータの読み取り時、またはバッファープールヒット率が低い場合によく発生します。これを解決するには、インスタンスタイプをアップグレードするか、販促キャンペーンの前にデータを事前にウォームアップします。
ダーティページの過剰な蓄積。フラッシュされていないダーティページの最も古いログシーケンス番号 (LSN) と現在の LSN の間の距離が 76% を超えると、ユーザースレッドがトリガーされてダーティページを同期およびフラッシュします。これにより、インスタンスのパフォーマンスが著しく低下します。最適化するには、書き込み負荷を分散し、過度に高い書き込みスループットを避け、ダーティページのフラッシュパラメーターを調整するか、インスタンスタイプをアップグレードしてください。
高メモリインスタンスでは、innodb_buffer_pool_instances パラメーターの設定値が低すぎます。QPS 負荷が高い場合、バッファープールでのロック競合が激しくなる可能性があります。高メモリインスタンスの場合は、innodb_buffer_pool_instances パラメーターを 8、16、またはそれ以上に設定します。
一時テーブル
メモリ内一時テーブルのサイズは、tmp_table_size および max_heap_table_size パラメーターによって制限されます。テーブルがこれらの制限を超えると、ディスク一時テーブルに変換されます。多くの接続が同時に大きな一時テーブルを作成すると、急激なメモリ使用量の増加を引き起こす可能性があります。MySQL 8.0 では、新しい temptable エンジンが導入されました。すべてのスレッドによって割り当てられたすべてのメモリ内一時テーブルの合計サイズは、temptable_max_ram パラメーターの値を超えることはできません。temptable_max_ram のデフォルト値は 1 GB です。この制限を超えると、テーブルはディスク一時テーブルに変換されます。
その他の原因
インスタンスのテーブル数が多い場合や QPS が高い場合、テーブルキャッシュも大量のメモリを消費する可能性があります。インスタンスにテーブルを作成しすぎたり、table_open_cache パラメーターを高く設定しすぎたりすることは避けてください。
適応型ハッシュインデックスが使用するメモリは、デフォルトでバッファープールサイズの 1/64 です。非常に大きな BLOB (バイナリラージオブジェクト) フィールドをクエリまたは書き込みする場合、これらの大きなオブジェクト用にメモリが動的に割り当てられ、全体のメモリ使用量が増加します。
その他にも、メモリ使用量が増加する原因となる問題は多数あります。メモリ使用量が異常に増加したり、インスタンスでメモリ不足が発生したりした場合は、「MySQL の公式ドキュメント」を参照して原因を特定してください。