クライアント: ClientRead - Amazon Aurora
サポート対象エンジンバージョンContext待機時間が増加する原因の可能性アクション

クライアント: ClientRead

Client:ClientReadイベントは、Aurora PostgreSQL がクライアントからのデータの受信を待っているときに発生します。

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

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

Context

Aurora PostgreSQL DB クラスターは、クライアントからのデータ受信を待っています。Aurora PostgreSQL DB クラスターは、クライアントにさらにデータを送信する前に、クライアントからデータを受信する必要があります。クラスターがクライアントからデータを受信する前に待機する時間がClient:ClientReadイベントとなります。

待機時間が増加する原因の可能性

Client:ClientRead上位待機中に表示されるイベントの一般的な原因には、次のものがあります。

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

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

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

クライアント側で CPU プレッシャーまたはネットワーク飽和が発生している可能性があります。クライアント側の負荷が増加すると、クライアントから Aurora PostgreSQL DB クラスターへのデータの転送が遅延する可能性があります。

過剰なネットワークラウンドトリップ

Aurora PostgreSQL DB クラスターとクライアントの間のネットワークラウンドトリップが多くなると、クライアントから Aurora PostgreSQL DB クラスターへのデータの転送が遅延する可能性があります。

大規模なコピーオペレーション

コピーオペレーション中、データはクライアントのファイルシステムから Aurora PostgreSQL DB クラスターに転送されます。DB クラスターに大量のデータを送信すると、クライアントから DB クラスターへのデータの転送が遅延する可能性があります。

アイドル状態のクライアントの接続

Aurora PostgreSQL DB インスタンスへの接続は、トランザクション状態でアイドル状態であり、クライアントからのデータ送信またはコマンドの発行を待っています。この状態は、Client:ClientRead イベントの増加につながることがあります。

接続プーリングに使用される pgBouncer

pgBouncer にはpkt_bufという低レベルネットワーク構成設定があり、デフォルトでは 4,096 に設定されています。ワークロードが 4,096 バイトを超えるクエリパケットを pgBouncer を介して 送信する場合は、pkt_buf8,192 に設定することをお勧めします。新しい設定でClient:ClientReadイベントの数が減らない場合は、pkt_bufを16,384 や 32,768 など、より大きな値に設定にすることをお勧めします。クエリテキストが大きい場合は、大きな設定を使用すると特に効果的です。

アクション

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

クライアントをクラスターと同じアベイラビリティーゾーンと VPC サブネットに配置します。

ネットワークレイテンシーを減らしてネットワークスループットを向上するには、Aurora PostgreSQL DB クラスターと同じアベイラビリティーゾーンおよび仮想プライベートクラウド (VPC) サブネットにクライアントを配置します。クライアントが、DB クラスターにできる限り地理的に近い場所に配置されていることを確認してください。

クライアントのスケーリング

Amazon CloudWatch またはその他のホストメトリクスを使用して、クライアント側が現在 CPU またはネットワーク帯域幅、またはその両方によって制約を受けているかどうかを判断します。クライアント側が制約を受けている場合は、それに応じてクライアントをスケーリングします。

現行世代のインスタンスを使用

場合によっては、ジャンボフレームをサポートする DB インスタンスクラスを使用していない可能性があります。Amazon EC2 でアプリケーションを実行している場合は、クライアント側に現行世代のインスタンスを使用することを検討してください。また、クライアントのOSで最大送信単位 (MTU) を設定します。この技術では、ネットワークラウンドトリップの数を減らし、ネットワークスループットを向上させることができます。詳細については、「Amazon EC2 ユーザーガイド」の「ジャンボフレーム (9001 MTU)」を参照してください。

DB インスタンスクラスの詳細については、「Amazon Aurora DB インスタンスクラス」を参照してください。Amazon EC2 インスタンスタイプと同等の DB インスタンスクラスを決定するには、db.Amazon EC2 インスタンスタイプの前に配置します。例えば、r5.8xlargeAmazon EC2 インスタンスはdb.r5.8xlargeDB インスタンスクラスと同等です。

ネットワーク帯域幅の増加

NetworkReceiveThroughputおよびNetworkTransmitThroughputの Amazon CloudWatch メトリクスを使用して、DB クラスター上の着信および発信ネットワークトラフィックをモニタリングします。これらのメトリックは、ネットワーク帯域幅がワークロードに十分であるかどうかを判断するのに役立ちます。

ネットワーク帯域幅が十分でない場合は、増加してください。AWSクライアントまたは DB インスタンスがネットワーク帯域幅の制限に達している場合、帯域幅を増やす唯一の方法は、DB インスタンスのサイズを増加することことです。

CloudWatch のメトリクスの詳細については、「Amazon Aurora の Amazon CloudWatch メトリクス」を参照してください。

ネットワークパフォーマンスの最大値をモニタリングする

Amazon EC2 クライアントを使用している場合、Amazon EC2 は、集約されたインバウンドとアウトバウンドのネットワーク帯域幅を含む、ネットワークパフォーマンスメトリックの最大値を提供します。また、パケットが期待どおりに返されることを確認する接続追跡、ドメインネームシステム (DNS) などのサービスへのリンクローカルサービスアクセスも提供します。これらの最大値をモニタリングするには、現在の拡張ネットワークドライバーを使用し、クライアントのネットワークパフォーマンスをモニタリングします。

詳細については、「Amazon EC2 ユーザーガイド」の「Amazon EC2 インスタンスのネットワークパフォーマンスのモニタリング」および「Amazon EC2 ユーザーガイド」の「Amazon EC2 インスタンスのネットワークパフォーマンスのモニタリング」を参照してください。

「トランザクションのアイドル」状態のトランザクションをモニタリングする

idle in transaction接続の数が増えているかどうかをチェックします。これを行うには、pg_stat_activityテーブルのstate列をモニタリングします。次のようなクエリを実行することで、接続出典を特定できる場合があります。

select client_addr, state, count(1) from pg_stat_activity 
where state like 'idle in transaction%' 
group by 1,2 
order by 3 desc