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-MySQL-Versionen 2 und 3

Kontext

Intern verwendet das InnoDB-Datenbankmodul die wiederholbare Lese-Isolationsstufe mit Snapshots, um Lesekonsistenz zu gewährleisten. Dies gibt Ihnen eine zeitpunktbezogene Ansicht der 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 Multiversions-Parallelitätssteuerung (MVCC) alle mit der Datenbank verbundenen Benutzer 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 namens ReadView, die hilft zu identifizieren, welche Transaktions-IDs für einen Snapshot sichtbar sind.

Wahrscheinliche Ursachen für erhöhte Wartezeiten

Jede Datenbankoperation, die eine konsistente und kontrollierte Behandlung (Erstellen, Lesen, Aktualisieren und Löschen) von Transaktions-IDs erfordert, erzeugt 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 Überwachen von InnoDB-Mutex-Wartezeiten mithilfe des Leistungsschemas in der MySQL-Dokumentation.

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.

So zeigen Sie das Top-SQL-Diagramm in AWS Management Console an

1. Öffnen Sie die Amazon-RDS-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 Datenbankauslastungsdiagramm die Option Top-SQL aus.

   Das Diagramm listet die SQL-Abfragen auf, 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.

Eine nützliche Übersicht über die Fehlerbehebung mit Performance Insights finden Sie im Blogbeitrag Analysieren Sie Amazon Aurora MySQL Workloads mit 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 zum Optimieren von Transaktionen finden Sie unter Optimieren der InnoDB-Transaktionsverwaltung in der MySQL-Dokumentation.