このトピックでは、ApsaraDB RDS for MySQLインスタンスでアクティブなスレッドの数が過剰になる問題をトラブルシューティングする方法について説明します。
背景情報
アクティブなスレッドの数またはアクティブな接続の数は、RDSインスタンスの負荷を測定するために使用される重要な指標です。 ほとんどの場合、正常なRDSインスタンス上のアクティブなスレッドまたは接続の数は10未満です。 RDSインスタンスが高い仕様と高い1秒あたりのクエリ数 (QPS) を提供する場合、その数は20または30に増加する可能性があります。 この数が100 1,000を超えると、SQLクエリのパイルアップにより、RDSインスタンスがクエリに応答する速度が遅くなります。 重大なケースでは、RDSインスタンスは応答せず、SQLクエリの処理を停止します。
アクティブなスレッドの数を表示する
ApsaraDB RDSコンソールにログインし、次のいずれかの方法を使用して、アクティブなスレッド数を表示できます。
モニタリングとアラート
左側のナビゲーションウィンドウで [モニタリングとアラート] をクリックします。 表示されるページの [標準モニタリング] タブで、[標準ビュー] をクリックして、アクティブなスレッドの数を表示します。
DAS
左側のナビゲーションウィンドウで、 を選択します。 表示されるページで、[パフォーマンストレンド] タブをクリックして、アクティブなスレッドの数を表示します。 数が大きすぎると、一部のセッションがブロックされます。
積み上げられた低速SQLクエリのトラブルシューティング
現象
アクティブなスレッドの数が増えた場合は、
SHOW PROCESSLIST文を実行して、低速SQLクエリが存在するかどうかを確認できます。 大量のSQLクエリでApsaraDB RDSが過度に多数の行をスキャンする必要がある場合、アクティブなスレッドの数が増加する可能性があります。低速SQLクエリに関する情報を表示するには、 を選択します。
解決策
SQLスロットリング機能を有効にするか、セッションを終了します。 これにより、低速SQLクエリの影響が軽減されます。 詳細については、「SQLスロットリング」をご参照ください。
テーブルキャッシュの問題のトラブルシューティング
現象
RDSインスタンスで過度に高いQPSが発生したり、多数のテーブルを処理したりすると、テーブルキャッシュのサイズが不十分なため、多数のSQLクエリが
[テーブルを開く]状態に切り替わります。解決策
table_open_cacheおよびtable_open_cache_instancesパラメーターの値を増やします。 table_open_cacheパラメーターの再構成では、RDSインスタンスの再起動は必要ありません。 ただし、table_open_cache_instancesパラメーターを再構成するには、RDSインスタンスの再起動が必要です。
メタデータロックの問題のトラブルシューティング
現象
準備フェーズとコミットフェーズでは、DDL文はテーブルのメタデータロックを取得する必要があります。 テーブルがコミットされていないトランザクションまたは低速SQLクエリに関与している場合、DDLステートメントはブロックされます。 これにより、より多くのSQLクエリがブロックされます。 ブロックされたすべてのSQLクエリは、
[Waiting for table metadata lock]状態に切り替わります。 その結果、アクティブなスレッドの数が増加する。解決策
コミットされていないすべてのトランザクション、低速SQLクエリ、および進行中のDDLステートメントを中止します。
行ロックの競合のトラブルシューティング
現象
Innodb_row_lock_waitsおよびInnodb_row_lock_timeメトリックの値が大きい場合、行ロックの競合が発生する可能性があります。
左側のナビゲーションウィンドウで、 を選択します。 表示されるページで、[パフォーマンストレンド] タブをクリックします。 次に、[行のロック] セクションでメトリックを表示できます。
解決策
SHOW ENGINE INNODB STATUS;ステートメントを実行して、多数のセッションがロック待機状態にあるかどうかを確認します。 多数のセッションがロック待機状態にある場合、重大な行ロックの競合が発生します。 この場合、推奨されるすべてのメソッドを使用して行ロックの競合を軽減します。 たとえば、ホットデータの更新を最適化し、トランザクションサイズを縮小し、トランザクションのコミットに必要な時間を短縮できます。