ApsaraDB RDS for MySQL インスタンスにおける高 I/O は、通常、高スループット、一時テーブル、コールドデータの読み取り、DDL ステートメント、大規模トランザクションのバイナリログ書き込みという 5 つの根本原因に起因します。このガイドを参考に原因を特定し、的を絞った対策を講じてください。
一般的な原因の概要
| 原因 | コンソールでの確認場所 | 主要な指標 |
|---|---|---|
| 高スループット | [Autonomy Service] > [Dashboard] > [Performance Trends] | 読み取り/書き込み負荷 |
| 一時テーブル | [Autonomy Service] > [Dashboard] > [Performance Trends] | tmp ディレクトリのサイズ |
| コールドデータの読み取り | [Autonomy Service] > [Dashboard] > [Performance Trends] | バッファープールヒット率 |
| DDL ステートメント | [Monitoring and Alerts] > [Standard Monitoring] > [Standard View] | ディスク使用率と IOPS |
| 大規模トランザクションのバイナリログ書き込み | — | バイナリログ量の急激な増加 |
InnoDB による I/O の処理方法
InnoDB は、独立した I/O システムを使用してデータページを読み書きします。SQL ステートメントがバッファープールにないデータページを要求すると、InnoDB は同期 I/O を使用してディスクからそのページを読み取ります。バックグラウンドスレッドは、非同期 I/O を使用してダーティページをディスクにフラッシュします。
データファイルの I/O に加えて、redo ログの書き込み、undo ログの書き込み、バイナリログの書き込み、一時テーブルのソート、DDL によるテーブルスペースの再構築など、他のいくつかの操作によっても I/O が大幅に増加する可能性があります。以下に示す 5 つの原因は、それぞれこれらのメカニズムの 1 つ以上に関連しています。
高スループットに起因する高 I/O のトラブルシューティング
症状
インデックスが多い、またはフィールドが大きいテーブルに対して UPDATE、DELETE、INSERT 操作が頻繁に行われると、2 つの要因で I/O が増加します。まず、RDS はデータページをバッファープールに読み込みます。次に、バックグラウンドスレッドが、結果として生じたダーティページをディスクにフラッシュします。この読み取りと書き込みの複合的な負荷により、I/O が増加します。
確認するには、ApsaraDB RDS コンソールの左側のナビゲーションペインで [Autonomy Service] > [Dashboard] に移動し、[Performance Trends] タブを開いて、読み取り/書き込み負荷のメトリクスを確認します。
解決策
読み取り/書き込みの頻度を減らすか、インスタンスタイプをアップグレードするか、ダーティページのフラッシュを制御するパラメーターを調整してください。
| パラメーター | デフォルト | 説明 |
|---|---|---|
innodb_max_dirty_pages_pct |
75 | バッファープールで許可されるダーティページの最大割合 |
innodb_max_dirty_pages_pct_lwm |
0 (無効) | ダーティページの下限基準値。この値を超えると、RDS はバッファープールの空き容量を確保するためにダーティページを積極的にフラッシュします。 |
innodb_io_capacity |
20000 | InnoDB のバックグラウンドタスクで利用可能な 1 秒あたりの最大 I/O 操作数。ダーティページのフラッシュとバッファープールの書き込み速度を制御します。 |
innodb_io_capacity_max |
40000 | 1 秒あたりの I/O 操作数の上限。ダーティページのフラッシュが遅延した場合にのみ有効になります。innodb_io_capacity より大きい値にする必要があります。 |
innodb_max_dirty_pages_pct_lwm は innodb_max_dirty_pages_pct 以下である必要があります。より高い値を設定した場合、RDS は自動的に innodb_max_dirty_pages_pct の値にリセットします。
一時テーブルに起因する高 I/O のトラブルシューティング
症状
ソートや重複排除を伴う低速な SQL ステートメント (スロークエリ) は、InnoDB がディスク上に大規模な一時テーブルを作成する原因となります。これらの一時テーブルの作成と書き込みの両方で I/O が増加します。tmp ディレクトリのサイズが大きいことは、信頼できる指標です。
確認するには、ApsaraDB RDS コンソールの左側のナビゲーションペインで [Autonomy Service] > [Dashboard] に移動し、[Performance Trends] タブを開いて、tmp ディレクトリのサイズを確認します。
解決策
一時テーブルを生成する SQL ステートメントを最適化してください。Database Autonomy Service (DAS) は、スロークエリを特定して修正するのに役立つ組み込みの SQL 最適化機能を提供します。詳細については、「SQL 最適化」をご参照ください。
コールドデータの読み取りに起因する高 I/O のトラブルシューティング
症状
クエリまたは DML ステートメントが必要とするデータページがバッファープールにない場合、InnoDB はディスクからそれらを読み取ります。バッファープールヒット率が低いと、ほとんどのリクエストがディスクにアクセスすることになり、I/O が大幅に増加します。
確認するには、ApsaraDB RDS コンソールの左側のナビゲーションペインで [Autonomy Service] > [Dashboard] に移動し、[Performance Trends] タブを開いて、バッファープールヒット率を確認します。
解決策
ワークロードのアクセスパターンに基づいてキャッシュ戦略を再設計するか、RDS インスタンスをアップグレードしてください。
DDL ステートメントに起因する高 I/O のトラブルシューティング
症状
DDL ステートメントは、テーブルスペース全体の再構築をトリガーします。InnoDB は、すべての行をスキャンし、ソートインデックスを作成し、新しいテーブル構造のためにダーティページをフラッシュします。大規模なテーブルの削除も、大量の I/O を発生させます。これらの操作は、ディスク使用率と IOPS の両方で急激なスパイクを引き起こす可能性があります。
確認するには、ApsaraDB RDS コンソールの左側のナビゲーションペインで [Monitoring and Alerts] に移動し、[Standard Monitoring] タブの [Standard View] をクリックして、ディスク使用率と IOPS を確認します。
解決策
大容量ファイルの非同期パージ機能を使用すると、I/O をブロックせずに大容量ファイルを削除できます。この機能は、Alibaba Cloud の MySQL ブランチである AliSQL の一部です。詳細については、「大容量ファイルの非同期パージ」をご参照ください。
大規模トランザクションによるバイナリログ書き込みに起因する高 I/O のトラブルシューティング
症状
InnoDB は、トランザクションのコミット時にのみバイナリログファイルに書き込みます。たとえば、多数の行を削除する DELETE のような単一の大きなトランザクションでは、数十 GB ものバイナリログデータが生成されることがあります。この大量のデータを一度にディスクにフラッシュすると、急激な I/O スパイクが発生します。
解決策
大規模なトランザクションをより小さなバッチに分割してください。コミットを小さくすることで、バイナリログのフラッシュが時間的に分散され、ダーティページのディスクへのフラッシュが平滑化され、単一の大きなコミットによって生じるバースト的な I/O を防ぐことができます。