Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.
synch/mutex/innodb/temp_pool_manager_mutex
L'evento synch/mutex/innodb/temp_pool_manager_mutex wait si verifica quando una sessione è in attesa di acquisire un mutex per la gestione del pool di tablespace temporanee della sessione.
Versioni del motore supportate
Queste informazioni sull'evento di attesa sono supportate per le seguenti versioni del motore:
-
Aurora MySQL versione 3
Contesto
Aurora MySQL versione 3.x e successive consente di controllare più sessioni che accedono temp_pool_manager_mutex al pool di tablespace temporaneo contemporaneamente. Aurora MySQL gestisce l'archiviazione tramite un volume cluster Aurora per i dati persistenti e l'archiviazione locale per i file temporanei. Un tablespace temporaneo è necessario quando una sessione crea una tabella temporanea sul volume del cluster Aurora.
Quando una sessione richiede per la prima volta un tablespace temporaneo, MySQL alloca tablespace temporanei della sessione dal pool condiviso. Una sessione può contenere fino a 2 tablespace temporanee alla volta per i seguenti tipi di tabelle:
Tabelle temporanee create dall'utente
Tabelle temporanee interne generate dall'ottimizzatore
Il TempTable motore predefinito utilizza il seguente meccanismo di overflow per gestire le tabelle temporanee:
-
Memorizza le tabelle nella RAM fino al
temptable_max_ramlimite. -
Passa ai file mappati in memoria nella memoria locale quando la RAM è piena.
-
Utilizza il volume condiviso del cluster quando i file mappati in memoria raggiungono il limite.
temptable_max_mmap
Dopo che le tabelle temporanee superano i limiti di RAM e di archiviazione locale, MySQL le gestisce utilizzando tablespace su disco.
Quando una sessione richiede una tabella temporanea su disco, MySQL:
-
Cerca i
INACTIVEtablespace disponibili nel pool da riutilizzare. -
Crea 10 nuove tablespace se non esistono spazi.
INACTIVE
Quando una sessione si disconnette, MySQL:
-
Tronca i tablespace temporanei della sessione.
-
Le contrassegna come INATTIVE nel pool per il riutilizzo.
-
Mantiene la dimensione attuale del pool fino al riavvio del server.
-
Ritorna alla dimensione predefinita del pool (10 tablespace) dopo il riavvio.
Probabili cause di aumento delle attese
Situazioni comuni che causano questo evento di attesa:
Sessioni simultanee che creano tabelle temporanee interne sul volume del cluster.
Sessioni simultanee che creano tabelle temporanee utente sul volume del cluster.
Interruzione improvvisa delle sessioni utilizzando tablespace attivi.
Espansione del pool di tablespace durante carichi di lavoro di scrittura pesanti.
Accesso simultaneo alle interrogazioni
INFORMATION_SCHEMA.
Azioni
Consigliamo azioni diverse a seconda delle cause dell’evento di attesa.
Argomenti
Monitora e ottimizza l'utilizzo temporaneo delle tabelle
Per monitorare e ottimizzare l'utilizzo delle tabelle temporanee, utilizzate uno di questi metodi:
-
Controlla il
Created_tmp_disk_tablescontatore in Performance Insights per tenere traccia della creazione di tabelle temporanee su disco nel cluster Aurora. -
Esegui questo comando nel tuo database per monitorare direttamente la creazione di tabelle temporanee:.
mysql> show status like '%created_tmp_disk%'
Nota
Il comportamento delle tabelle temporanee differisce tra i nodi reader MySQL di Aurora e i nodi writer. Per ulteriori informazioni, consulta Nuovo comportamento della tabella temporanea in Aurora MySQL versione 3.
Dopo aver identificato le query che creano tabelle temporanee, esegui questi passaggi di ottimizzazione:
-
EXPLAINUtilizzatelo per esaminare i piani di esecuzione delle query e identificare dove e perché vengono create le tabelle temporanee. -
Modifica le query per ridurre l'utilizzo temporaneo delle tabelle, ove possibile.
Se l'ottimizzazione delle query da sola non risolve i problemi di prestazioni, valuta la possibilità di modificare questi parametri di configurazione:
-
temptable_max_ram- Controlla l'utilizzo massimo della RAM per le tabelle temporanee. -
temptable_max_mmap- Imposta il limite per l'archiviazione di file mappati in memoria. -
tmp_table_size- Si applica quando aurora_tmptable_enable_per_table_limitè abilitato (disabilitato per impostazione predefinita).
Importante
Tieni presente che alcune condizioni di interrogazione richiederanno sempre tabelle temporanee su disco, indipendentemente dalle impostazioni di configurazione. Per ulteriori informazioni sul motore TempTable di storage, consulta Utilizzare il motore TempTable di storage su Amazon RDS for MySQL e Amazon Aurora MySQL
Esamina le query utilizzando INFORMATION_SCHEMA
Quando si interrogano INFORMATION_SCHEMA le tabelle, MySQL crea tabelle temporanee InnoDB sul volume del cluster. Ogni sessione necessita di un tablespace temporaneo per queste tabelle, il che può portare a problemi di prestazioni in caso di accesso simultaneo elevato.
Per migliorare le prestazioni:
-
Usalo
PERFORMANCE_SCHEMAal posto diINFORMATION_SCHEMAdove possibile. -
Se necessario
INFORMATION_SCHEMA, riduci la frequenza con cui esegui queste query.
Aumenta il parametro innodb_sync_array_size
Il innodb_sync_array_size parametro controlla la dimensione dell'array di mutex/lock attesa in MySQL. Il valore predefinito di 1 funziona per carichi di lavoro generici, ma aumentandolo si può ridurre il conflitto di thread in caso di elevata concorrenza.
Quando il carico di lavoro mostra un numero crescente di thread in attesa:
-
Monitora il numero di thread in attesa nel tuo carico di lavoro.
-
Imposta un numero
innodb_sync_array_sizepari o superiore al numero di vCPU dell'istanza per suddividere la struttura di coordinamento dei thread e ridurre i conflitti.
Nota
Per determinare il numero di v CPUs disponibili sulla tua istanza RDS, consulta le specifiche vCPU nei tipi di istanze Amazon RDS
Implementa un pool di connessioni
MySQL assegna un tablespace dedicato a ogni sessione che crea una tabella temporanea. Questo tablespace rimane attivo fino al termine della connessione al database. Per gestire le risorse in modo più efficiente:
-
Implementa il pool di connessioni per limitare il numero di tablespace temporanee attive.
-
Riutilizza le connessioni esistenti invece di crearne di nuove per ogni operazione.