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_locks Ereignis tritt ein, wenn Seiten, die nicht im Pufferpool gefunden wurden, aus dem Speicher gelesen werden müssen.
Unterstützte Engine-Versionen
Diese Warteereignisinformationen werden für die folgenden Versionen unterstützt:
-
Aurora Meine SQL 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. My SQL verwendet einen zuletzt verwendeten (LRU) Algorithmus, um Seiten aus dem Pufferpool 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 aus der Liste des Pufferpools freigegeben oder zu dieser hinzugefügt werden. LRU 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 Buffer Pool
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 Konfiguration von Amazon Aurora My SQL database
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.
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
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 Serverstatusvariablen
Ü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.
