Aurora-MySQL-Warteereignisse

Es folgen verschiedene typische Warteereignisse für Aurora MySQL.

Anmerkung

Informationen zur Optimierung der Leistung von Aurora MySQL mithilfe von Warteereignissen finden Sie unter Optimieren von Aurora MySQL mit Warteereignissen.

Informationen zu den in MySQL-Warteereignissen geltenden Namenskonventionen finden Sie unter Performance Schema Instrument Naming Conventions in der MySQL-Dokumentation.

cpu: Die Anzahl der aktiven Verbindungen, die betriebsbereit sind, ist durchweg höher als die Anzahl von CPUs v. Weitere Informationen finden Sie untercpu.
io/aurora_redo_log_flush: Eine Sitzung enthält Daten für den Aurora-Speicher. Typischerweise bezieht sich dieses Warteereignis auf eine Schreib-I/O-Operation in Aurora MySQL. Weitere Informationen finden Sie unter io/aurora_redo_log_flush.
io/aurora_respond_to_client: Die Abfrageverarbeitung ist abgeschlossen und die Ergebnisse werden für die folgenden Aurora-MySQL-Version an den Anwendungs-Client zurückgegeben: 2.10.2 und höhere 2.10-Versionen, 2.09.3 und höhere 2.09-Versionen, 2.07.7 und höhere 2.07-Versionen. Vergleichen Sie die Netzwerkbandbreite der DB-Instance-Klasse mit der Größe der zurückgegebenen Ergebnismenge. Überprüfen Sie auch clientseitige Reaktionszeiten. Wenn der Client nicht reagiert und die TCP-Pakete nicht verarbeiten kann, können Paketabfälle und TCP-Neuübertragungen auftreten. Diese Situation wirkt sich negativ auf die Netzwerkbandbreite aus. In Versionen vor 2.10.2, 2.09.3 und 2.07.7 enthält das Warteereignis fälschlicherweise die Leerlaufzeit. Um zu erfahren, wie Sie Ihre Datenbank optimieren, wenn diese Wartezeit im Vordergrund steht, lesen Sie io/aurora_respond_to_client.
io/file/csv/data: Threads schreiben in Tabellen im CSV-Format (Comma-Separated Value). Prüfen Sie die Auslastung der CSV-Tabellen. Eine typische Ursache für dieses Ereignis ist die Einstellung log_output auf einer Tabelle.
io/file/sql/binlog: Ein Thread wartet auf eine binäre Protokoll-Datei (binlog), die auf den Datenträger geschrieben wird.
io/redo_log_flush: Eine Sitzung enthält Daten für den Aurora-Speicher. In der Regel bezieht sich dieses Warteereignis auf einen I/O Schreibvorgang in Aurora MySQL. Weitere Informationen finden Sie unter io/redo_log_flush.
io/socket/sql/client_Verbindung: Das Programm mysqld ist damit beschäftigt, Threads zu erstellen, um eingehende neue Client-Verbindungen zu verarbeiten. Weitere Informationen finden Sie unter io/socket/sql/client_connection.
io/table/sql/handler: Der Motor wartet auf Zugang zu einer Tabelle. Dieses Ereignis tritt unabhängig davon auf, ob die Daten im Pufferpool zwischengespeichert oder auf der Festplatte zugegriffen werden. Weitere Informationen finden Sie unter io/table/sql/handler.
lock/table/sql/handler: Dieses Warteereignis ist ein Warteereignis-Handler für Tabellensperren. Weitere Informationen zu Atom- und Molekülereignissen im Leistungsschema finden Sie unter Leistungsschema-Atom- und Molekülereignisse in der MySQL-Dokumentation.
synch/cond/innodb/row_lock_wait: Mehrere DML-Anweisungen (DML = Data Manipulation Language) greifen gleichzeitig auf dieselben Datenbankzeilen zu. Weitere Informationen finden Sie unter synch/cond/innodb/row_lock_wait.
synch/cond/innodb/row_lock_wait_cond: Mehrere DML-Anweisungen greifen gleichzeitig auf dieselben Datenbankzeilen zu. Weitere Informationen finden Sie unter synch/cond/innodb/row_lock_wait_cond.
synch/cond/sql/MDL_context: :cond_wait_status: Threads warten auf eine Tabellen-Metadatensperre. Die Engine verwendet diese Art von Sperre, um den gleichzeitigen Zugriff auf ein Datenbankschema zu verwalten und die Datenkonsistenz sicherzustellen. Weitere Informationen finden Sie unter Optimizing Locking Operations in der MySQL-Dokumentation. Um zu erfahren, wie Sie Ihre Datenbank optimieren, wenn dieses Ereignis im Vordergrund steht, lesen Sie synch/cond/sql/MDL_context::COND_wait_status.
synch/cond/sql/MYSQL_BIN_LOG: :cond_DONE: Sie haben die binäre Protokollierung aktiviert. Es kann einen hohen Commit-Durchsatz, eine große Anzahl von Transaktionen oder Replikate geben, die Binlogs lesen. Erwägen Sie, mehrzeilige Anweisungen zu verwenden oder Anweisungen in einer Transaktion zu bündeln. Verwenden Sie in Aurora globale Datenbanken anstelle der Binärprotokollreplikation oder verwenden Sie die Parameter aurora_binlog_*.
synch/mutex/innodb/aurora_lock_thread_slot_futex: Mehrere DML-Anweisungen greifen gleichzeitig auf dieselben Datenbankzeilen zu. Weitere Informationen finden Sie unter synch/mutex/innodb/aurora_lock_thread_slot_futex.
synch/mutex/innodb/buf_pool_mutex: Der Puffer-Pool ist nicht groß genug, um den Arbeitsdatensatz zu speichern. Oder die Workload greift auf Seiten aus einer bestimmten Tabelle zu, was zu Konflikten im Pufferpool führt. Weitere Informationen finden Sie unter synch/mutex/innodb/buf_pool_mutex.
synch/mutex/innodb/fil_system_mutex: Der Prozess wartet auf den Zugriff auf den Tablespace-Speicher-Cache. Weitere Informationen finden Sie unter synch/mutex/innodb/fil_system_mutex.
synch/mutex/innodb/trx_sys_mutex: Operationen sind das Überprüfen, Aktualisieren, Löschen oder Hinzufügen von Transaktionen IDs in InnoDB auf konsistente oder kontrollierte Weise. Diese Vorgänge erfordern einen trx_sys-Mutex-Aufruf, der von der Leistungs-Schema-Instrumentierung verfolgt wird. Zu den Vorgängen gehören die Verwaltung des Transaktionssystems beim Starten oder Herunterfahren der Datenbank, Rollbacks, Rückgängig-Bereinigungen, Zeilen-Lesezugriff und Pufferpool-Lasten. Eine hohe Datenbanklast bei einer großen Anzahl von Transaktionen führt zum häufigen Auftreten dieses Wait-Ereignisses. Weitere Informationen finden Sie unter synch/mutex/innodb/trx_sys_mutex.
synch/mutex/mysys/KEY_CACHE: :cache_lock: Der keycache->cache_lock-Mutex steuert den Zugriff auf den Schlüsselcache für MyISAM-Tabellen. Aurora MySQL erlaubt zwar keine MyISAM-Tabellen zum Speichern persistenter Daten, diese werden jedoch zum Speichern interner temporärer Tabellen verwendet. Prüfen Sie ggf. die Statuszähler created_tmp_tables oder created_tmp_disk_tables, da in bestimmten Situationen temporäre Tabellen auf die Festplatte geschrieben werden, wenn sie nicht mehr in den Speicher passen.
synch/mutex/sql/FILE_AS_TABLE: :Lock_Offsets: Die Engine erwirbt diesen Mutex beim Öffnen oder Erstellen eines Tabellen-Metadatenarchivs. Wenn dieses Warteereignis mit übermäßiger Häufigkeit auftritt, ist die Anzahl der erstellten oder geöffneten Tabellen gestiegen.
synch/mutex/sql/FILE_AS_TABLE: :Lock_SHIM_LISTS: Die Engine ruft diesen Mutex ab, während sie Vorgänge wie reset_size, detach_contents oder add_contents an der internen Struktur durchführt, die geöffnete Tabellen verfolgt. Der Mutex synchronisiert den Zugriff auf den Listeninhalt. Wenn dieses Warteereignis mit hoher Frequenz auftritt, deutet dies auf eine plötzliche Änderung des Tabellensatzes hin, auf die zuvor zugegriffen wurde. Die Engine muss auf neue Tabellen zugreifen oder den Kontext, der sich auf zuvor aufgerufene Tabellen bezieht, loslassen.
synch/mutex/sql/LOCK_öffnen: Die Anzahl der Tabellen, die Ihre Sitzungen öffnen, überschreitet die Größe des Tabellendefinitions-Caches oder des Caches zum Öffnen der Tabelle. Erhöhen Sie die Größe dieser Caches. Weitere Informationen finden Sie unter How MySQL Opens and Closes Tables.
synch/mutex/sql/LOCK_Tabellencache: Die Anzahl der Tabellen, die Ihre Sitzungen öffnen, überschreitet die Größe des Tabellendefinitions-Caches oder des Caches zum Öffnen der Tabelle. Erhöhen Sie die Größe dieser Caches. Weitere Informationen finden Sie unter How MySQL Opens and Closes Tables.
synch/mutex/sql/LOG: Bei diesem Warteereignis warten Threads auf eine Protokollsperre. Beispiel: Ein Thread wartet auf eine Sperre, um in die Slow-Query-Protokolldatei zu schreiben.
synch/mutex/sql/MYSQL_BIN_LOG: :Lock_Commit: Bei diesem Warteereignis wartet ein Thread auf eine Sperre, um Daten in das Binärprotokoll schreiben zu können. Konflikte in der Binärprotokollierung können bei Datenbanken mit sehr hoher Änderungsrate auftreten. In Abhängigkeit von der MySQL-Version werden verschiedene Sperren verwendet, um Konsistenz und Haltbarkeit des Binärprotokolls zu schützen. In RDS für MySQL werden Binärprotokolle für die Replikation und für automatische Sicherungen verwendet. In Aurora MySQL werden keine Binärprotokolle für die native Replikation und für Sicherungen benötigt. Sie sind standardmäßig deaktiviert, können aber aktiviert und für die externe Replikation oder die Erfassung von Änderungsdaten genutzt werden. Weitere Informationen finden Sie unter The Binary Log in der MySQL-Dokumentation.
sync/mutex/sql/MYSQL_BIN_LOG: :Lock_Dump_Thread_Metrics_Collection: Wenn die binäre Protokollierung aktiviert ist, erwirbt die Engine diesen Mutex, wenn sie aktive Dump-Thread-Metriken an das Engine-Fehlerprotokoll und in die interne Vorgangs-Mappe druckt.
sync/mutex/sql/MYSQL_BIN_LOG: :Lock_Inactive_BinLogs_Map: Wenn die binäre Protokollierung aktiviert ist, erwirbt die Engine diesen Mutex, wenn sie die Liste der Binlog-Datei hinter der neuesten hinzufügt, sie löscht oder durchsucht.
sync/mutex/sql/MYSQL_BIN_LOG: :IO_Cache sperren: Wenn die binäre Protokollierung aktiviert ist, erwirbt die Engine diesen Mutex während der Aurora-Binlog-IO-Cache-Vorgänge: Zuweisen, Größe ändern, freigeben, schreiben, lesen, löschen und auf Cache-Informationen zugreifen. Wenn dieses Ereignis häufig auftritt, greift die Engine auf den Cache zu, in dem Binlog-Ereignisse gespeichert werden. Um Wartezeiten zu reduzieren, reduzieren Sie Commits. Versuchen Sie, mehrere Anweisungen in einer einzigen Transaktion zu gruppieren.
synch/mutex/sql/MYSQL_BIN_LOG: :LOG SPERREN: Sie haben die binäre Protokollierung aktiviert. Möglicherweise gibt es einen hohen Commit-Durchsatz, viele Transaktionen oder Replikate, die Binlogs lesen. Erwägen Sie, mehrzeilige Anweisungen zu verwenden oder Anweisungen in einer Transaktion zu bündeln. Verwenden Sie in Aurora globale Datenbanken anstelle der Binärprotokollreplikation oder verwenden Sie die Parameter aurora_binlog_*.
synch/mutex/sql/SERVER_THREAD: :LOCK_SYNC: Der SERVER_THREAD::LOCK_sync-Mutex wird während des Planens, Verarbeitens oder Startens von Threads für Dateischreibvorgänge erfasst. Das übermäßige Auftreten dieses Wait-Ereignisses weist auf eine erhöhte Schreibaktivität in der Datenbank hin.
synch/mutex/sql/TABLESPACES_THREAD: :lock_sync ----sep----:sperren: Die Engine ruft den TABLESPACES:lock-Mutex während der folgenden Tablespace-Vorgänge ab: erstellen, löschen, abschneiden und erweitern. Das übermäßige Auftreten dieses Wait-Ereignisses weist auf eine hohe Häufigkeit von Tablespace-Vorgänge hin. Ein Beispiel ist das Laden einer großen Datenmenge in die Datenbank.
synch/rwlock/innodb/dict: Bei diesem Warteereignis warten Threads auf eine rwlock, die für das InnoDB-Datenwörterbuch gesetzt ist.
synch/rwlock/innodb/dict_operation_lock: Bei diesem Warteereignis warten Threads auf Sperren, die für InnoDB-Datenwörterbuch-Operationen gesetzt sind.
synch/rwlock/innodb/dictsys-RW-Sperre: Eine große Anzahl gleichzeitiger Datensteuerungs-Sprachanweisungen (DCLs) im Datendefinitionssprachencode (DDLs) wird gleichzeitig ausgelöst. Reduzieren Sie die Abhängigkeit der Anwendung DDLs während der regulären Anwendungsaktivität.
synch/rwlock/innodb/index_tree_rw_lock: Eine große Anzahl ähnlicher DML-Anweisungen (Data Manipulation Language) greift gleichzeitig auf dasselbe Datenbankobjekt zu. Versuchen Sie es mit mehrreihigen Anweisungen. Verteilen Sie die Workload auch auf verschiedene Datenbankobjekte. Implementieren Sie beispielsweise die Partitionierung.
synch/sxlock/innodb/dict_Betriebssperre: Eine große Anzahl gleichzeitiger Datensteuerungs-Sprachanweisungen (DCLs) im Datendefinitionssprachencode (DDLs) wird gleichzeitig ausgelöst. Reduzieren Sie die Abhängigkeit der Anwendung DDLs während der regulären Anwendungsaktivität.
synch/sxlock/innodb/dict_sys_lock: Eine große Anzahl gleichzeitiger Datensteuerungs-Sprachanweisungen (DCLs) im Datendefinitionssprachencode (DDLs) wird gleichzeitig ausgelöst. Reduzieren Sie die Abhängigkeit der Anwendung DDLs während der regulären Anwendungsaktivität.
synch/sxlock/innodb/hash_table_locks: Die Sitzung konnte keine Seiten im Puffer-Pool finden. Die Engine muss entweder eine Datei lesen oder die zuletzt verwendete Liste (LRU) für den Pufferpool ändern. Erwägen Sie, die Puffer-Cache-Größe zu erhöhen und die Zugriffspfade für die entsprechenden Abfragen
synch/sxlock/innodb/index_tree_rw_lock: Viele ähnliche DML-Anweisungen (DML = Data Manipulation Language) greifen gleichzeitig auf dasselbe Datenbankobjekt zu. Versuchen Sie es mit mehrreihigen Anweisungen. Verteilen Sie die Workload auch auf verschiedene Datenbankobjekte. Implementieren Sie beispielsweise die Partitionierung.
synch/mutex/innodb/temp_poolmanager_mutex: Dieses Wartungsereignis tritt auf, wenn eine Sitzung darauf wartet, einen Mutex für die Verwaltung des Pools temporärer Sitzungs-Tablespaces zu erhalten.

Weitere Informationen zur Fehlerbehebung bei Synchronisierungs-Warteereignissen finden Sie unter Warum zeigt meine MySQL-DB-Instance eine hohe Anzahl aktiver Sitzungen an, die auf SYNCH-Warteereignisse in Performance Insights warten?.

Warnung JavaScript ist in Ihrem Browser nicht verfügbar oder deaktiviert.

Zur Nutzung der AWS-Dokumentation muss JavaScript aktiviert sein. Weitere Informationen finden auf den Hilfe-Seiten Ihres Browsers.

Dokumentkonventionen

Globale Statusvariablen

Thread-Zustände