synch/mutex/innodb/trx_sys_mutex - Amazon Aurora
Relevante Engine-VersionenKontextWahrscheinliche Ursachen für erhöhte WartezeitenAktionen

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/mutex/innodb/trx_sys_mutex

Dieses synch/mutex/innodb/trx_sys_mutex-Ereignis tritt auf, wenn eine hohe Datenbankaktivität mit einer großen Anzahl von Transaktionen besteht.

Relevante Engine-Versionen

Diese Warteereignisinformationen werden für die folgenden Engine-Versionen unterstützt:

  • Aurora Meine SQL Versionen 2 und 3

Kontext

Intern verwendet das InnoDB-Datenbankmodul die wiederholbare Lese-Isolationsstufe mit Snapshots, um Lesekonsistenz zu gewährleisten. Auf diese Weise erhalten Sie einen point-in-time Überblick über die Datenbank zum Zeitpunkt der Erstellung des Snapshots.

In InnoDB werden alle Änderungen auf die Datenbank angewendet, sobald sie eintreffen, unabhängig davon, ob sie festgeschrieben wurden. Dieser Ansatz bedeutet, dass ohne Multiversion-Parallelitätssteuerung (MVCC) alle Benutzer, die mit der Datenbank verbunden sind, alle Änderungen und die neuesten Zeilen sehen. Daher benötigt InnoDB eine Möglichkeit, die Änderungen zu verfolgen, um zu verstehen, was bei Bedarf zurückgesetzt werden soll.

Dazu verwendet InnoDB ein Transaktionssystem (trx_sys) zum Verfolgen von Snapshots. Das Transaktionssystem führt folgenden Aktionen:

  • Verfolgt die Transaktions-ID für jede Zeile in den Rückgängig-Protokollen.

  • Verwendet eine interne InnoDB-Struktur namensReadView, mit deren Hilfe identifiziert werden kann, welche Transaktionen für einen Snapshot sichtbar IDs sind.

Wahrscheinliche Ursachen für erhöhte Wartezeiten

Jeder Datenbankvorgang, der die konsistente und kontrollierte Verarbeitung (Erstellen, Lesen, Aktualisieren und Löschen) von Transaktionen erfordert, IDs generiert einen Aufruf von trx_sys an den Mutex.

Diese Aufrufe erfolgen innerhalb von drei Funktionen:

  • trx_sys_mutex_enter – Erzeugt den Mutex.

  • trx_sys_mutex_exit – Gibt den Mutex frei.

  • trx_sys_mutex_own – Testet, ob der Mutex im Besitz ist.

Die Instrumentierung des InnoDB-Leistungsschemas verfolgt alle trx_sys-Mutex-Aufrufe. Die Verfolgung umfasst unter anderem die Verwaltung von trx_sys beim Starten oder Herunterfahren der Datenbank, Rollback-Vorgänge, das Rückgängigmachen von Bereinigungen, den Zeilenlesezugriff und das Laden von Pufferpools. Eine hohe Datenbankaktivität mit einer großen Anzahl von Transaktionen führt dazu, dass synch/mutex/innodb/trx_sys_mutex unter den Top-Warteereignissen erscheint.

Weitere Informationen finden Sie unter Monitoring InnoDB Mutex Waits Using Performance Schema in der Dokumentation Meine. SQL

Aktionen

Abhängig von den Ursachen Ihres Warteereignisses empfehlen wir verschiedene Aktionen.

Identifizieren der Sitzungen und Abfragen, die die Ereignisse verursachen

Normalerweise weisen Datenbanken mit mäßiger bis erheblicher Last Warteereignisse auf. Die Warteereignisse sind möglicherweise akzeptabel, wenn die Leistung optimal ist. Wenn die Leistung nicht optimal ist, untersuchen Sie, wo die Datenbank die meiste Zeit verbringt. Schauen Sie sich die Warteereignisse an, die zur höchsten Belastung beitragen. Finden Sie heraus, ob Sie die Datenbank und die Anwendung optimieren können, um diese Ereignisse zu reduzieren.

Um das oberste SQL Diagramm in der AWS Management Console

  1. Öffnen Sie die RDS Amazon-Konsole unter https://console.aws.amazon.com/rds/.

  2. Wählen Sie im Navigationsbereich Performance-Insights aus.

  3. Wählen Sie eine DB-Instance aus. Das Performance-Insights-Dashboard wird für diese DB-Instance angezeigt.

  4. Wählen Sie im Diagramm zur Datenbanklast die Option Nach Wartezeit aufteilen.

  5. Wählen Sie unter dem Diagramm zum Laden der Datenbank die Option Top ausSQL.

    In der Tabelle sind die SQL Abfragen aufgeführt, die für die Belastung 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 Blogbeitrag Analysieren Sie Amazon Aurora My SQL Workloads with Performance Insights.

Untersuchen Sie andere Warteereignisse

Untersuchen Sie die anderen Warteereignisse, die dem synch/mutex/innodb/trx_sys_mutex-Warteereignis zugeordnet sind. Auf diese Weise finden Sie weitere Informationen über die Art der Workload. Eine große Anzahl von Transaktionen kann den Durchsatz verringern, die Workload kann dies jedoch auch erforderlich machen.

Weitere Informationen zur Optimierung von Transaktionen finden Sie unter Optimieren des InnoDB-Transaktionsmanagements in der SQL Dokumentation Meine.