Veranstaltungen rund um Aurora My SQL Wait

Die Anzahl der aktiven Verbindungen, die betriebsbereit sind, ist durchweg höher als die Anzahl vonvCPUs. Weitere Informationen finden Sie unter cpu.

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/aurora_redo_log_flush.

Die Abfrageverarbeitung wurde abgeschlossen und die Ergebnisse werden für die folgenden Aurora SQL My-Versionen an den Anwendungsclient zurückgegeben: 2.10.2 und höher 2.10-Versionen, 2.09.3 und höhere 2.09-Versionen und 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 Pakete nicht verarbeiten kann, kann es zu Paketverlusten und erneuten Übertragungen kommenTCP. TCP 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.

Threads schreiben in Tabellen im kommagetrennten Wertformat (). CSV Überprüfen Sie Ihre CSV Tabellennutzung. Eine typische Ursache für dieses Ereignis ist die Einstellung log_output auf einer Tabelle.

Ein Thread wartet auf eine binäre Protokoll-Datei (binlog), die auf den Datenträger geschrieben wird.

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.

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.

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.

Dieses Warteereignis ist ein Warteereignis-Handler für Tabellensperren. Weitere Informationen zu Atom- und Molekülereignissen im Leistungsschema finden Sie in der SQL Dokumentation Meine Dokumentation unter Leistungsschema — Atom- und Molekülereignisse.

Mehrere Data Manipulation Language (DML) -Anweisungen greifen gleichzeitig auf dieselben Datenbankzeilen zu. Weitere Informationen finden Sie unter synch/cond/innodb/row_lock_wait.

Mehrere DML Anweisungen greifen gleichzeitig auf dieselben Datenbankzeilen zu. Weitere Informationen finden Sie unter synch/cond/innodb/row_lock_wait_cond.

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 in der Dokumentation Meine Dokumentation unter Optimieren von Sperrvorgängen. SQL Um zu erfahren, wie Sie Ihre Datenbank optimieren, wenn dieses Ereignis im Vordergrund steht, lesen Sie synch/cond/sql/MDL_context::COND_wait_status.

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_*.

Mehrere DML Anweisungen greifen gleichzeitig auf dieselben Datenbankzeilen zu. Weitere Informationen finden Sie unter synch/mutex/innodb/aurora_lock_thread_slot_futex.

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.

Der Prozess wartet auf den Zugriff auf den Tablespace-Speicher-Cache. Weitere Informationen finden Sie unter synch/mutex/innodb/fil_system_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.

Der keycache->cache_lock Mutex steuert den Zugriff auf den Schlüssel-Cache für Meine Tabellen. ISAM Aurora My erlaubt zwar SQL nicht, Meine ISAM Tabellen zum Speichern persistenter Daten zu verwenden, sie 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.

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.

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.

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 So öffnet und schließt My Tabellen. SQL

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 So öffnet und schließt My Tabellen. SQL

Bei diesem Warteereignis warten Threads auf eine Protokollsperre. Beispiel: Ein Thread wartet auf eine Sperre, um in die Slow-Query-Protokolldatei zu schreiben.

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. Abhängig von Ihrer Version von My werden bestimmte Sperren verwendetSQL, um die Konsistenz und Beständigkeit des Binärprotokolls zu schützen. In RDS for My SQL werden Binärprotokolle für die Replikation und den automatisierten Backup-Prozess verwendet. In Aurora My SQL werden Binärprotokolle nicht für native Replikation oder Backups 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 Das Binärprotokoll in der SQL Dokumentation My.

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.

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.

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.

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_*.

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.

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.

Bei diesem Warteereignis warten Threads auf eine rwlock, die für das InnoDB-Datenwörterbuch gesetzt ist.

Bei diesem Warteereignis warten Threads auf Sperren, die für InnoDB-Datenwörterbuch-Operationen gesetzt sind.

Eine große Anzahl gleichzeitiger Datensteuerungs-Sprachanweisungen (DCLs) im Datendefinitionssprachencode () wird gleichzeitig ausgelöst. DDLs Reduzieren Sie die Abhängigkeit der Anwendung DDLs während der regulären Anwendungsaktivität.

Eine große Anzahl ähnlicher Data Manipulation Language (DML) -Anweisungen 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.

Eine große Anzahl gleichzeitiger Datensteuerungssprachenanweisungen (DCLs) im Datendefinitionssprachencode (DDLs) wird gleichzeitig ausgelöst. Reduzieren Sie die Abhängigkeit der Anwendung DDLs während der regulären Anwendungsaktivität.

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.

Die Sitzung konnte keine Seiten im Puffer-Pool finden. Die Engine muss entweder eine Datei lesen oder die Liste der zuletzt verwendeten Dateien (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

Viele ähnliche Data Manipulation Language (DML) -Anweisungen 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.