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.
synch/mutex/innodb/buf_pool_mutex
Dieses synch/mutex/innodb/buf_pool_mutex-Ereignis tritt ein, wenn ein Thread eine Sperre des InnoDB-Puffer-Pools für den Zugriff auf eine Seite im Speicher erworben hat.
Relevante Engine-Versionen
Diese Warteereignisinformationen werden für die folgenden Engine-Versionen unterstützt:
-
Aurora-MySQL-Version 2
Kontext
Der buf_pool-Mutex ist ein einzelner Mutex, der die Kontrolldatenstrukturen des Pufferpools schützt.
Weitere Informationen finden Sie unter Überwachen von InnoDB-Mutex-Wartezeiten mithilfe des Leistungsschemas
Wahrscheinliche Ursachen für erhöhte Wartezeiten
Dies ist ein Workload-spezifisches Warteereignis. Zu den häufigsten Ursachen für das Auftreten von synch/mutex/innodb/buf_pool_mutex unter den häufigsten Warteereignissen gehören die folgenden:
-
Die Pufferpoolgröße ist nicht groß genug, um den Arbeitsdatensatz zu speichern.
-
Die Workload ist für bestimmte Seiten einer bestimmten Tabelle in der Datenbank spezifischer, was zu Konflikten im Pufferpool führt.
Aktionen
Abhängig von den Ursachen Ihres Warteereignisses empfehlen wir verschiedene Aktionen.
Identifizieren der Sitzungen und Abfragen, die die Ereignisse verursachen
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 zeigen Sie das Top-SQL-Diagramm in der AWS-Managementkonsole an
Öffnen Sie die Amazon-RDS-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 unter dem Datenbankauslastungsdiagramm die Option 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.
Eine nützliche Übersicht über die Fehlerbehebung mit Performance Insights finden Sie im Blogbeitrag Analysieren Sie Amazon Aurora MySQL Workloads mit Performance Insights
Performance Insights verwenden
Dieses Ereignis hängt mit der Workload zusammen. Mit Performance Insights können Sie Folgendes tun:
-
Identifizieren Sie, wann Warteereignisse beginnen und ob sich die Workload zu dieser Zeit aus den Anwendungsprotokollen oder verwandten Quellen ändert.
-
Identifizieren Sie die SQL-Anweisungen, die für dieses Warteereignis verantwortlich sind. Untersuchen Sie den Ausführungsplan der Abfragen, um sicherzustellen, dass diese Abfragen optimiert sind und geeignete Indizes verwenden.
Wenn die obersten Abfragen, die für das Warteereignis verantwortlich sind, sich auf dasselbe Datenbankobjekt oder dieselbe Tabelle beziehen, sollten Sie erwägen, dieses Objekt oder die Tabelle zu partitionieren.
Erstellen eines Aurora-Replikats
Sie können Aurora-Replikationen erstellen, um schreibgeschützten Datenverkehr bereitzustellen. Sie können Aurora Auto Scaling auch verwenden, um Überspannungen im Leseverkehr zu behandeln. Stellen Sie sicher, dass geplante schreibgeschützte Aufgaben und logische Backups auf Aurora-Replikaten ausgeführt werden.
Weitere Informationen finden Sie unter Amazon Aurora Auto Scaling mit Aurora Replicas.
Überprüfen Sie die Größe des Pufferpools
Prüfen Sie anhand der Metrik innodb_buffer_pool_wait_free, ob die Pufferpoolgröße für die Workload ausreicht. Wenn der Wert dieser Metrik hoch ist und kontinuierlich zunimmt, deutet dies darauf hin, dass die Größe des Pufferpools nicht ausreicht, um die Workload zu bewältigen. Wenn innodb_buffer_pool_size richtig eingestellt wurde, sollte der Wert von innodb_buffer_pool_wait_free klein sein. Weitere Informationen finden Sie unter Innodb_buffer_pool_wait_free
Erhöhen Sie die Pufferpool-Größe, wenn die DB-Instance über genügend Speicher für Sitzungspuffer und Betriebssystemaufgaben verfügt. Wenn dies nicht der Fall ist, ändern Sie die DB-Instance in eine größere DB-Instance-Klasse, um zusätzlichen Speicher zu erhalten, der dem Pufferpool zugewiesen werden kann.
Anmerkung
Aurora MySQL passt den Wert von innodb_buffer_pool_instances automatisch basierend auf der konfigurierten innodb_buffer_pool_size an.
Überwachen Sie den globalen Statusverlauf
Durch die Überwachung der Änderungsraten von Statusvariablen können Sie Sperr- oder Speicherprobleme auf Ihrer DB-Instance erkennen. Aktivieren Sie den globalen Statusverlauf (GoSH), wenn er noch nicht aktiviert ist. Weitere Informationen zu GoSH finden Sie unter Verwalten des globalen Statusverlaufs.
Sie können auch benutzerdefinierte Amazon-CloudWatch-Metriken erstellen, um Statusvariablen zu überwachen. Weitere Informationen finden Sie unter Veröffentlichen benutzerdefinierter Metriken.
