このトピックでは、ApsaraDB RDS for MySQLインスタンスのメモリ消費の問題をトラブルシューティングする方法について説明します。
背景情報
メモリ使用量とバッファプールヒット率は、RDSインスタンスの全体的なメモリ消費量を測定するために使用される2つの重要な指標です。 メモリ使用量が多すぎると、メモリ枯渇の危険が生じる。 バッファプールヒット率が異常に低い場合、要求された多数のデータページをバッファプールでヒットすることはできません。 その結果、ApsaraDB RDSはディスクからデータを読み取る必要があります。 これにより、I/O操作とクエリの待ち時間が増加します。
メモリ消費量の表示
ApsaraDB RDSコンソールには、メモリ消費量の表示に使用できるさまざまな方法があります。
モニタリングとアラート
左側のナビゲーションウィンドウで [モニタリングとアラート] をクリックします。 表示されるページで、[標準モニタリング] タブをクリックして、[MySQL CPU使用率 /メモリ使用率] および [InnoDBバッファプールヒット率] メトリックを表示します。
Database Autonomy Service (DAS)
左側のナビゲーションウィンドウで、 を選択します。 表示されるページで、[パフォーマンストレンド] タブをクリックします。 次に、MySQL CPU使用率 /メモリ使用率とInnoDBバッファプールヒット率のメトリクスを表示できます。
PERFORMANCE_SCHEMAストレージエンジンを使用して、メモリ機器を構成することもできます。 これにより、メモリ使用量の統計をメモリサマリテーブルに集約できます。 詳細については、「MySQLドキュメント」をご参照ください。
RDSインスタンスの起動時にメモリモニタリングを有効にする場合、インスタンスがMySQL 5.6を実行している場合はperformance_schemaパラメーターをONに設定し、インスタンスがMySQL 5.7またはMySQL 8.0を実行している場合は1に設定します。 詳細については、「ApsaraDB RDS For MySQLインスタンスのパラメーターの表示」をご参照ください。 次に、RDSインスタンスを再起動して、設定を有効にします。
RDSインスタンスの実行中にメモリモニタリングを有効にする場合は、次のコマンドを実行します。
更新performance_schema.setup_instruments set enabled = 'yes 'ここで名前は '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テーブルは、指定されたイベント名に一致するイベントを提供します。
メモリ使用量が過度に多い一般的な理由
通常、InnoDBバッファプールはほとんどのメモリを消費します。 バッファプールで消費できる最大メモリは、バッファプールのパラメーター設定によって異なります。 さらに、メモリの大部分は、要求が処理されているときに動的に割り当てられ、調整される。 メモリ消費には、インメモリ一時テーブル、プリフェッチキャッシュ、テーブルキャッシュ、ハッシュインデックス、および行ロックオブジェクトによって消費されるメモリが含まれます。 メモリ使用量とパラメーター制限の詳細については、「MySQLによるメモリの使用方法」をご参照ください。
複数文クエリMulti-statement queries
MySQLでは、複数のSQL文を1つのクエリに結合できます。 これらのSQL文は、クエリ内でセミコロン (;) で区切られ、一度にMySQLに送信されます。 MySQLはこれらのSQL文を1つずつ処理します。 ただし、一部のメモリは、これらのSQL文がすべて実行された後にのみ解放されます。
一度に大量のSQL文を送信すると、これらのSQL文を実行するためにさまざまなオブジェクトが消費する累積メモリが大幅に増加します。 増加は数百MBに達することができます。 これは、MySQLプロセスのために利用可能なメモリを使い果たし得る。
通常、一度に大量のSQL文が送信された場合、モニタリングおよびアラート機能またはSQL Explorer機能を使用して、ネットワークトラフィックの突然の増加を検出できます。 複数ステートメントクエリを実行しないことを推奨します。
バッファプールの問題
すべてのテーブルのデータページがバッファプールに格納されます。 要求されたデータページがバッファプール内でヒットした場合、システムは物理I/O操作を実行しません。 この場合、システムはSQL文を高速に実行します。 さらに、バッファプールは、最長時間未使用 (LRU) キャッシングアルゴリズムを使用して、データページを管理する。 このアルゴリズムにより、バッファプールはすべてのダーティページをフラッシュリストに格納できます。
InnoDBバッファプールのデフォルトサイズは、RDSインスタンスが提供するメモリ容量の75% に設定されています。
バッファプールに関連する次の一般的な問題が発生する可能性があります。
データページは、十分に予熱されていない。 これにより、クエリの待ち時間が増加します。 RDSインスタンスを再起動したり、コールドデータを読み取ったり、バッファプールヒット率が低い場合、この問題が発生する可能性があります。 RDSインスタンスをアップグレードするか、販売促進を開始する前に、データページを十分に事前ウォームアップすることをお勧めします。
過剰な汚れたページが蓄積されます。 たとえば、ダーティページは長期間更新されていません。 この場合、ダーティページの最も早いログシーケンス番号 (LSN) と現在のログシーケンス番号 (LSN) との差が76% を超える場合、ユーザスレッドは、ダーティページを同期的に更新するようにトリガされる。 これにより、RDSインスタンスのパフォーマンスが大幅に低下します。 この問題を解決するには、書き込み負荷のバランスを取り、書き込み操作のスループットが高すぎるのを防ぎ、ダーティページの更新方法を指定するパラメーターを再設定し、RDSインスタンスをアップグレードします。
RDSインスタンスは大容量のメモリを提供します。 ただし、RDSインスタンスのinnodb_buffer_pool_instancesパラメーターは小さな値に設定されています。 この場合、QPSが高い場合、バッファプール内のロックの激しい競合が発生します。 innodb_buffer_pool_instancesパラメーターを8、16、またはそれ以上の値に設定することを推奨します。
一時的なテーブルの問題
メモリ内の一時テーブルサイズは、tmp_table_sizeおよびmax_heap_table_sizeパラメーターによって制限されます。 メモリ内一時テーブルのサイズが制限を超えた場合、メモリ内一時テーブルはディスク上一時テーブルに変換されます。 多数の接続で多数の一時テーブルが作成されると、RDSインスタンスのメモリ使用量が突然増加します。 MySQL 8.0は新しいTempTableエンジンを提供します。 このエンジンは、すべてのスレッドによって作成されるメモリ内一時テーブルの合計サイズがtemptable_max_ramパラメーターの値より小さくなければならないことを指定します。 temptable_max_ramのデフォルト値は1 GBです。 合計サイズがこのパラメーターの値を超える場合、以前のメモリ内一時テーブルはディスク上一時テーブルに変換されます。
その他の問題
RDSインスタンスに作成されたテーブルの数が多すぎる場合、またはQPSが多い場合、テーブルキャッシュは特定のメモリ量を消費する可能性があります。 多数のテーブルを作成したり、table_open_cacheパラメーターを大きな値に設定したりしないことを推奨します。
アダプティブハッシュインデックスのデフォルトのメモリ消費量は、バッファプールサイズの1/64に設定されます。 バイナリラージオブジェクト (BLOB) データ型の大きなフィールドを照会または書き込むと、メモリはこれらの大きなフィールドに動的に割り当てられます。 これにより、RDSインスタンスのメモリ使用量も増加します。
RDSインスタンスのメモリ使用量は、他の多くの問題により増加する可能性があります。 メモリ使用量が異常に増加した場合、またはメモリが使い果たされた場合は、MySQLドキュメントに記載されている手順に従って問題をトラブルシューティングできます。