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/buf\$1pool\$1mutex
<a name="ams-waits.bufpoolmutex"></a>

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.

**Topics**
+ [Versioni del motore rilevanti](#ams-waits.bufpoolmutex.context.supported)
+ [Contesto](#ams-waits.bufpoolmutex.context)
+ [Probabili cause di aumento delle attese](#ams-waits.bufpoolmutex.causes)
+ [Azioni](#ams-waits.bufpoolmutex.actions)

## Versioni del motore rilevanti
<a name="ams-waits.bufpoolmutex.context.supported"></a>

Queste informazioni sull'evento di attesa sono supportate per le seguenti versioni del motore:
+ Aurora MySQL versione 2

## Contesto
<a name="ams-waits.bufpoolmutex.context"></a>

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](https://dev.mysql.com/doc/refman/5.7/en/monitor-innodb-mutex-waits-performance-schema.html) nella documentazione di MySQL.

## Probabili cause di aumento delle attese
<a name="ams-waits.bufpoolmutex.causes"></a>

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.

## Azioni
<a name="ams-waits.bufpoolmutex.actions"></a>

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

**Topics**
+ [Identificare le sessioni e le query che causano gli eventi](#ams-waits.bufpoolmutex.actions.identify)
+ [Utilizzo di Performance Insights](#ams-waits.bufpoolmutex.actions.action1)
+ [Crea repliche di Aurora](#ams-waits.bufpoolmutex.actions.action2)
+ [Analisi delle dimensioni del pool di buffer](#ams-waits.bufpoolmutex.actions.action3)
+ [Monitoraggio della cronologia di stato globale](#ams-waits.bufpoolmutex.actions.action4)

### Identificare le sessioni e le query che causano gli eventi
<a name="ams-waits.bufpoolmutex.actions.identify"></a>

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 Top SQL nella console di gestione AWS**

1. Aprire la console Amazon RDS all'indirizzo [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/).

1. Nel pannello di navigazione scegli **Approfondimenti sulle prestazioni**.

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

1. Nel grafico **Carico del database**, scegli **Dividi per attesa**.

1. 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 blog[Analizza i carichi di lavoro di Amazon Aurora MySQL con Performance Insights](https://aws.amazon.com/blogs/database/analyze-amazon-aurora-mysql-workloads-with-performance-insights/).

### Utilizzo di Performance Insights
<a name="ams-waits.bufpoolmutex.actions.action1"></a>

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
<a name="ams-waits.bufpoolmutex.actions.action2"></a>

È 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 [Dimensionamento automatico di Amazon Aurora con le repliche Aurora](Aurora.Integrating.AutoScaling.md).

### Analisi delle dimensioni del pool di buffer
<a name="ams-waits.bufpoolmutex.actions.action3"></a>

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_free`dovrebbe essere piccolo. Per ulteriori informazioni, consulta [Innodb\$1buffer\$1pool\$1wait\$1free](https://dev.mysql.com/doc/refman/5.7/en/server-status-variables.html#statvar_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
<a name="ams-waits.bufpoolmutex.actions.action4"></a>

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](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Appendix.MySQL.CommonDBATasks.html#Appendix.MySQL.CommonDBATasks.GoSH).

Puoi anche creare CloudWatch parametri Amazon personalizzati per monitorare le variabili di stato. Per ulteriori informazioni, consulta [Pubblicazione di parametri personalizzati](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/publishingMetrics.html).