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/fil_system_mutex
Dieses synch/mutex/innodb/fil_system_mutex-Ereignis tritt auf, wenn eine Sitzung darauf wartet, auf den Tablespace-Speichercache zuzugreifen.
Unterstützte Engine-Versionen
Diese Warteereignisinformationen werden für die folgenden Engine-Versionen unterstützt:
-
Aurora-MySQL-Versionen 2 und 3
Kontext
InnoDB verwendet Tablespaces, um den Speicherbereich für Tabellen und Protokolldateien zu verwalten. Der Tablespace-Speichercache ist eine globale Speicherstruktur, die Informationen über Tablespaces verwaltet. MySQL verwendet synch/mutex/innodb/fil_system_mutex Wartezeiten, um den gleichzeitigen Zugriff auf den Tablespace-Speichercache zu steuern.
Das Ereignis synch/mutex/innodb/fil_system_mutex zeigt an, dass derzeit mehr als eine Operation vorhanden ist, die Informationen im Tabellenbereichsspeichercache für denselben Tabellenbereich abrufen und bearbeiten muss.
Wahrscheinliche Ursachen für erhöhte Wartezeiten
Wenn das synch/mutex/innodb/fil_system_mutex-Ereignis mehr als normal auftritt, was möglicherweise auf ein Leistungsproblem hinweist, tritt dies normalerweise auf, wenn alle der folgenden Bedingungen vorliegen:
Eine Zunahme der gleichzeitigen DML-Vorgänge (Data Manipulation Language), die Daten in derselben Tabelle aktualisieren oder löschen.
Der Tablespace für diese Tabelle ist sehr groß und hat viele Datenseiten.
Der Füllfaktor für diese Datenseiten ist niedrig.
Aktionen
Abhängig von den Ursachen Ihres Warteereignisses empfehlen wir verschiedene Aktionen.
Themen
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 und finden Sie heraus, ob Sie die Datenbank und die Anwendung optimieren können, um diese Ereignisse zu reduzieren.
So suchen Sie SQL-Abfragen, die für hohe Last verantwortlich sind
Melden Sie sich bei der AWS Management Console an und öffnen Sie die Amazon-RDS-Konsole unter https://console.aws.amazon.com/rds/
. -
Wählen Sie im Navigationsbereich Performance-Insights aus.
-
Wählen Sie eine DB-Instance aus. Das Performance-Insights-Dashboard wird für diese DB-Instance angezeigt.
-
Wählen Sie im Diagramm zur Datenbanklast die Option Nach Wartezeit aufteilen.
-
Wählen Sie unten auf der Seite 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
Eine andere Möglichkeit herauszufinden, welche Abfragen eine hohe Anzahl von synch/mutex/innodb/fil_system_mutex-Wartezeiten verursachen, besteht darin, performance_schema zu überprüfen, wie im folgenden Beispiel.
mysql> select * from performance_schema.events_waits_current where EVENT_NAME='wait/synch/mutex/innodb/fil_system_mutex'\G *************************** 1. row *************************** THREAD_ID: 19 EVENT_ID: 195057 END_EVENT_ID: 195057 EVENT_NAME: wait/synch/mutex/innodb/fil_system_mutex SOURCE: fil0fil.cc:6700 TIMER_START: 1010146190118400 TIMER_END: 1010146196524000 TIMER_WAIT: 6405600 SPINS: NULL OBJECT_SCHEMA: NULL OBJECT_NAME: NULL INDEX_NAME: NULL OBJECT_TYPE: NULL OBJECT_INSTANCE_BEGIN: 47285552262176 NESTING_EVENT_ID: NULL NESTING_EVENT_TYPE: NULL OPERATION: lock NUMBER_OF_BYTES: NULL FLAGS: NULL *************************** 2. row *************************** THREAD_ID: 23 EVENT_ID: 5480 END_EVENT_ID: 5480 EVENT_NAME: wait/synch/mutex/innodb/fil_system_mutex SOURCE: fil0fil.cc:5906 TIMER_START: 995269979908800 TIMER_END: 995269980159200 TIMER_WAIT: 250400 SPINS: NULL OBJECT_SCHEMA: NULL OBJECT_NAME: NULL INDEX_NAME: NULL OBJECT_TYPE: NULL OBJECT_INSTANCE_BEGIN: 47285552262176 NESTING_EVENT_ID: NULL NESTING_EVENT_TYPE: NULL OPERATION: lock NUMBER_OF_BYTES: NULL FLAGS: NULL *************************** 3. row *************************** THREAD_ID: 55 EVENT_ID: 23233794 END_EVENT_ID: NULL EVENT_NAME: wait/synch/mutex/innodb/fil_system_mutex SOURCE: fil0fil.cc:449 TIMER_START: 1010492125341600 TIMER_END: 1010494304900000 TIMER_WAIT: 2179558400 SPINS: NULL OBJECT_SCHEMA: NULL OBJECT_NAME: NULL INDEX_NAME: NULL OBJECT_TYPE: NULL OBJECT_INSTANCE_BEGIN: 47285552262176 NESTING_EVENT_ID: 23233786 NESTING_EVENT_TYPE: WAIT OPERATION: lock NUMBER_OF_BYTES: NULL FLAGS: NULL
Reorganisieren Sie große Tabellen außerhalb der Hauptverkehrszeiten
Reorganisieren Sie große Tabellen, die Sie während eines Wartungsfensters außerhalb der Produktionszeiten als Quelle einer großen Anzahl von synch/mutex/innodb/fil_system_mutex-Warteereignissen identifizieren. Dadurch wird sichergestellt, dass die Bereinigung der internen Tablespaces-Zuordnung nicht erfolgt, wenn der schnelle Zugriff auf die Tabelle kritisch ist. Informationen zum Reorganisieren von Tabellen finden Sie unter OPTIMIZE TABLE-Anweisung
