io/aurora_respond_to_client - Amazon Aurora
サポート対象エンジンバージョンContext待ち時間増加の考えられる原因アクション

io/aurora_respond_to_client

io/aurora_respond_to_client イベントは、スレッドが結果セットをクライアントに返すのを待っているときに発生します。

サポート対象エンジンバージョン

この待機イベント情報は、以下のエンジンバージョンでサポートされています。

  • Aurora MySQL バージョン 2

バージョン 2.07.7、2.09.3、2.10.2 より前のバージョンでは、この待機イベントにアイドル時間が誤って含まれます。

Context

io/aurora_respond_to_client イベントは、スレッドが結果セットをクライアントに返すのを待っているときに発生します。

クエリの処理が完了し、結果はアプリケーションクライアントに返されます。ただし、DB クラスターには十分なネットワーク帯域幅がないため、スレッドは結果セットを返すのを待っています。

待ち時間増加の考えられる原因

io/aurora_respond_to_client イベントが通常よりも多く表示され、パフォーマンスの問題を示している可能性がある場合、典型的な原因は次のとおりです。

DB インスタンスクラスがワークロードに対して不十分

DB クラスターで使用される DB インスタンスクラスには、ワークロードを効率的に処理するために必要なネットワーク帯域幅がありません。

大きな結果セット

クエリがより多くの行数を返すため、返される結果セットのサイズが増加しました。結果セットが大きいほど、より多くのネットワーク帯域幅を消費します。

クライアントへの負荷の増加

クライアントに CPU プレッシャー、メモリプレッシャー、またはネットワークの飽和が発生する可能性があります。クライアントの負荷が増加すると、Aurora MySQL DB クラスターからのデータの受信が遅れます。

ネットワークレイテンシーの増加

Aurora MySQL DB クラスターとクライアント間のネットワークレイテンシーが増加することがあります。ネットワークレイテンシーが大きいほど、クライアントがデータを受信するのに必要な時間が長くなります。

アクション

待機イベントの原因に応じたさまざまなアクションをお勧めします。

イベントの原因となるセッションとクエリを特定する

Performance Insights を使用して、io/aurora_respond_to_client 待機イベントによってブロックされたクエリを表示できます。通常、ロードが中程度から重大なデータベースには、待機イベントがあります。パフォーマンスが最適であれば、待機イベントは受け入れられる可能性があります。パフォーマンスが最適でない場合は、データベースが最も長い時間を費やしている場所を調べます。最も高いロードに寄与する待機イベントを調べて、データベースとアプリケーションを最適化してこれらのイベントを削減できるかどうかを調べます。

高ロードの原因となる SQL クエリを検索するには

  1. AWS Management Console にサインインし、Amazon RDS コンソール (https://console.aws.amazon.com/rds/) を開きます。

  2. ナビゲーションペインで、[Performance Insights] を選択します。

  3. DB インスタンスを選択します。その DB インスタンスの Performance Insights ダッシュボードが表示されます。

  4. データベースロードで、待機でスライスを選択します。

  5. ページの下部で トップ SQL を選択します。

    グラフには、ロードの原因となる SQL クエリがリストされます。リスト上部にあるクエリに、最も責任があります。ボトルネックを解決するには、これらのステートメントに注目してください。

Performance Insights を使用したトラブルシューティングの便利な概要については、AWS　データベースブログ記事の Performance Insights を使用した Amazon Aurora MySQL ワークロードの分析を参照してください。

DB インスタンスクラスのスケール

NetworkReceiveThroughput や NetworkTransmitThroughput などのネットワークスループットに関連する Amazon CloudWatch メトリクスの値の増加を確認します。DB インスタンスクラスのネットワーク帯域幅に達している場合は、DB クラスターを変更することで、DB クラスターで使用される DB インスタンスクラスをスケールできます。より大きなネットワーク帯域幅を持つ DB インスタンスクラスは、データをより効率的にクライアントに返します。

Amazon CloudWatch メトリクスのモニタリングについては、Amazon RDS コンソールでのメトリクスの表示 を参照してください。DB インスタンスクラスの詳細については、「Amazon Aurora DB インスタンスクラス」を参照してください。DB クラスターの変更については、「Amazon Aurora DB クラスターの変更」を参照してください。

予期しない結果のワークロードをチェックする

DB クラスターのワークロードをチェックし、予期しない結果が発生していないことを確認します。例えば、予想よりも多くの行を返すクエリがある可能性があります。この場合、Innodb_rows_read などの Performance Insights カウンターメトリクスを使用できます。詳細については、「Performance Insights カウンターメトリクス」を参照してください。

リーダーインスタンスでワークロードを分散する

Aurora レプリカを使用して、読み取り専用ワークロードを配布できます。Aurora レプリカを追加することで、水平方向にスケールできます。そうすると、ネットワーク帯域幅のスロットリング制限が増加する可能性があります。詳細については、「Amazon Aurora DB クラスター」を参照してください。

SQL_BUFFER_RESULT 修飾子を使用する

SQL_BUFFER_RESULT 修飾子 を SELECT ステートメントに追加すると、結果がクライアントに返される前にテンポラリテーブルに強制できます。クエリは io/aurora_respond_to_client 待機状態になっているため、InnoDB ロックが解放されていない時この修飾子はパフォーマンスの問題に役立ちます。詳細については、MySQL ドキュメントの SELECT ステートメントを参照してください。