Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.
# io/aurora\$1respond\$1to\$1client
Das `io/aurora_respond_to_client`-Ereignis tritt auf, wenn ein Thread darauf wartet, eine Ergebnismenge an einen Client zurückzugeben.
**Topics**
+ [Unterstützte Engine-Versionen](#ams-waits.respond-to-client.context.supported)
+ [Kontext](#ams-waits.respond-to-client.context)
+ [Wahrscheinliche Ursachen für erhöhte Wartezeiten](#ams-waits.respond-to-client.causes)
+ [Aktionen](#ams-waits.respond-to-client.actions)
## Unterstützte Engine-Versionen
Diese Warteereignisinformationen werden für die folgenden Engine-Versionen unterstützt:
+ Aurora-MySQL-Version 2
## Kontext
Das Ereignis `io/aurora_respond_to_client` zeigt an, dass ein Thread darauf wartet, eine Ergebnismenge an einen Client zurückzugeben.
Die Abfrageverarbeitung ist abgeschlossen und die Ergebnisse werden an den Anwendungsclient zurückgegeben. Da jedoch nicht genügend Netzwerkbandbreite im DB-Cluster vorhanden ist, wartet ein Thread darauf, die Ergebnismenge zurückzugeben.
## Wahrscheinliche Ursachen für erhöhte Wartezeiten
Wenn das `io/aurora_respond_to_client`-Ereignis mehr als normal auftritt, was möglicherweise auf ein Leistungsproblem hinweist, sind die folgenden typischen Ursachen:
**DB-Instance-Klasse reicht für die Workload nicht aus**
Die vom DB-Cluster verwendete DB-Instance-Klasse verfügt nicht über die erforderliche Netzwerkbandbreite, um die Workload effizient zu verarbeiten.
**Große Ergebnismengen**
Es gab eine Zunahme der Größe der zurückgegebenen Ergebnismenge, da die Abfrage eine höhere Anzahl von Zeilen zurückgibt. Die größere Ergebnismenge verbraucht mehr Netzwerkbandbreite.
**Erhöhte Belastung des Clients**
Auf dem Client kann es zu CPU-, Speicher- oder Netzwerksättigung kommen. Eine Erhöhung der Belastung des Clients verzögert den Empfang von Daten aus dem Aurora-MySQL-DB-Cluster.
**Erhöhte Netzwerklatenz**
Es kann zu einer erhöhten Netzwerklatenz zwischen dem Aurora-MySQL-DB-Cluster und dem Client kommen. Eine höhere Netzwerklatenz erhöht die Zeit, die der Client benötigt, um die Daten zu empfangen.
## Aktionen
Abhängig von den Ursachen Ihres Warteereignisses empfehlen wir verschiedene Aktionen.
**Topics**
+ [Identifizieren der Sitzungen und Abfragen, die die Ereignisse verursachen](#ams-waits.respond-to-client.actions.identify)
+ [Skalieren Sie die DB-Instance-Klasse](#ams-waits.respond-to-client.actions.scale-db-instance-class)
+ [Überprüfen Sie die Workload auf unerwartete Ergebnisse](#ams-waits.respond-to-client.actions.workload)
+ [Verteilen Sie die Workload mit Leser-Instances](#ams-waits.respond-to-client.actions.balance)
+ [Verwenden Sie den Modifikator SQL\$1BUFFER\$1RESULT](#ams-waits.respond-to-client.actions.sql-buffer-result)
### Identifizieren der Sitzungen und Abfragen, die die Ereignisse verursachen
Sie können Performance Insights verwenden, um Abfragen anzuzeigen, die durch das `io/aurora_respond_to_client`-Warteereignis gesperrt wurden Normalerweise weisen Datenbanken mit mäßiger bis erheblicher Last Warteereignisse auf. Die Warteereignisse sind möglicherweise akzeptabel, wenn die Leistung optimal ist. Wenn die Leistung nicht optimal ist, untersuchen Sie, wo die Datenbank die meiste Zeit verbringt. Schauen Sie sich die Warteereignisse an, die zur höchsten Belastung beitragen und finden Sie heraus, ob Sie die Datenbank und die Anwendung optimieren können, um diese Ereignisse zu reduzieren.
**So suchen Sie SQL-Abfragen, die für hohe Last verantwortlich sind**
1. Melden Sie sich bei der an AWS-Managementkonsole und öffnen Sie die Amazon RDS-Konsole unter [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/).
1. Wählen Sie im Navigationsbereich **Performance-Insights** aus.
1. Wählen Sie eine DB-Instance aus. Das Performance-Insights-Dashboard wird für diese DB-Instance angezeigt.
1. Wählen Sie im Diagramm zur **Datenbanklast** die Option **Nach Wartezeit aufteilen**.
1. Wählen Sie unten auf der Seite **Top-SQL** aus.
Das Diagramm listet die SQL-Abfragen auf, die für die Belastung verantwortlich sind. Diejenigen, die an der Spitze der Liste stehen, sind am meisten verantwortlich. Konzentrieren Sie sich auf diese Aussagen, um einen Engpass zu beheben.
Einen nützlichen Überblick über die Fehlerbehebung mit Performance Insights finden Sie im AWS Datenbank-Blogbeitrag [Analysieren von Amazon Aurora MySQL-Workloads mit Performance Insights](https://aws.amazon.com/blogs/database/analyze-amazon-aurora-mysql-workloads-with-performance-insights/).
### Skalieren Sie die DB-Instance-Klasse
Prüfen Sie, ob der Wert der CloudWatch Amazon-Metriken in Bezug auf den Netzwerkdurchsatz gestiegen ist, z. B. `NetworkReceiveThroughput` und`NetworkTransmitThroughput`. Wenn die Netzwerkbandbreite der DB-Instance-Klasse erreicht wird, können Sie die vom DB-Cluster verwendete DB-Instance-Klasse skalieren, indem Sie den DB-Cluster ändern. Eine DB-Instance-Klasse mit größerer Netzwerkbandbreite gibt Daten effizienter an Clients zurück.
Informationen zur Überwachung von CloudWatch Amazon-Metriken finden Sie unter[Anzeigen von Metriken in der Amazon-RDS-Konsole](USER_Monitoring.md). Weitere Informationen zu DB-Instance-Klassen finden Sie unter [Amazon Aurora Aurora-DB-Instance-Klassen](Concepts.DBInstanceClass.md). Weitere Informationen zum Ändern eines DB-Clusters finden Sie unter [Ändern eines Amazon Aurora-DB-Clusters](Aurora.Modifying.md).
### Überprüfen Sie die Workload auf unerwartete Ergebnisse
Überprüfen Sie die Workload im DB-Cluster und stellen Sie sicher, dass keine unerwarteten Ergebnisse erzielt werden. Beispielsweise kann es Abfragen geben, die eine höhere Anzahl von Zeilen als erwartet zurückgeben. In diesem Fall können Sie Performance-Insights-Zählermetriken wie `Innodb_rows_read` verwenden. Weitere Informationen finden Sie unter [Performance-Insights-Zählermetriken](USER_PerfInsights_Counters.md).
### Verteilen Sie die Workload mit Leser-Instances
Sie können schreibgeschützte Workloads mit Aurora-Replikaten verteilen. Sie können horizontal skalieren, indem Sie weitere Aurora-Replikate hinzufügen. Dies kann zu einer Erhöhung der Drosselgrenzen für die Netzwerkbandbreite führen. Weitere Informationen finden Sie unter [Amazon-Aurora-DB-Cluster](Aurora.Overview.md).
### Verwenden Sie den Modifikator SQL\$1BUFFER\$1RESULT
Sie können `SELECT`-Anweisungen den Modifikator `SQL_BUFFER_RESULT` hinzufügen, um das Ergebnis in eine temporäre Tabelle zu zwingen, bevor es an den Client zurückgegeben wird. Dieser Modifikator kann bei Leistungsproblemen helfen, wenn InnoDB-Sperren nicht freigegeben werden, weil sich Abfragen im Wartezustand `io/aurora_respond_to_client` befinden. Weitere Informationen finden Sie unter [SELECT-Anweisung](https://dev.mysql.com/doc/refman/5.7/en/select.html) in der MySQL-Dokumentation.