Kunde: ClientRead

Das Ereignis Client:ClientRead tritt ein, wenn Aurora PostgreSQL darauf wartet, Daten vom Client zu empfangen.

Unterstützte Engine-Versionen

Diese Warteereignisinformationen werden für Aurora PostgreSQL Version 10 und höher unterstützt.

Kontext

Ein Aurora PostgreSQL DB-Cluster wartet darauf, Daten vom Client zu empfangen. Der Aurora PostgreSQL-DB-Cluster muss die Daten vom Client empfangen, bevor er weitere Daten an den Client senden kann. Die Zeit, die der Cluster wartet, bevor er Daten vom Client empfängt, ist ein Client:ClientRead-Ereignis.

Wahrscheinliche Ursachen für erhöhte Wartezeiten

Häufige Gründe dafür, dass das Client:ClientRead-Ereignis in den Top-Wartezeiten angezeigt wird, sind die folgenden:

Erhöhte Netzwerklatenz

Es kann zu einer erhöhten Netzwerklatenz zwischen dem Aurora PostgreSQL-DB-Cluster und dem Client kommen. Eine höhere Netzwerklatenz erhöht die Zeit, die der DB-Cluster benötigt, um Daten vom Client zu empfangen.

Erhöhte Belastung des Clients

Auf dem Client kann es zu CPU-Druck oder Netzwerksättigung kommen. Eine Zunahme der Last auf dem Client kann die Übertragung von Daten vom Client zum Aurora PostgreSQL-DB-Cluster verzögern.

Übermäßige Netzwerkrundfahrten

Eine große Anzahl von Netzwerk-Roundtrips zwischen dem Aurora PostgreSQL-DB-Cluster und dem Client kann die Datenübertragung vom Client zum Aurora PostgreSQL-DB-Cluster verzögern.

Großer Kopiervorgang

Während eines Kopiervorgangs werden die Daten vom Dateisystem des Clients in den Aurora PostgreSQL DB-Cluster übertragen. Das Senden einer großen Datenmenge an den DB-Cluster kann die Übertragung von Daten vom Client zum DB-Cluster verzögern.

Verbindung von Clients im Leerlauf

Eine Verbindung mit einer DB-Instance von Aurora PostgreSQL befindet sich im Transaktionsstatus im Leerlauf und wartet darauf, dass ein Client weitere Daten sendet oder einen Befehl ausgibt. Dieser Status kann zu einer Zunahme von Client:ClientRead-Ereignissen führen.

PgBouncer wird für das Verbindungspooling verwendet

PgBouncer hat eine Netzwerkkonfigurationseinstellung auf niedriger Ebene aufgerufenpkt_buf, die standardmäßig auf 4.096 gesetzt ist. Wenn der Workload Abfragepakete mit mehr als 4.096 Byte durchsendet, empfehlen wir PgBouncer, die Einstellung auf 8.192 zu erhöhen. pkt_buf Wenn die neue Einstellung die Anzahl der Client:ClientRead-Ereignisse nicht verringert, empfehlen wir, die pkt_buf-Einstellung auf höhere Werte zu erhöhen, z. B. 16.384 oder 32.768. Wenn der Abfragetext groß ist, kann die größere Einstellung besonders hilfreich sein.

Aktionen

Abhängig von den Ursachen Ihres Warteereignisses empfehlen wir verschiedene Aktionen.

Themen

• Platzieren Sie die Clients im selben Availability Zone- und VPC-Subnetz wie der Cluster
• Skalieren Sie Ihren -C
• Instances der aktuellen Generation verwenden
• Erhöhung der Netzwerkbandbreite
• Überwachen Sie Maximen für die Netzwerkleistung
• Überwachen Sie auf Transaktionen im Status „Leerlauf in Transaktion“

Platzieren Sie die Clients im selben Availability Zone- und VPC-Subnetz wie der Cluster

Um die Netzwerklatenz zu reduzieren und den Netzwerkdurchsatz zu erhöhen, platzieren Sie Clients in dieselbe Availability Zone und Virtual Private Cloud (VPC) -Subnetz wie der Aurora PostgreSQL DB-Cluster. Stellen Sie sicher, dass sich die Clients so geografisch wie möglich am DB-Cluster befinden.

Skalieren Sie Ihren -C

Ermitteln Sie anhand von Amazon CloudWatch oder anderen Host-Metriken, ob Ihr Client derzeit durch CPU- oder Netzwerkbandbreite oder beides eingeschränkt ist. Wenn der Kunde eingeschränkt ist, skalieren Sie Ihren Kunden entsprechend.

Instances der aktuellen Generation verwenden

In einigen Fällen verwenden Sie möglicherweise keine DB-Instance-Klasse, die Jumbo-Frames unterstützt. Wenn Sie Ihre Anwendung auf Amazon EC2 ausführen, sollten Sie eine Instance der aktuellen Generation für den Client verwenden. Konfigurieren Sie außerdem die maximale Übertragungseinheit (MTU) im Kundenvorgangssystem Diese Technik könnte die Anzahl der Netzläufe reduzieren und den Netzwerkdurchsatz erhöhen. Weitere Informationen finden Sie unter Jumbo Frames (9001 MTU) im Amazon EC2 EC2-Benutzerhandbuch.

Weitere Informationen zu DB-Instance-Klassen finden Sie unter Aurora DB-Instance-Klassen. Um die DB-Instance-Klasse zu bestimmen, die einem Amazon EC2-Instance-Typ entspricht, platzieren Sie db. vor dem Namen des Amazon EC2-Instance-Typs. Beispielsweise entspricht die r5.8xlarge-Amazon EC2-Instance der db.r5.8xlarge-DB-Instance-Klasse.

Erhöhung der Netzwerkbandbreite

Verwenden Sie NetworkReceiveThroughput und NetworkTransmitThroughput CloudWatch Amazon-Metriken, um den eingehenden und ausgehenden Netzwerkverkehr auf dem DB-Cluster zu überwachen. Diese Metriken können Ihnen helfen festzustellen, ob die Netzwerkbandbreite für Ihre Workload ausreicht.

Wenn Ihre Netzwerkbandbreite nicht ausreicht, erhöhen Sie sie. Wenn der AWS Client oder Ihre DB-Instance die Netzwerkbandbreitenlimits erreicht, besteht die einzige Möglichkeit, die Bandbreite zu erhöhen, darin, Ihre DB-Instance-Größe zu erhöhen.

Weitere Informationen zu CloudWatch Metriken finden Sie unter CloudWatch Amazon-Metriken für Amazon Aurora.

Überwachen Sie Maximen für die Netzwerkleistung

Wenn Sie Amazon EC2-Clients verwenden, bietet Amazon EC2 Maximum für Netzwerkleistungsmetriken, einschließlich der aggregierten eingehenden und ausgehenden Netzwerkbandbreite. Es bietet auch Verbindungsverfolgung, um sicherzustellen, dass Pakete wie erwartet zurückgegeben werden, und Zugriff auf Link-lokale Dienste für Dienste wie das Domain Name System (DNS). Um diese Maximen zu überwachen, verwenden Sie einen aktuell erweiterten Netzwerktreiber und überwachen Sie die Netzwerkleistung für Ihren Client.

Weitere Informationen finden Sie unter Überwachen der Netzwerkleistung für Ihre Amazon EC2 EC2-Instance im Amazon EC2 EC2-Benutzerhandbuch und Überwachen der Netzwerkleistung für Ihre Amazon EC2 EC2-Instance im Amazon EC2 EC2-Benutzerhandbuch.

Überwachen Sie auf Transaktionen im Status „Leerlauf in Transaktion“

Überprüfen Sie, ob Sie eine steigende Anzahl von idle in transaction-Verbindungen haben. Beobachten Sie dazu die state-Spalte in der pg_stat_activity-Tabelle. Möglicherweise können Sie die Verbindungsquelle identifizieren, indem Sie eine Abfrage ähnlich der folgenden ausführen.

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