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_respond_to_client
Das io/aurora_respond_to_client-Ereignis tritt auf, wenn ein Thread darauf wartet, eine Ergebnismenge an einen Client zurückzugeben.
Unterstützte Engine-Versionen
Diese Warteereignisinformationen werden für die folgenden Engine-Versionen unterstützt:
-
Aurora Meine SQL 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
-
Möglicherweise herrscht CPU Druck, Speicherauslastung oder Netzwerküberlastung auf dem Client. Eine erhöhte Auslastung des Clients verzögert den Empfang von Daten aus dem Aurora My SQL DB-Cluster.
- Erhöhte Netzwerklatenz
-
Möglicherweise besteht eine erhöhte Netzwerklatenz zwischen dem Aurora My SQL DB-Cluster und dem Client. 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.
Themen
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.
Um SQL Abfragen zu finden, die für eine hohe Auslastung verantwortlich sind
Melden Sie sich bei der an AWS Management Console und öffnen Sie die RDS Amazon-Konsole unter https://console.aws.amazon.com/rds/
. -
Wählen Sie im Navigationsbereich Performance-Insights aus.
-
Wählen Sie eine DB-Instance aus. Das Performance-Insights-Dashboard wird für diese DB-Instance angezeigt.
-
Wählen Sie im Diagramm zur Datenbanklast die Option Nach Wartezeit aufteilen.
-
Wählen Sie unten auf der Seite Top ausSQL.
In der Tabelle sind die SQL Abfragen aufgeführt, die für den Ladevorgang 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 Sie Amazon Aurora My SQL 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 undNetworkTransmitThroughput. 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 unterMetriken in der RDS Amazon-Konsole anzeigen. Weitere Informationen zu DB-Instance-Klassen finden Sie unter Amazon Aurora Aurora-DB-Instance-Klassen. Informationen über das Ändern eines DB-Clusters finden Sie unter Ändern eines Amazon Aurora-DB-Clusters.
Ü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.
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.
Verwenden Sie den RESULT Modifikator SQL BUFFER _ _
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 SELECTAussage
