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.

Optimieren Ihres Abfrage-Workloads

Mit einem gut abgestimmten Workload können Sie viel erreichen, um eine stabile Lösung für Hyperwachstum zu finden. Wenn Ihr Workload nicht gut abgestimmt ist, werden Sie unabhängig von der Leistung des von Ihnen verwendeten Amazon-Aurora-Clusters auf Engpässe stoßen, die die Leistung beeinträchtigen und die Benutzererfahrung Ihrer Anwendung beeinträchtigen. Es empfiehlt sich, von Anfang an über einen Prozess zu verfügen, der Ihnen hilft, problematische Abfragen in Ihrem System zu identifizieren und zu optimieren.

Verfolgen und Optimieren problematischer Abfragen in Ihrem Workload

Wenn Sie auf Hyperwachstum stoßen, ist ein gut abgestimmter Workload die halbe Miete. Um die Art der Echtzeit-Workloads und Leistungsprobleme zu verstehen, mit denen Ihr Aurora-Cluster konfrontiert ist, stellen Sie sicher, dass Ihr Team problematische Anfragen sowohl von Ihren Writer- als auch von Ihren Reader-Instances sammelt. Diese problematischen Abfragen müssen so abgestimmt werden, dass Ihr Workload in einem optimalen Zustand ausgeführt wird. Amazon-Aurora-MySQL-kompatible Edition bietet Ihnen zwei Möglichkeiten, dies zu erreichen:

Verwendung von Performance-Insights

Performance Insights verfolgt die Auslastung der Aurora-Writer- oder Reader-Instance auf der Grundlage der durchschnittlichen aktiven Sitzungen (AAS). Der AAS-Wert wird anhand von Stichproben und der Anzahl der aktiven Sitzungen berechnet, die darauf warten, dass eine CPU ihre Abfrage-Workload übernimmt und verarbeitet. Performance Insights bietet eine grafische Oberfläche, in der Sie die SQL-Anweisungen überprüfen können, die die höchste Auslastung verursachen, indem Sie auf aktive Sitzungen warten.

Im vorherigen Screenshot verursacht der Aufruf der gespeicherten Prozedur my_sqrt durchschnittlich 13,03 Sitzungen, die auf die Verarbeitung ihrer Lasten warten. Der logische nächste Schritt besteht darin, dieses Verfahren zu optimieren. Sie sollten die SQL-Anweisungen in Ihren Reader und Writern identifizieren, die die jeweilige Instance belasten, und sie so anpassen, dass die Leistung verbessert wird, bis die AAS-Werte sinken und unter der gepunkteten Linie Max vCPU in Performance Insights bleiben. Wenn Sie bei Ihren Optimierungsbemühungen an eine Obergrenze gestoßen sind und die AAS immer noch über der Max-vCPU-Linie liegt, können Sie sich für eine größere Instance-Klasse entscheiden, um Ihren Workload zu bewältigen. Entscheiden Sie sich nicht für eine größere Instance, ohne zuvor versucht zu haben, Ihren Abfrage-Workload zu optimieren, da durch den zunehmenden Verkehr die Fehlerlinien aufgedeckt werden, die durch fehlerhafte Abfragen in Ihrem Workload entstanden sind.

Logs für langsame Abfragen verwenden und veröffentlichen in CloudWatch

Das Slow Query Log ist ein natives MySQL-Feature und ergänzt Performance Insights. Es empfiehlt sich, beide Methoden zu verwenden, um problematischen Abfragen, die verheerende Auswirkungen auf Ihre Instances haben können, immer einen Schritt voraus zu sein. Das Slow Query Log protokolliert alle Abfragen, die langsamer als die dynamische Variable long_query_time sind. Diese Variable kann eingerichtet werden, ohne dass Ihre Cluster-Instances neu gestartet werden müssen.

Verwenden Sie separate Parametergruppen für Ihre Writer- und Reader-Instances, um Flexibilität und Isolation bei der Optimierung zu gewährleisten. Das ist besonders wichtig, wenn Sie Read-Write-Split verwenden. Richten Sie ein komfortables Limit für long_query_time in Ihren Cluster-Instances je nach Bedarf ein. Wenn Sie Ihre Auslastung anpassen, können Sie auf aggressive Werte in der long_query_time-Variablen zielen, weil Sie den Schwellenwert auf Millisekundenebene festlegen können. Bei hoher Parallelität und einem gut abgestimmten Workload sollten fast alle Ihre Abfragen in Millisekunden ausgeführt werden.

Wenn Sie Amazon-Aurora-MySQL-kompatible Edition so einrichten, dass Slow Query Logs in einer Datei protokolliert werden, schreibt Aurora-MySQL-kompatible die lSlow Query Logs in das Aurora-MySQL-kompatible Dateisystem und speichert sie 24 Stunden lang. Um die langsamen Abfrageprotokolle für einen längeren Zeitraum zur Analyse aufzubewahren, veröffentlichen Sie sie auf Amazon CloudWatch. Sie können auch ein CloudWatch Dashboard erstellen, um Ihre langsamen Abfragen zu überwachen. Weitere Informationen finden Sie im Blogbeitrag Erstellen eines CloudWatch Amazon-Dashboards zur Überwachung von Amazon RDS und Amazon Aurora MySQL. Zusätzlich zur Analyse Ihrer langsamen Abfragen bei Amazon CloudWatch können Sie mithilfe pt-query-digest eines Tools im Percona Toolkit Profile für langsame Abfragen erstellen.

Sie können sich auch dafür entscheiden, diesen Prozess des Herunterladens und der Profilerstellung von Abfragen zu automatisieren, um die Effizienz in Ihrem Team zu erhöhen. Ihr Team sollte nach Abfragen suchen, die häufig und in längeren Intervallen ausgeführt werden, und deren Optimierung priorisieren. Streben Sie einen Zustand an, in dem nur sehr wenige Abfragen in Ihrem Slow Query Log protokolliert werden, und Sie können die long_query_time reduzieren, um aggressiver zu werden, je besser Sie Ihren Workload verstehen und anpassen.