synch/mutex/innodb/temp_poolmanager_mutex - Amazon Aurora
Unterstützte 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/temp_poolmanager_mutex

Das synch/mutex/innodb/temp_pool_manager_mutex Wait-Ereignis tritt ein, wenn eine Sitzung darauf wartet, einen Mutex für die Verwaltung des Pools temporärer Sitzungs-Tablespaces zu erhalten.

Unterstützte Engine-Versionen

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

  • Aurora-MySQL-Version 3

Kontext

Aurora MySQL Version 3.x und höher steuert mehrere Sitzungentemp_pool_manager_mutex, die gleichzeitig auf den temporären Tablespace-Pool zugreifen. Aurora MySQL verwaltet Speicher über ein Aurora-Cluster-Volume für persistente Daten und lokalen Speicher für temporäre Dateien. Ein temporärer Tablespace wird benötigt, wenn eine Sitzung eine temporäre Tabelle auf dem Aurora-Cluster-Volume erstellt.

Wenn eine Sitzung zum ersten Mal einen temporären Tablespace anfordert, weist MySQL temporäre Sitzungs-Tablespaces aus dem Shared Pool zu. Eine Sitzung kann bis zu 2 temporäre Tablespaces gleichzeitig für die folgenden Tabellentypen enthalten:

  • Vom Benutzer erstellte temporäre Tabellen

  • Von Optimizer generierte interne temporäre Tabellen

Die TempTable Standard-Engine verwendet den folgenden Überlaufmechanismus, um temporäre Tabellen zu verarbeiten:

  • Speichert Tabellen im RAM bis zum temptable_max_ramLimit.

  • Wechselt zu Dateien im lokalen Speicher, die dem Arbeitsspeicher zugeordnet sind, wenn der Arbeitsspeicher voll ist.

  • Verwendet das gemeinsam genutzte Cluster-Volume, wenn die Speicherzuordnungsdateien ihr Limit erreichen. temptable_max_mmap

Wenn temporäre Tabellen sowohl die RAM- als auch die lokalen Speichergrenzen überschreiten, verwaltet MySQL sie mithilfe von Tablespace auf der Festplatte.

Wenn für eine Sitzung eine temporäre Tabelle auf der Festplatte erforderlich ist, kann MySQL:

  • Sucht nach verfügbaren INACTIVE Tablespaces im Pool, die wiederverwendet werden können.

  • Erzeugt 10 neue Tablespaces, wenn keine Leerzeichen vorhanden sind. INACTIVE

Wenn eine Sitzung unterbrochen wird, geht MySQL wie folgt vor:

  • Kürzt die temporären Tablespaces der Sitzung.

  • Markiert sie im Pool zur Wiederverwendung als INAKTIV.

  • Behält die aktuelle Poolgröße bis zum Neustart des Servers bei.

  • Kehrt nach dem Neustart zur Standard-Poolgröße (10 Tablespaces) zurück.

Wahrscheinliche Ursachen für erhöhte Wartezeiten

Häufige Situationen, die dieses Warteereignis verursachen:

  • Gleichzeitige Sitzungen, die interne temporäre Tabellen auf dem Cluster-Volume erstellen.

  • Gleichzeitige Sitzungen, in denen temporäre Benutzertabellen auf dem Cluster-Volume erstellt werden.

  • Plötzliches Beenden von Sitzungen, die aktive Tablespaces verwenden.

  • Erweiterung des Tablespace-Pools bei hohen Schreiblasten.

  • Gleichzeitige Abfragen, auf die zugegriffen wird INFORMATION_SCHEMA.

Aktionen

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

Überwachen und optimieren Sie die Nutzung temporärer Tabellen

Verwenden Sie eine der folgenden Methoden, um die Nutzung temporärer Tabellen zu überwachen und zu optimieren:

  • Überprüfen Sie den Created_tmp_disk_tables Zähler in Performance Insights, um die Erstellung temporärer Tabellen auf der Festplatte in Ihrem Aurora-Cluster nachzuverfolgen.

  • Führen Sie diesen Befehl in Ihrer Datenbank aus, um die Erstellung temporärer Tabellen direkt zu überwachen:mysql> show status like '%created_tmp_disk%'.

Anmerkung

Das Verhalten temporärer Tabellen unterscheidet sich zwischen Aurora MySQL-Reader-Knoten und Writer-Knoten. Weitere Informationen finden Sie unter Neues temporäres Tabellenverhalten in Aurora-MySQL-Version 3.

Nachdem Sie Abfragen identifiziert haben, die temporäre Tabellen erstellen, führen Sie die folgenden Optimierungsschritte durch:

  • Wird verwendetEXPLAIN, um Ausführungspläne für Abfragen zu untersuchen und zu ermitteln, wo und warum temporäre Tabellen erstellt werden.

  • Ändern Sie Abfragen, um die Verwendung temporärer Tabellen nach Möglichkeit zu reduzieren.

Wenn Leistungsprobleme durch Abfrageoptimierung allein nicht behoben werden können, sollten Sie die folgenden Konfigurationsparameter anpassen:

  • temptable_max_ram- Steuert die maximale RAM-Auslastung für temporäre Tabellen.

  • temptable_max_mmap- Legt das Limit für die Speicherung von Dateien mit Speicherabbildung fest.

  • tmp_table_size- Gilt, wenn aurora_tmptable_enable_per_table_limit aktiviert (standardmäßig deaktiviert).

Wichtig

Beachten Sie, dass für bestimmte Abfragebedingungen immer temporäre Tabellen auf der Festplatte erforderlich sind, unabhängig von den Konfigurationseinstellungen. Weitere Informationen zur TempTable Speicher-Engine finden Sie unter Verwenden der TempTable Speicher-Engine auf Amazon RDS for MySQL und Amazon Aurora MySQL.

Überprüfen Sie Abfragen mit INFORMATION_SCHEMA

Wenn Sie INFORMATION_SCHEMA Tabellen abfragen, erstellt MySQL temporäre InnoDB-Tabellen auf dem Cluster-Volume. Jede Sitzung benötigt einen temporären Tablespace für diese Tabellen, was bei vielen gleichzeitigen Zugriffen zu Leistungseinbußen führen kann.

Um die Leistung zu verbessern:

  • Verwenden Sie PERFORMANCE_SCHEMA statt INFORMATION_SCHEMA wo möglich.

  • Wenn Sie diese Abfragen verwenden müssenINFORMATION_SCHEMA, reduzieren Sie die Häufigkeit, mit der Sie diese Abfragen ausführen.

Erhöhen Sie den Parameter innodb_sync_array_size

Der innodb_sync_array_size Parameter steuert die Größe des mutex/lock Warte-Arrays in MySQL. Der Standardwert von 1 funktioniert für allgemeine Workloads, aber wenn Sie ihn erhöhen, können Thread-Konflikte bei hoher Parallelität reduziert werden.

Wenn Ihre Arbeitslast eine zunehmende Anzahl wartender Threads aufweist:

  • Überwachen Sie die Anzahl der wartenden Threads in Ihrem Workload.

  • Legen Sie den innodb_sync_array_size Wert gleich oder höher als die vCPU-Anzahl Ihrer Instance fest, um die Thread-Koordinationsstruktur aufzuteilen und Konflikte zu reduzieren.

Anmerkung

Informationen zur Anzahl der auf Ihrer RDS-Instance CPUs verfügbaren v finden Sie in den vCPU-Spezifikationen unter Amazon RDS-Instance-Typen.

Verbindungspooling implementieren

MySQL weist jeder Sitzung, die eine temporäre Tabelle erstellt, einen eigenen Tablespace zu. Dieser Tablespace bleibt aktiv, bis die Datenbankverbindung beendet wird. Gehen Sie wie folgt vor, um Ihre Ressourcen effizienter zu verwalten:

  • Implementieren Sie Verbindungspooling, um die Anzahl der aktiven temporären Tablespaces zu begrenzen.

  • Verwenden Sie bestehende Verbindungen wieder, anstatt für jeden Vorgang neue zu erstellen.