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/buf\$1pool\$1mutex
Dieses `synch/mutex/innodb/buf_pool_mutex`-Ereignis tritt ein, wenn ein Thread eine Sperre des InnoDB-Puffer-Pools für den Zugriff auf eine Seite im Speicher erworben hat.
**Topics**
+ [Relevante Engine-Versionen](#ams-waits.bufpoolmutex.context.supported)
+ [Kontext](#ams-waits.bufpoolmutex.context)
+ [Wahrscheinliche Ursachen für erhöhte Wartezeiten](#ams-waits.bufpoolmutex.causes)
+ [Aktionen](#ams-waits.bufpoolmutex.actions)
## Relevante Engine-Versionen
Diese Warteereignisinformationen werden für die folgenden Engine-Versionen unterstützt:
+ Aurora-MySQL-Version 2
## Kontext
Der `buf_pool`-Mutex ist ein einzelner Mutex, der die Kontrolldatenstrukturen des Pufferpools schützt.
Weitere Informationen finden Sie unter [Überwachen von InnoDB-Mutex-Wartezeiten mithilfe des Leistungsschemas](https://dev.mysql.com/doc/refman/5.7/en/monitor-innodb-mutex-waits-performance-schema.html) in der MySQL-Dokumentation.
## Wahrscheinliche Ursachen für erhöhte Wartezeiten
Dies ist ein Workload-spezifisches Warteereignis. Zu den häufigsten Ursachen für das Auftreten von `synch/mutex/innodb/buf_pool_mutex` unter den häufigsten Warteereignissen gehören die folgenden:
+ Die Pufferpoolgröße ist nicht groß genug, um den Arbeitsdatensatz zu speichern.
+ Die Workload ist für bestimmte Seiten einer bestimmten Tabelle in der Datenbank spezifischer, was zu Konflikten im Pufferpool führt.
## Aktionen
Abhängig von den Ursachen Ihres Warteereignisses empfehlen wir verschiedene Aktionen.
**Topics**
+ [Identifizieren der Sitzungen und Abfragen, die die Ereignisse verursachen](#ams-waits.bufpoolmutex.actions.identify)
+ [Performance Insights verwenden](#ams-waits.bufpoolmutex.actions.action1)
+ [Erstellen eines Aurora-Replikats](#ams-waits.bufpoolmutex.actions.action2)
+ [Überprüfen Sie die Größe des Pufferpools](#ams-waits.bufpoolmutex.actions.action3)
+ [Überwachen Sie den globalen Statusverlauf](#ams-waits.bufpoolmutex.actions.action4)
### 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 das Top-SQL-Diagramm in der Management Console anzuzeigen AWS**
1. Öffnen Sie die Amazon RDS-Konsole unter [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/).
1. Wählen Sie im Navigationsbereich **Performance-Insights** aus.
1. Wählen Sie eine DB-Instance aus. Das Performance-Insights-Dashboard wird für diese DB-Instance angezeigt.
1. Wählen Sie im Diagramm zur **Datenbanklast** die Option **Nach Wartezeit aufteilen**.
1. 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](https://aws.amazon.com/blogs/database/analyze-amazon-aurora-mysql-workloads-with-performance-insights/).
### Performance Insights verwenden
Dieses Ereignis hängt mit der Workload zusammen. Mit Performance Insights können Sie Folgendes tun:
+ Identifizieren Sie, wann Warteereignisse beginnen und ob sich die Workload zu dieser Zeit aus den Anwendungsprotokollen oder verwandten Quellen ändert.
+ Identifizieren Sie die SQL-Anweisungen, die für dieses Warteereignis verantwortlich sind. Untersuchen Sie den Ausführungsplan der Abfragen, um sicherzustellen, dass diese Abfragen optimiert sind und geeignete Indizes verwenden.
Wenn die obersten Abfragen, die für das Warteereignis verantwortlich sind, sich auf dasselbe Datenbankobjekt oder dieselbe Tabelle beziehen, sollten Sie erwägen, dieses Objekt oder die Tabelle zu partitionieren.
### Erstellen eines Aurora-Replikats
Sie können Aurora-Replikationen erstellen, um schreibgeschützten Datenverkehr bereitzustellen. Sie können Aurora Auto Scaling auch verwenden, um Überspannungen im Leseverkehr zu behandeln. Stellen Sie sicher, dass geplante schreibgeschützte Aufgaben und logische Backups auf Aurora-Replikaten ausgeführt werden.
Weitere Informationen finden Sie unter [Amazon-Aurora-Auto-Scaling mit Aurora-Replikaten](Aurora.Integrating.AutoScaling.md).
### Überprüfen Sie die Größe des Pufferpools
Prüfen Sie anhand der Metrik `innodb_buffer_pool_wait_free`, ob die Pufferpoolgröße für die Workload ausreicht. Wenn der Wert dieser Metrik hoch ist und kontinuierlich zunimmt, deutet dies darauf hin, dass die Größe des Pufferpools nicht ausreicht, um die Workload zu bewältigen. Wenn `innodb_buffer_pool_size` richtig eingestellt wurde, sollte der Wert von `innodb_buffer_pool_wait_free` klein sein. Weitere Informationen finden Sie unter [Innodb\$1buffer\$1pool\$1wait\$1free](https://dev.mysql.com/doc/refman/5.7/en/server-status-variables.html#statvar_Innodb_buffer_pool_wait_free) in der MySQL-Dokumentation.
Erhöhen Sie die Pufferpool-Größe, wenn die DB-Instance über genügend Speicher für Sitzungspuffer und Betriebssystemaufgaben verfügt. Wenn dies nicht der Fall ist, ändern Sie die DB-Instance in eine größere DB-Instance-Klasse, um zusätzlichen Speicher zu erhalten, der dem Pufferpool zugewiesen werden kann.
**Anmerkung**
Aurora MySQL passt den Wert von `innodb_buffer_pool_instances` automatisch basierend auf der konfigurierten `innodb_buffer_pool_size` an.
### Überwachen Sie den globalen Statusverlauf
Durch die Überwachung der Änderungsraten von Statusvariablen können Sie Sperr- oder Speicherprobleme auf Ihrer DB-Instance erkennen. Aktivieren Sie den globalen Statusverlauf (GoSH), wenn er noch nicht aktiviert ist. Weitere Informationen zu GoSH finden Sie unter [Verwalten des globalen Statusverlaufs](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Appendix.MySQL.CommonDBATasks.html#Appendix.MySQL.CommonDBATasks.GoSH).
Sie können auch benutzerdefinierte CloudWatch Amazon-Metriken erstellen, um Statusvariablen zu überwachen. Weitere Informationen finden Sie unter [Veröffentlichen benutzerdefinierter Metriken](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/publishingMetrics.html).