synch/mutex/innodb/buf_pool_mutex

L’evento synch/mutex/innodb/buf_pool_mutex si verifica quando un thread ha acquisito un blocco nel pool di buffer InnoDB per accedere a una pagina in memoria.

Versioni del motore rilevanti

Queste informazioni sull'evento di attesa sono supportate per le seguenti versioni del motore:

• Aurora MySQL versione 2

Context

La mutex buf_pool è una mutex singola che protegge le strutture di dati di controllo del pool di buffer.

Per ulteriori informazioni, consulta Monitoraggio delle attese di Mutex di InnoDB utilizzando lo schema delle prestazioni nella documentazione di MySQL.

Probabili cause di aumento delle attese

Si tratta di un evento di attesa specifico per il carico di lavoro. Cause comuni perché synch/mutex/innodb/buf_pool_mutex appaia tra i primi eventi di attesa includono quanto segue:

• Le dimensioni del pool di buffer non sono abbastanza grandi da contenere la serie di dati funzionante.

• Il carico di lavoro è più specifico per determinate pagine di una tabella specifica del database, causando contese nel pool di buffer.

Operazioni

Consigliamo azioni diverse a seconda delle cause dell'evento di attesa.

Identificare le sessioni e le query che causano gli eventi

In genere, i database con carico da moderato a significativo hanno eventi di attesa. Gli eventi di attesa possono essere accettabili se le prestazioni sono ottimali. Se le prestazioni non sono ottimali, esaminare dove il database impiega più tempo. Considerare gli eventi di attesa che contribuiscono al carico più elevato per scoprire se è possibile ottimizzare il database e l'applicazione per ridurre tali eventi.

Per visualizzare il grafico SQL principale nella Console di gestione AWS

1. Apri la console Amazon RDS all'indirizzo https://console.aws.amazon.com/rds/.

2. Nel pannello di navigazione scegli Performance Insights.

3. Scegli un'istanza database. Viene visualizzato il pannello di controllo di Approfondimenti sulle prestazioni per l'istanza database.

4. Nel grafico Carico del database, scegli Dividi per attesa.

5. Sotto il grafico Carico del database, seleziona Prime istruzioni SQL.

   Il grafico elenca le query di SQL responsabili del carico. Quelli in cima all'elenco sono le più responsabili. Per risolvere un collo di bottiglia, occorre concentrarsi su queste istruzioni.

Per una panoramica utile dell’identificazione e della risoluzione dei problemi con Performance Insights, consulta il post del blogAnalizza i carichi di lavoro di Amazon Aurora MySQL con Performance Insights.

Utilizzo di Performance Insights

Questo evento è correlato al carico di lavoro. È possibile utilizzare Performance Insights per effettuare quanto segue:

• Identificare l'avvio degli eventi di attesa e se c'è qualche modifica nel carico di lavoro in quel periodo dai registri dell'applicazione o dalle origini correlate.

• Identificare le istruzioni SQL responsabili di questo evento di attesa. Esaminare il piano di esecuzione delle query per accertarsi che queste query siano ottimizzate e utilizzino indici appropriati.

  Se le query principali responsabili dell'evento di attesa sono correlate allo stesso oggetto o tabella di database, prendere in considerazione il partizionamento dell'oggetto o della tabella.

Crea repliche di Aurora

È possibile creare repliche di Aurora per gestire il traffico di sola lettura. È inoltre possibile utilizzare Auto Scaling di Aurora per gestire le sovratensioni nel traffico di lettura. Assicurarsi di eseguire attività di sola lettura pianificate e backup logici sulle repliche di Aurora.

Per ulteriori informazioni, consulta Utilizzo del dimensionamento automatico di Amazon Aurora con le repliche Aurora.

Analisi delle dimensioni del pool di buffer

Verificare se la dimensione del pool di buffer è sufficiente per il carico di lavoro esaminando il parametro innodb_buffer_pool_wait_free. Se il valore di questo parametro è alto e aumenta continuamente, ciò indica che la dimensione del pool di buffer non è sufficiente per gestire il carico di lavoro. Se innodb_buffer_pool_size è stato impostato correttamente, il valore di innodb_buffer_pool_wait_freedovrebbe essere piccolo. Per ulteriori informazioni, consulta Innodb_buffer_pool_wait_free nella documentazione di MySQL.

Aumentare le dimensioni del pool di buffer se l'istanza database dispone di memoria sufficiente per i buffer di sessione e le attività del sistema operativo. In caso contrario, modificare l'istanza database in una classe di istanza database più grande per ottenere memoria aggiuntiva che può essere allocata al pool di buffer.

Nota

Aurora MySQL regola automaticamente il valore di innodb_buffer_pool_instances basato sul configurato innodb_buffer_pool_size.

Monitoraggio della cronologia di stato globale

Monitorando i tassi di modifica delle variabili di stato, è possibile rilevare problemi di blocco o di memoria sull'istanza database. Attivare Global Status History (GoSH) se non è già attivo. Per ulteriori informazioni su GoSH, consulta Gestione della cronologia di stato globale.

Puoi anche creare parametri personalizzati di Amazon CloudWatch per monitorare le variabili di stato. Per ulteriori informazioni, consulta Pubblicazione di parametri personalizzati.