すべてのプロダクト
Search
ドキュメントセンター

ApsaraDB RDS:ApsaraDB RDS for MySQLインスタンスで高I/Oを引き起こす問題のトラブルシューティング

最終更新日:Jan 18, 2024

このトピックでは、ApsaraDB RDS for MySQLインスタンスで高I/Oを引き起こす問題のトラブルシューティング方法について説明します。 RDSインスタンスのI/Oパフォーマンスは、ストレージタイプ、カーネルアーキテクチャ、およびデータをスキャンまたは変更するために実行されるSQL文によって異なります。

高スループットによる高I/Oのトラブルシューティング

  • 現象

    アプリケーションがテーブルのデータの更新、削除、および挿入のリクエストを頻繁に開始すると、データの読み取りとダーティページのフラッシュにより、RDSインスタンスのI/Oが大幅に増加します。 これは、テーブルに多数のインデックスまたは大きなフィールドが含まれている場合に適用されます。

    ApsaraDB RDSコンソールにログインし、左側のナビゲーションウィンドウで [Autonomy Service] > [ダッシュボード] を選択します。 次に、[パフォーマンストレンド] タブで、RDSインスタンスの読み取り負荷と書き込み負荷を表示できます。

  • 解決策

    読み書きの頻度を減らすか、RDSインスタンスのインスタンスタイプをアップグレードするか、ダーティページのフラッシュに使用されるパラメーターの設定を最適化することを推奨します。 次のリストに、ダーティページのフラッシュに使用されるパラメーターを示します。

    • innodb_max_dirty_pages_pct: バッファプールで許可されているダーティページの割合。 デフォルト値: 75。

    • innodb_max_dirty_pages_lwm: バッファプールで許可されているダーティページの割合の下限値。 バッファプール内のダーティページの割合が下限値を超えた場合、ApsaraDB RDSはダーティページをディスクにフラッシュします。 これにより、バッファプール内のダーティページの適切な割合が保証されます。 デフォルト値0は、低水位マークを無効にすることを指定します。

      説明

      innodb_max_dirty_pages_pct_lwmパラメーターの値は、innodb_max_dirty_pages_pctパラメーターの値以下である必要があります。 それ以外の場合、ApsaraDB RDSは、innodb_max_dirty_pages_pct_lwmパラメーターをinnodb_max_dirty_pages_pctパラメーターの値に設定します。

    • innodb_io_capacity: 各バックグラウンドタスクの1秒あたりにInnoDBが許可するI/O操作の最大数。 このパラメーターの値は、ApsaraDB RDSがダーティページをディスクにフラッシュする速度に影響します。 このパラメーターの値は、ApsaraDB RDSがバッファプールにデータを書き込む速度にも影響します。 デフォルト値: 20000

    • innodb_io_capacity_max: 各バックグラウンドタスクの1秒あたりにInnoDBが許可するI/O操作の最大数。 このパラメータは、ダーティページのフラッシュが古い場合にのみ有効になります。 このパラメーターの値は、innodb_io_capacityパラメーターの値よりも大きくなっています。 デフォルト値: 40000

一時的なテーブルによって引き起こされる高いI/Oのトラブルシューティング

  • 現象

    一時ディレクトリが大きい場合、低速SQLステートメントのソートや重複排除などの操作により、ApsaraDB RDSが大きな一時テーブルを作成している可能性があります。 これにより、RDSインスタンスのI/Oが増加します。 さらに、一時テーブルへのデータ書き込みによって、RDSインスタンスのI/Oも増加します。

    ApsaraDB RDSコンソールにログインし、左側のナビゲーションウィンドウで [Autonomy Service] > [ダッシュボード] を選択します。 次に、[パフォーマンストレンド] タブで、RDSインスタンスのtmpまたはその他のディレクトリのサイズを表示できます。

  • 解決策

    実行するSQL文を最適化することを推奨します。 これにより、低速なSQL文を防ぐことができます。 Database Autonomy Service (DAS) はSQL最適化をサポートしています。 詳細については、「SQLの最適化」をご参照ください。

コールドデータ読み取りによる高いI/Oのトラブルシューティング

  • 現象

    SQL文を使用して照会または変更されたデータがバッファプールでヒットできない場合、ApsaraDB RDSはディスクからデータを読み取る必要があります。 これにより、RDSインスタンスのI/Oが大幅に増加する可能性があります。

    ApsaraDB RDSコンソールにログインし、左側のナビゲーションウィンドウで [Autonomy Service] > [ダッシュボード] を選択します。 次に、[パフォーマンストレンド] タブで、RDSインスタンスのバッファプールヒット率を表示できます。

  • 解決策

    ビジネスシナリオに基づいてキャッシュポリシーを再設計します。 それ以外の場合は、RDSインスタンスをアップグレードします。

DDLステートメントによる高I/Oのトラブルシューティング

  • 現象

    アプリケーションがDDLステートメントを開始すると、ApsaraDB RDSはRDSインスタンスのテーブルスペースを再構築できます。 再構築プロセス中、ApsaraDB RDSはテーブルスペース内の各テーブルの各行をスキャンし、データのソートに使用されるインデックスを作成し、新しいテーブルから生成されたダーティページをフラッシュします。 これらの操作はすべて、RDSインスタンスのI/Oを大幅に増加させます。 アプリケーションが大きなテーブルを削除するリクエストを開始すると、RDSインスタンスのI/Oも増加する可能性があります。

    ApsaraDB RDSコンソールにログインし、左側のナビゲーションウィンドウで [モニタリングとアラート] をクリックします。 次に、[標準モニタリング] タブの [標準ビュー] をクリックして、RDSインスタンスのディスク使用量とIOPSを表示します。

  • 解決策

    大きなファイルを非同期的にパージする機能を使用して、大きなファイルを削除します。 この機能はAliSQLによって提供されます。 AliSQLは、Alibaba Cloudによって開発されたMySQLブランチです。 詳細については、「大きなファイルを非同期的にパージする」をご参照ください。

大規模なトランザクションからのバイナリログ書き込みによる高I/Oのトラブルシューティング

  • 現象

    トランザクションは、コミットされた場合にのみ、ログレコードをバイナリログファイルに書き込みます。 アプリケーションが大規模なトランザクションを実行する場合、トランザクションは数十GBのデータをバイナリログファイルに書き込む可能性があります。 たとえば、トランザクションには、多数の行を削除するために使用されるDELETEステートメントが含まれています。 これらのバイナリログファイルがディスクにフラッシュされると、RDSインスタンスのI/Oが大幅に増加します。

  • 解決策

    実行する大規模なトランザクションを分割することを推奨します。 これにより、汚れたページのディスクへのフラッシュを減らすことができます。

付録: InnoDB I/Oシステムの概要

InnoDBは、独立したI/Oシステムを使用してデータページを読み書きします。 SQL文によって要求されたデータページがバッファプールでヒットできない場合、物理I/O操作が実行され、ディスクにデータが読み書きされます。

  • データページの読み取り操作

    基礎となる読み出し動作は、データページを読み出すための同期I/Oに基づいて呼び出される。

  • データページの書き込み操作

    例として、汚れたページのフラッシュを使用します。 バックグラウンドI/Oスレッドは、非同期I/Oに基づいて呼び出され、ダーティページをディスクに非同期にフラッシュします。

一般的なデータファイルに対するI/O操作に加えて、他の多くの操作もRDSインスタンスのI/Oを大幅に増加させる可能性があります。 これらの操作には、redoログ、undoログ、およびバイナリログの書き込み操作、一時テーブルをソートする操作、およびDDLステートメントによるテーブルスペースを再構築する操作が含まれます。