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/sxlock/innodb/hash_table_locks
Das -synch/sxlock/innodb/hash_table_locksEreignis tritt auf, wenn Seiten, die nicht im Pufferpool gefunden werden, aus dem Speicher gelesen werden müssen.
Unterstützte Engine-Versionen
Diese Warteereignisinformationen werden für die folgenden Versionen unterstützt:
-
Aurora-MySQL-Versionen 2 und 3
Kontext
Das Ereignis synch/sxlock/innodb/hash_table_locks zeigt an, dass eine Workload häufig auf Daten zugreift, die nicht im Pufferpool gespeichert sind. Dieses Warteereignis ist mit neuen Seitenhinzufügungen und alten Datenräumungen aus dem Pufferpool verbunden. Die im Pufferpool gespeicherten Daten und neuen Daten müssen zwischengespeichert werden, sodass die gealterten Seiten geräumt werden, um das Zwischenspeichern der neuen Seiten zu ermöglichen. MySQL verwendet einen am wenigsten verwendeten (LRU) -Algorithmus, um Seiten aus dem Puffer-Pool zu entfernen. Die Workload versucht, auf Daten zuzugreifen, die nicht in den Pufferpool geladen wurden, oder auf Daten, die aus dem Pufferpool vertrieben wurden.
Dieses Warteereignis tritt auf, wenn der Workload auf die Daten in Dateien auf der Festplatte zugreifen muss oder wenn Blöcke von der LRU-Liste des Pufferpools befreit oder zur LRU-Liste des Pufferpools hinzugefügt werden. Diese Vorgänge warten darauf, eine gemeinsame ausgeschlossene Sperre (SX-Lock) zu erhalten. Diese SX-Sperre wird für die Synchronisation über die Hash-Tabelle verwendet, bei der es sich um eine Tabelle im Speicher handelt, die die Leistung des Pufferpoolzugriffs verbessern soll.
Weitere Informationen finden Sie unter Bufferpool
Wahrscheinliche Ursachen für erhöhte Wartezeiten
Wenn das synch/sxlock/innodb/hash_table_locks-Warteereignis mehr als normal auftritt, was möglicherweise auf ein Leistungsproblem hinweist, sind die folgenden typischen Ursachen:
- Ein unterdimensionierter Pufferpool
-
Die Größe des Pufferpools ist zu klein, um alle häufig aufgerufenen Seiten im Speicher zu behalten.
- Starke Workload
-
Die Workload verursacht häufige Bereinigungen und das Neuladen von Datenseiten in den Puffercache.
- Fehler beim Lesen der Seiten
-
Es gibt Fehler beim Lesen von Seiten im Pufferpool, die auf eine Beschädigung von Daten hinweisen können.
Aktionen
Abhängig von den Ursachen Ihres Warteereignisses empfehlen wir verschiedene Aktionen.
Themen
Erhöhen Sie die Größe des Pufferpools
Stellen Sie sicher, dass diese Pufferpools für die Workload entsprechend dimensioniert sind. Sie können dazu die Trefferrate des Pufferpools überprüfen. Wenn der Wert unter 95 Prozent sinkt, sollten Sie in der Regel die Größe des Pufferpools erhöhen. Ein größerer Pufferpool kann häufig aufgerufene Seiten länger im Speicher halten. Um die Größe des Pufferpools zu vergrößern, ändern Sie den Wert des innodb_buffer_pool_size-Parameters. Der Standardwert dieses Parameters basiert auf der DB-Instance-Klassengröße. Weitere Informationen finden Sie unter bewährte Methoden für die Amazon-Aurora-MySQL-Datenbankkonfiguration
Verbesserung der Datenzugriffsmuster
Überprüfen Sie die von dieser Wartezeit betroffenen Abfragen und deren Ausführungspläne. Erwägen Sie, die Datenzugriffsmuster zu verbessern. Wenn Sie beispielsweise mysqli_result:: fetch_array
Sie können Performance Insights verwenden, um Abfragen und Sitzungen anzuzeigen, die möglicherweise ein synch/sxlock/innodb/hash_table_locks-Warteereignis verursachen.
So suchen Sie SQL-Abfragen, die für hohe Last verantwortlich sind
Melden Sie sich bei der AWS Management Console an und ö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 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.
Eine nützliche Übersicht über die Fehlerbehebung mit Performance Insights finden Sie im AWS-Database Blog-Beitrag Analysieren von Amazon-Aurora-MySQL-Workloads mit Performance Insights
Reduzieren oder vermeiden Sie vollständige Tabellen-Scans
Überwachen Sie Ihre Workload, um zu sehen, ob vollständige Tabellen-Scans ausgeführt werden, und wenn dies der Fall ist, reduzieren oder vermeiden Sie sie. Sie können beispielsweise Statusvariablen wie Handler_read_rnd_next überwachen. Weitere Informationen finden Sie unter Server-Status-Variablen
Überprüfen Sie die Fehlerprotokolle auf Seitenbeschädigung
Sie können mysql-error.log auf korruptionsbezogene Nachrichten überprüfen, die zum Zeitpunkt des Problems erkannt wurden. Nachrichten, mit denen Sie arbeiten können, um das Problem zu beheben, befinden sich im Fehlerprotokoll. Möglicherweise müssen Sie Objekte neu erstellen, die als beschädigt gemeldet wurden.
