# io/aurora\_respond\_to\_client
`io/aurora_respond_to_client` イベントは、スレッドが結果セットをクライアントに返すのを待っているときに発生します。
**Topics**
+ [サポート対象エンジンバージョン](#ams-waits.respond-to-client.context.supported)
+ [Context](#ams-waits.respond-to-client.context)
+ [待ち時間増加の考えられる原因](#ams-waits.respond-to-client.causes)
+ [アクション](#ams-waits.respond-to-client.actions)
## サポート対象エンジンバージョン
この待機イベント情報は、以下のエンジンバージョンでサポートされています。
+ Aurora MySQL バージョン 2
## Context
`io/aurora_respond_to_client` イベントは、スレッドが結果セットをクライアントに返すのを待っているときに発生します。
クエリの処理が完了し、結果はアプリケーションクライアントに返されます。ただし、DB クラスターには十分なネットワーク帯域幅がないため、スレッドは結果セットを返すのを待っています。
## 待ち時間増加の考えられる原因
`io/aurora_respond_to_client` イベントが通常よりも多く表示され、パフォーマンスの問題を示している可能性がある場合、典型的な原因は次のとおりです。
**DB インスタンスクラスがワークロードに対して不十分**
DB クラスターで使用される DB インスタンスクラスには、ワークロードを効率的に処理するために必要なネットワーク帯域幅がありません。
**大きな結果セット**
クエリがより多くの行数を返すため、返される結果セットのサイズが増加しました。結果セットが大きいほど、より多くのネットワーク帯域幅を消費します。
**クライアントへの負荷の増加**
クライアントに CPU プレッシャー、メモリプレッシャー、またはネットワークの飽和が発生する可能性があります。クライアントの負荷が増加すると、Aurora MySQL DB クラスターからのデータの受信が遅れます。
**ネットワークレイテンシーの増加**
Aurora MySQL DB クラスターとクライアント間のネットワークレイテンシーが増加することがあります。ネットワークレイテンシーが大きいほど、クライアントがデータを受信するのに必要な時間が長くなります。
## アクション
待機イベントの原因に応じたさまざまなアクションをお勧めします。
**Topics**
+ [イベントの原因となるセッションとクエリを特定する](#ams-waits.respond-to-client.actions.identify)
+ [DB インスタンスクラスのスケール](#ams-waits.respond-to-client.actions.scale-db-instance-class)
+ [予期しない結果のワークロードをチェックする](#ams-waits.respond-to-client.actions.workload)
+ [リーダーインスタンスでワークロードを分散する](#ams-waits.respond-to-client.actions.balance)
+ [SQL\_BUFFER\_RESULT 修飾子を使用する](#ams-waits.respond-to-client.actions.sql-buffer-result)
### イベントの原因となるセッションとクエリを特定する
Performance Insights を使用して、`io/aurora_respond_to_client` 待機イベントによってブロックされたクエリを表示できます。通常、ロードが中程度から重大なデータベースには、待機イベントがあります。パフォーマンスが最適であれば、待機イベントは受け入れられる可能性があります。パフォーマンスが最適でない場合は、データベースが最も長い時間を費やしている場所を調べます。最も高いロードに寄与する待機イベントを調べて、データベースとアプリケーションを最適化してこれらのイベントを削減できるかどうかを調べます。
**高ロードの原因となる SQL クエリを検索するには**
1. AWS マネジメントコンソール にサインインし、Amazon RDS コンソール ([https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/)) を開きます。
1. ナビゲーションペインで、[**Performance Insights**] を選択します。
1. DB インスタンスを選択します。その DB インスタンスの Performance Insights ダッシュボードが表示されます。
1. **データベースロード**で、**待機でスライス**を選択します。
1. ページの下部で **トップ SQL** を選択します。
グラフには、ロードの原因となる SQL クエリがリストされます。リスト上部にあるクエリに、最も責任があります。ボトルネックを解決するには、これらのステートメントに注目してください。
Performance Insights を使用したトラブルシューティングの便利な概要については、AWS データベースブログ記事の [Performance Insights を使用した Amazon Aurora MySQL ワークロードの分析](https://aws.amazon.com/blogs/database/analyze-amazon-aurora-mysql-workloads-with-performance-insights/)を参照してください。
### DB インスタンスクラスのスケール
`NetworkReceiveThroughput` や `NetworkTransmitThroughput` などのネットワークスループットに関連する Amazon CloudWatch メトリクスの値の増加を確認します。DB インスタンスクラスのネットワーク帯域幅に達している場合は、DB クラスターを変更することで、DB クラスターで使用される DB インスタンスクラスをスケールできます。より大きなネットワーク帯域幅を持つ DB インスタンスクラスは、データをより効率的にクライアントに返します。
Amazon CloudWatch メトリクスのモニタリングについては、[Amazon RDS コンソールでのメトリクスの表示](USER_Monitoring.md) を参照してください。DB インスタンスクラスの詳細については、「[Amazon Aurora DB インスタンスクラス](Concepts.DBInstanceClass.md)」を参照してください。DB クラスターの変更の詳細については、「[Amazon Aurora DB クラスターの変更](Aurora.Modifying.md)」を参照してください。
### 予期しない結果のワークロードをチェックする
DB クラスターのワークロードをチェックし、予期しない結果が発生していないことを確認します。例えば、予想よりも多くの行を返すクエリがある可能性があります。この場合、`Innodb_rows_read` などの Performance Insights カウンターメトリクスを使用できます。詳細については、「[Performance Insights カウンターメトリクス](USER_PerfInsights_Counters.md)」を参照してください。
### リーダーインスタンスでワークロードを分散する
Aurora レプリカを使用して、読み取り専用ワークロードを配布できます。Aurora レプリカを追加することで、水平方向にスケールできます。そうすると、ネットワーク帯域幅のスロットリング制限が増加する可能性があります。詳細については、「[Amazon Aurora DB クラスター](Aurora.Overview.md)」を参照してください。
### SQL\_BUFFER\_RESULT 修飾子を使用する
`SQL_BUFFER_RESULT` 修飾子 を `SELECT` ステートメントに追加すると、結果がクライアントに返される前にテンポラリテーブルに強制できます。クエリは `io/aurora_respond_to_client` 待機状態になっているため、InnoDB ロックが解放されていない時この修飾子はパフォーマンスの問題に役立ちます。詳細については、MySQL ドキュメントの [SELECT ステートメント](https://dev.mysql.com/doc/refman/5.7/en/select.html)を参照してください。