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 Meine SQL 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. Mein SQL Benutzer synch/mutex/innodb/fil_system_mutex wartet darauf, den gleichzeitigen Zugriff auf den Tablespace-Speicher-Cache zu kontrollieren.
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 gleichzeitiger Data Manipulation Language (DML) -Operationen, mit denen Daten in derselben Tabelle aktualisiert oder gelöscht werden.
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.
Um SQL Abfragen zu finden, die für eine hohe Auslastung verantwortlich sind
Melden Sie sich bei der an AWS Management Console und öffnen Sie die RDS Amazon-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 ausSQL.
In der Tabelle sind die SQL Abfragen aufgeführt, die für den Ladevorgang 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
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 zur Neuorganisation von Tabellen finden Sie unter OPTIMIZETABLEErklärung
