Warum zeigt meine MySQL-DB-Instance eine hohe Anzahl aktiver Sitzungen an, die auf SYNCH-Warteereignisse in Performance Insights warten?

Kurzbeschreibung

MySQL SYNCH-Warteereignisse in Performance Insights treten auf, wenn mehrere Datenbanksitzungen auf dieselben geschützten Objekte oder Speicherstrukturen zugreifen. Die folgenden Objekte sind in Amazon Relational Database Service (Amazon RDS) für MySQL, Amazon RDS für MariaDB und Amazon Aurora MySQL-Compatible Edition geschützt:

• Die aktive Binärprotokolldatei in einer Binlog-Quell-Instance, die einen Mutex enthält, der es jeweils nur einer Sitzung erlaubt, sie zu lesen oder zu schreiben.
• Das Datenwörterbuch, das für Anweisungen in der Datenkontrollsprache (Data Control Language, DCL) oder Datendefinitionssprache (Data Definition Language, DDL) geschützt ist.
• Der adaptive Hash-Index, der einen Mutex enthält, der es jeweils nur einer Sitzung erlaubt, ihn zu lesen oder zu schreiben.
• Der offene Tabellen-Cache, in dem nur eine Sitzung eine Tabelle zum Cache hinzufügen oder daraus entfernen kann.
• Jeder Datenbankblock innerhalb des InnoDB-Pufferpools, in dem nur eine Sitzung den Inhalt eines Blocks im Speicher gleichzeitig ändern kann.

Lösung

Sicherstellen, dass die DB-Instance über genügend CPU-Ressourcen verfügt, um die Workload zu bewältigen

Eine hohe Anzahl von Sitzungen, die auf SYNCH-Ereignisse warten, führt zu einer hohen CPU-Auslastung. Bei einer Auslastung von 100 % steigt die Anzahl der Wartesitzungen. Erhöhe die Größe der DB-Instance, um dieses Problem zu beheben, sodass genügend CPU zur Verfügung steht, um die zusätzliche Workload zu verarbeiten.

Da SYNCH-Ereignisse in der Regel nicht lange andauern, zeigt die Amazon CloudWatch-Metrik CPUUtilization die Spitzenauslastung möglicherweise nicht korrekt an. Diese Metrik hat nur eine Granularität von 60 Sekunden. Um die Spitzenauslastung zu überprüfen, verwende den Granularitätszähler von einer Sekunde in Enhanced Monitoring auf der Amazon RDS-Konsole.

Das MySQL-Mutex- oder Wartesperre-Array erhöhen

MySQL verwendet eine interne Datenstruktur, um Threads mit einer Standard-Array-Größe von 1 zu koordinieren. Diese Konfiguration funktioniert bei Rechnern mit einer einzigen CPU, kann jedoch auf Rechnern mit mehreren CPUs zu Problemen führen. Wenn deine Workload eine große Anzahl von wartenden Threads hat, erhöhe die Array-Größe. Ändere den MySQL-Parameter innodb_sync_array_size so, dass er gleich oder höher als die Anzahl der CPUs ist. Weitere Informationen findest du unter innodb_sync_array_size auf der MySQL-Website.

Hinweis: MySQL verwendet den Parameter innodb_sync_array_size nur beim Datenbank-Startup.

Reduzieren der Parallelität

In der Regel verbessert Parallelität den Durchsatz. Wenn jedoch eine große Anzahl von Sitzungen dieselben oder ähnliche Aktivitäten ausführt, müssen die Sitzungen Zugriff auf dieselben geschützten Objekte haben. Je größer die Anzahl der Sitzungen ist, desto mehr CPU verwendest du, wenn du wartest.

Um dieses Problem zu lösen, verteile die Aktivitäten über einen bestimmten Zeitraum oder plane sie nacheinander. Du kannst auch mehrere Operationen in einer einzigen Anweisung bündeln, z. B. mehrzeilige Einfügungen.

Problembehandlung auf Grundlage der Warteereignisse

Ergreife die folgenden Maßnahmen zur Problembehandlung auf der Grundlage des Warteereignisses, das du erhältst.

synch/rwlock/innodb/dict sys RW lock oder synch/rwlock/innodb/dict_operation_lock

Diese Ereignisse treten auf, wenn du eine hohe Anzahl gleichzeitiger DCLs oder DDLs zur gleichen Zeit aufrufst. Um diese Probleme zu beheben, reduziere die Abhängigkeit der Anwendung von DDLs während der regulären Anwendungsaktivitäten.

synch/cond/sql/MDL_context::COND_wait_status

Dieses Ereignis tritt auf, wenn eine große Anzahl von SQLs, einschließlich Selects, auf eine Tabelle zugreift, die eine DCL oder DDL gerade ändert. Um dieses Problem zu beheben, führe während der regulären Anwendungsaktivitäten keine DDL-Anweisungen für Tabellen mit hohem Datenverkehr aus.

synch/mutex/sql/LOCK_open oder synch/mutex/sql/LOCK_table_cache

Diese Ereignisse treten auf, wenn die Anzahl der Tabellen, die die Sitzungen öffnen, die Größe des Tabellendefinitions-Caches oder des Cache geöffneter Tabellen überschreitet. Erhöhe die Größe der Caches, um dieses Problem zu beheben. Weitere Informationen findest du unter 10.4.3.1 How MySQL opens and closes tables (10.4.3.1 Wie MySQL-Tabellen öffnet und schließt) auf der MySQL-Website.

synch/mutex/sql/LOG

Dieses Ereignis tritt auf, wenn die Datenbank eine große Anzahl von Anweisungen ausführt, die von den aktuellen Protokollierungsmethoden nicht unterstützt werden können. Wenn du die Ausgabemethode TABLE (Tabelle) verwendest, versuche stattdessen, FILE (Datei) zu verwenden. Wenn du das allgemeine Protokoll verwendest, verwende stattdessen Advanced Auditing in Aurora. Wenn du den Parameter long_query_time auf 0 oder einen Wert unter 1 setzt, erhöhe den Wert.

synch/mutex/innodb/buf_pool_mutex, synch/mutex/innodb/aurora_lock_thread_slot_futex oder synch/rwlock/innodb/index_tree_rw_lock

Diese Ereignisse treten auf, wenn eine große Anzahl ähnlicher Datenbearbeitungssprach (Data Manipulation Language, DML)-Anweisungen gleichzeitig auf dasselbe Datenbankobjekt zugreift. Um dieses Problem zu lösen, verwende mehrzeilige Anweisungen und Partitionen, um die Workload auf verschiedene Datenbankobjekte zu verteilen.

synch/mutex/innodb/aurora_lock_thread_slot_futex

Dieses Ereignis tritt auf, wenn eine Sitzung eine Zeile für eine Aktualisierung gesperrt hat und dann eine andere Sitzung versucht, die Zeile zu aktualisieren. Behebe dieses Problem auf Grundlage der anderen Warteereignisse, die du erhältst. Suche nach den SQL-Anweisungen, die für dieses Warteereignis verantwortlich sind, und antworte darauf, oder suche nach der blockierenden Sitzung und antworte darauf.

synch/cond/sql/MYSQL_BIN_LOG::COND_done, synch/mutex/sql/MYSQL_BIN_LOG::LOCK_commit oder synch/mutex/sql/MYSQL_BIN_LOG::LOCK_log

Diese Ereignisse treten auf, wenn du die Binärprotokollierung aktiviert hast und ein großer Commit-Durchsatz, Commit-Transaktionen oder Replikate, die Binlogs lesen, vorhanden sind. Um dieses Problem zu beheben, verwende mehrzeilige Anweisungen oder gruppiere mehrere Anweisungen in einer einzigen Transaktion.

Weitere Informationen zu Aurora MySQL-kompatiblen Warteereignissen findest du unter Tuning Aurora MySQL with wait events (Tuning von Aurora MySQL mit Warteereignissen) und Aurora MySQL wait events (Aurora MySQL-Warteereignisse).

Es empfiehlt sich, die Datenbank auf eine Hauptversion zu aktualisieren, die mit 8.0 oder höher kompatibel ist. Verwende nach Möglichkeit mehrzeilige Anweisungen oder gruppiere mehrere Anweisungen zu einer einzigen Transaktion. Verwende in Aurora die Aurora Global Database anstelle der Replikation binärer Protokolle oder verwende die Parameter aurora_binlog.

Ähnliche Informationen

Überwachen der DB-Auslastung mit Performance Insights auf Amazon RDS

Parametergruppen für Amazon RDS