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

Kurzbeschreibung

Performance Insights sind für jeden der folgenden Dienste aktiviert:

• Amazon Relational Database Service (Amazon RDS) für MySQL.
• Amazon RDS für MariaDB.
• Amazon Aurora MySQL-kompatible Ausgabe.

Wenn Sie MySQL SYNCH-Wait-Ereignisse in Performance Insights sehen, versucht eine große Anzahl von Sitzungen in der Datenbank, auf dieselben geschützten Objekte oder Speicherstrukturen zuzugreifen. Zu den geschützten Objekten in MySQL gehören die folgenden:

• Die aktive Binärlogdatei in einer Binlog-Quell-Instance. Sie enthält einen Mutex, der es jeweils nur einer Sitzung erlaubt, sie zu lesen oder zu schreiben.
• Das Datenwörterbuch, für Schreibvorgänge, die normalerweise durch Anweisungen in der Data Control Language (DCL) oder Data Definition Language (DDL) verursacht werden.
• Der adaptive Hash-Index. Er enthält einen Mutex, der es jeweils nur einer Sitzung erlaubt, ihn zu lesen oder zu schreiben.
• Der offene Tabellen-Cache. Nur eine Sitzung kann eine Tabelle zum Cache hinzufügen oder daraus entfernen.
• Jeder einzelne Datenbankblock innerhalb des InnoDB-Pufferpools. Nur eine Sitzung kann den Inhalt eines Blocks im Speicher gleichzeitig ändern.

Behebung

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

Wenn Sie eine hohe Anzahl von Sitzungen haben, die auf SYNCH-Ereignisse warten, führt dies zu einer hohen CPU-Auslastung. Wenn die Auslastung 100% erreicht, erhöht sich die Anzahl der wartenden Sitzungen. Erhöhen Sie bei der Fehlerbehebung die Größe Ihrer DB Instance, um sicherzustellen, dass genügend CPU vorhanden ist, um die zusätzliche Workload zu verarbeiten.

Da diese Ereignisse normalerweise nur von kurzer Dauer sind, zeigt die Amazon-CloudWatch-Metrik zur CPU-Auslastung die Spitzenauslastung möglicherweise nicht korrekt an. Der beste Weg, dies zu überprüfen, besteht darin, die CPU-Zähler für eine Sekunde in RDS Enhanced Monitoring zu verwenden. Diese Zähler sind spezifischer und detaillierter.

Erhöhen Sie das Mutex/Lock-Wait-Array von MySQL

MySQL verwendet eine interne Datenstruktur, um Threads zu koordinieren. Dieses Array hat standardmäßig die Größe eins. Dies ist für Rechner mit einer CPU geeignet, kann jedoch auf Computern mit mehreren CPUs zu Problemen führen. Wenn Ihre Workload eine große Anzahl von wartenden Threads hat, erhöhen Sie die Array-Größe. Setzen Sie den MYSQL-Parameter innodb_sync_array_size auf die Anzahl der CPUs (oder höher, bis zu 1024).

Hinweis: Der Parameter innodb_sync_array_size gilt nur beim Start der Datenbank.

Reduzieren Sie die Parallelität

Im Allgemeinen trägt Parallelität zur Verbesserung des Durchsatzes bei. Wenn jedoch eine große Anzahl von Sitzungen versucht, dieselben oder ähnliche Aktivitäten auszuführen, benötigen die Sitzungen Zugriff auf dieselben geschützten Objekte. Je höher die Anzahl der Sitzungen, desto mehr CPU verwenden Sie während des Wartens.

Verteilen Sie diese Aktivitäten über einen bestimmten Zeitraum oder planen Sie sie in einer Reihe. Sie können auch mehrere Operationen in einer einzigen Anweisung bündeln, z. B. mehrzeilige Einfügungen.

Untersuchen Sie bestimmte Warteereignisse

Verwenden Sie die folgenden Beispiele, um Ihr spezielles Warteereignis zu beheben. Weitere Informationen zu Aurora-MySQL-Warteereignissen finden Sie unter Optimieren von Aurora MySQL mit Warteereignissen.

• synch/rwlock/innodb/dict sys RW lock ODER
  synch/rwlock/innodb/dict_operation_lock: Dies weist darauf hin, dass eine hohe Anzahl gleichzeitiger DCLs von DDLs gleichzeitig ausgelöst wird. Reduzieren Sie die Abhängigkeit der Anwendung von der Verwendung von DDLs während der regulären Anwendungsaktivität.
• Synch/cond/sql/MDL_context: :COND_wait_status: Dies weist auf eine hohe Anzahl von SQLs (einschließlich Selects) hin, die versuchen, auf eine Tabelle zuzugreifen, die von einer DCL oder DDL geändert wird. Vermeiden Sie es, während der regulären Anwendungsaktivität DDL-Anweisungen für Tabellen mit hohem Datenverkehr auszuführen.
• synch/mutex/sql/LOCK_open ODER
  synch/mutex/sql/LOCK_table_cache: Dies bedeutet, dass die Anzahl der Tabellen, die Ihre Sitzungen öffnen, die Größe des Tabellendefinitionscaches oder des Tabellen-Open-Cache übersteigt. Erhöhen Sie die Größe dieser Caches.
• synch/mutex/sql/LOG: Ihre Datenbank führt möglicherweise eine große Anzahl von Anweisungen aus, und die aktuellen Protokollierungsmethoden können dies nicht unterstützen. Wenn Sie die Ausgabemethode TABELLE verwenden, versuchen Sie stattdessen, DATEI zu verwenden. Wenn Sie das allgemeine Protokoll verwenden, verwenden Sie stattdessen das erweiterte Auditing von Amazon Aurora. Wenn Sie 0 oder weniger als 1 für den Parameter long_query_time verwenden, versuchen Sie, ihn zu erhöhen.
• synch/mutex/innodb/buf_pool_mutex ODER synch/mutex/innodb/aurora_lock_thread_slot_futex ODER synch/rwlock/innodb/index_tree_rw_lock: Es gibt eine große Anzahl ähnlicher DMLs, die gleichzeitig auf dasselbe Datenbankobjekt zugreifen. Verwenden Sie mehrzeilige Anweisungen und verwenden Sie Partitionierung, um die Workload auf verschiedene Datenbankobjekte zu verteilen.
• synch/mutex/innodb/aurora_lock_thread_slot_futex: Dies passiert, wenn eine Sitzung eine Zeile für ein Update gesperrt hat und dann eine andere Sitzung versucht, dieselbe Zeile zu aktualisieren. Ihre Aktion hängt von den anderen Warteereignissen ab, die Sie sehen. Suchen Sie entweder nach den SQL-Anweisungen, die für dieses Warteereignis verantwortlich sind, und antworten Sie darauf, oder suchen Sie nach der blockierenden Sitzung und antworten Sie darauf.
• synch/cond/sql/MySQL_BIN_LOG: :COND_done ODER
  synch/mutex/sql/MySQL_BIN_LOG: :LOCK_commit ODER
  synch/mutex/sql/MySQL_BIN_LOG: :LOCK_log: Sie haben die binäre Protokollierung aktiviert und es könnte eine der folgenden Ursachen geben:

• ein hoher Commit-Durchsatz.

• eine große Anzahl von Transaktionen, die übernommen werden.

• Replikate, die Binlogs lesen.

• eine Kombination davon.

Erwägen Sie, die Datenbank auf eine Hauptversion zu aktualisieren, die mit 5.7 oder höher kompatibel ist. Verwenden Sie auch mehrzeilige Anweisungen oder bündeln Sie mehrere Anweisungen zu einer einzigen Transaktion. Verwenden Sie in Amazon Aurora globale Datenbanken anstelle der binären Protokollreplikation oder verwenden Sie die Aurora_binlog-Parameter.

---

Weitere Informationen

Erkenntnisse zur Amazon-RDS-Leistung nutzen

Arbeiten mit DB-Parametergruppen

Aurora-MySQL-Ereignisse