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à.
# Regolazione di Aurora MySQL con eventi di attesa
La tabella seguente riassume gli eventi di attesa di Aurora MySQL che più comunemente indicano problemi di prestazioni. I seguenti eventi di attesa sono un sottoinsieme dell'elenco in [Eventi di attesa Aurora MySQL](AuroraMySQL.Reference.Waitevents.md).
| Evento di attesa | Description |
| --- | --- |
| [cpu](ams-waits.cpu.md) | Questo evento si verifica quando un thread è attivo nella CPU o è in attesa della CPU. |
| [io/aurora\$1redo\$1log\$1flush](ams-waits.io-auredologflush.md) | Questo evento si verifica quando una sessione sta scrivendo dati permanenti nell'archiviazione di Aurora. |
| [io/aurora\$1respond\$1to\$1client](ams-waits.respond-to-client.md) | Questo evento si verifica quando un thread è in attesa di restituire una serie di risultati a un client. |
| [io/redo\$1log\$1flush](ams-waits.io-redologflush.md) | Questo evento si verifica quando una sessione sta scrivendo dati permanenti nell'archiviazione di Aurora. |
| [io/socket/sql/client\$1connessione](ams-waits.client-connection.md) | Questo evento si verifica quando un thread sta per gestire una nuova connessione. |
| [io/table/sql/handler](ams-waits.waitio.md) | Questo evento si verifica quando il lavoro è stato delegato a un motore di archiviazione. |
| [synch/cond/innodb/row\$1blocca\$1aspetta](ams-waits.row-lock-wait.md) | Questo evento si verifica quando una sessione ha bloccato una riga per un aggiornamento e un'altra sessione tenta di aggiornare la stessa riga. |
| [synch/cond/innodb/row\$1lock\$1wait\$1cond](ams-waits.row-lock-wait-cond.md) | Questo evento si verifica quando una sessione ha bloccato una riga per un aggiornamento e un'altra sessione tenta di aggiornare la stessa riga. |
| [synch/cond/sql/MDL\$1contesto: :COND\$1WAIT\$1STATUS](ams-waits.cond-wait-status.md) | Questo evento si verifica quando ci sono thread in attesa del blocco dei metadati di una tabella. |
| [synch/mutex/innodb/aurora\$1lock\$1thread\$1slot\$1futex](ams-waits.waitsynch.md) | Questo evento si verifica quando una sessione ha bloccato una riga per un aggiornamento e un'altra sessione tenta di aggiornare la stessa riga. |
| [synch/mutex/innodb/buf\$1pool\$1mutex](ams-waits.bufpoolmutex.md) | Questo evento si verifica quando un thread ha acquisito un blocco nel pool di buffer InnoDB per accedere a una pagina in memoria. |
| [synch/mutex/innodb/fil\$1sistema\$1mutex](ams-waits.innodb-fil-system-mutex.md) | Questo evento si verifica quando una sessione è in attesa di accedere alla cache di memoria del tablespace. |
| [synch/mutex/innodb/trx\$1sys\$1mutex](ams-waits.trxsysmutex.md) | Questo evento si verifica quando c'è un'elevata attività del database con un numero elevato di transazioni. |
| [synch/sxlock/innodb/hash\$1table\$1locks](ams-waits.sx-lock-hash-table-locks.md) | Questo evento si verifica quando le pagine non trovate nel pool del buffer devono essere lette da un file. |
| [synch/mutex/innodb/temp\$1pool\$1manager\$1mutex](ams-waits.io-temppoolmanager.md) | Questo evento si verifica quando una sessione è in attesa di acquisire un mutex per la gestione del pool di tablespace temporanee della sessione. |
# cpu
L’evento di attesa `cpu` si verifica quando un thread è attivo nella CPU o è in attesa della CPU.
**Topics**
+ [Versioni del motore supportate](#ams-waits.cpu.context.supported)
+ [Contesto](#ams-waits.cpu.context)
+ [Probabili cause di aumento delle attese](#ams-waits.cpu.causes)
+ [Azioni](#ams-waits.cpu.actions)
## Versioni del motore supportate
Queste informazioni sull'evento di attesa sono supportate per le seguenti versioni del motore:
+ Aurora MySQL versioni 2 e 3
## Contesto
Per ogni vCPU, una connessione può eseguire operazioni su questa CPU. In alcune situazioni, il numero di connessioni attive pronte per l'esecuzione è superiore al numero di vCPUs. Questo squilibrio fa sì che le connessioni attendano le risorse della CPU. Se il numero di connessioni attive rimane costantemente superiore al numero di vCPUs, l'istanza presenta un conflitto di CPU. La contesa provoca il verificarsi dell’evento di attesa `cpu`.
**Nota**
Il parametro di Performance Insights per la CPU è `DBLoadCPU`. Il valore per `DBLoadCPU` può differire dal valore della CloudWatch metrica`CPUUtilization`. Quest'ultima metrica viene raccolta da HyperVisor per un'istanza di database.
I parametri del sistema operativo del Performance Insights forniscono informazioni dettagliate sull'utilizzo della CPU. Ad esempio, puoi visualizzare i seguenti parametri:
+ `os.cpuUtilization.nice.avg`
+ `os.cpuUtilization.total.avg`
+ `os.cpuUtilization.wait.avg`
+ `os.cpuUtilization.idle.avg`
Performance Insights segnala l'utilizzo della CPU da parte del motore del database come `os.cpuUtilization.nice.avg`.
## Probabili cause di aumento delle attese
Quando questo evento si verifica più del normale, eventualmente indicando un problema di prestazioni, le cause tipiche includono le seguenti:
+ Query analitiche
+ Transazioni altamente simultanee
+ Transazioni di lunga durata
+ Un improvviso aumento del numero di connessioni, noto come *storm di login*
+ Un aumento del cambio di contesto
## Azioni
Se l’evento di attesa `cpu` domina l'attività del database, non indica necessariamente un problema di prestazioni. Rispondi a questo evento solo quando le prestazioni diminuiscono.
A seconda della causa dell'aumento dell'utilizzo della CPU, considerare le seguenti strategie:
+ Aumenta la capacità della CPU dell'host. Questo approccio tipicamente offre un sollievo temporaneo.
+ Identifica le principali query per una potenziale ottimizzazione.
+ Reindirizza alcuni carichi di lavoro di sola lettura verso i nodi del lettore, se applicabile.
**Topics**
+ [Identifica le sessioni o le query che causano il problema](#ams-waits.cpu.actions.az-vpc-subnet)
+ [Analizza e ottimizza l'elevato carico di lavoro della CPU](#ams-waits.cpu.actions.db-instance-class)
### Identifica le sessioni o le query che causano il problema
Per trovare le sessioni e le query, guarda la tabella **Prime istruzioni SQL** in Performance Insights per le istruzioni SQL che hanno il carico più alto della CPU. Per ulteriori informazioni, consulta [Analisi delle metriche utilizzando il pannello di controllo Performance Insights](USER_PerfInsights.UsingDashboard.md).
In genere, una o due istruzioni SQL consumano la maggior parte dei cicli della CPU. Concentra gli sforzi su queste istruzioni. Supponiamo che l'istanza DB abbia 2 v CPUs con un carico DB di 3,1 sessioni attive medie (AAS), tutte nello stato della CPU. In questo caso, la tua istanza è associata alla CPU. Considera le strategie seguenti:
+ Esegui l'upgrade a una classe di istanze più grande con più vCPUs.
+ Regola le query per ridurre il carico della CPU.
In questo esempio, le query SQL principali hanno un carico del database di 1,5 AAS, il tutto nello stato della CPU. Un'altra istruzione SQL ha un carico di 0,1 nello stato della CPU. In questo esempio, se si è interrotta l'istruzione SQL con caricamento più basso, non si riduce in modo significativo il carico del database. Tuttavia, se si regolano le due query ad alto carico in modo che siano due volte più efficienti, si elimina il collo di bottiglia della CPU. Se si riduce il carico della CPU di 1,5 AAS del 50%, l'AAS per ogni istruzione diminuisce a 0,75. Il carico totale del databalse speso per la CPU è ora di 1,6 AAS. Questo valore è inferiore alla linea massima di vCPU 2.0.
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/). Consulta anche l'articolo di AWS supporto [Come posso risolvere i problemi e risolvere l'utilizzo elevato della CPU sulle mie istanze Amazon RDS for MySQL](https://aws.amazon.com/premiumsupport/knowledge-center/rds-instance-high-cpu/)? .
### Analizza e ottimizza l'elevato carico di lavoro della CPU
Dopo aver identificato la query o le query che aumentano l'utilizzo della CPU, è possibile ottimizzarle o terminare la connessione. L'esempio seguente mostra come terminare una connessione.
```
CALL mysql.rds_kill(processID);
```
Per ulteriori informazioni, consulta [mysql.rds\$1kill](mysql-stored-proc-ending.md#mysql_rds_kill).
Se si termina una sessione, l'azione potrebbe innescare un lungo ripristino dello stato precedente.
#### Seguire le linee guida per l'ottimizzazione delle query
Per ottimizzare le query, prendere in considerazione le seguenti linee guida:
+ Eseguire l’istruzione `EXPLAIN`.
Questo comando mostra i singoli passaggi coinvolti nell'esecuzione di una query. Per ulteriori informazioni, consulta [Ottimizzazione delle query con EXPLAIN](https://dev.mysql.com/doc/refman/5.7/en/using-explain.html) nella documentazione di MySQL.
+ Eseguire l’istruzione `SHOW PROFILE`.
Utilizzare questa istruzione per esaminare i dettagli del profilo che possono indicare l'utilizzo delle risorse per le istruzioni eseguite durante la sessione corrente. Per ulteriori informazioni, consulta [Istruzione REPAIR TABLE](https://dev.mysql.com/doc/refman/5.7/en/show-profile.html) nella documentazione di MySQL.
+ Eseguire l’istruzione `ANALYZE TABLE`.
Utilizzare questa istruzione per riaggiornare le statistiche di indice per le tabelle a cui si accede dalla query che consuma CPU elevata. Analizzando l'istruzione, è possibile aiutare l'ottimizzatore a scegliere un piano di esecuzione appropriato. Per ulteriori informazioni, consulta [Istruzione ANALYZE TABLE](https://dev.mysql.com/doc/refman/5.7/en/analyze-table.html) nella documentazione di MySQL.
#### Segui le linee guida per migliorare l'utilizzo della CPU
Per migliorare l'utilizzo della CPU in un'istanza database, attenersi a queste linee guida:
+ Assicurarsi che tutte le query utilizzino indici appropriati.
+ Scopri se è possibile utilizzare query parallele di Aurora. Si può usare questa tecnica per ridurre l'utilizzo della CPU sul nodo head grazie all'elaborazione della funzione di trasferimento, al filtraggio delle righe e alla proiezione delle colonne per la clausola `WHERE`.
+ Scopri se il numero di esecuzioni SQL al secondo soddisfa le soglie previste.
+ Scopri se la manutenzione dell'indice o la creazione di nuovi indici occupano i cicli della CPU necessari per il carico di lavoro di produzione. Pianifica le attività di manutenzione al di fuori degli orari del picco di attività.
+ Scopri se è possibile utilizzare il partizionamento per ridurre la serie dei dati delle query. Per ulteriori informazioni, consultare il post del blog.[Come pianificare e ottimizzare Amazon Aurora con compatibilità MySQL per carichi di lavoro consolidati](https://aws.amazon.com/blogs/database/planning-and-optimizing-amazon-aurora-with-mysql-compatibility-for-consolidated-workloads/).
#### Verifica la presenza di congestioni dovute alla connessione
Se il parametro `DBLoadCPU` non è molto alto, ma il parametro `CPUUtilization` è elevato, la causa dell’utilizzo elevato della CPU risiede al di fuori del motore del database. Un esempio classico è una congestione dovuta alla connessione.
Verificare se le condizioni seguenti sono vere:
+ C'è un aumento sia della metrica Performance Insights che della `CPUUtilization` CloudWatch `DatabaseConnections` metrica Amazon.
+ Il numero di thread nella CPU è maggiore del numero di v. CPUs
Se le condizioni precedenti sono vere, considerare di diminuire il numero di connessioni al database. Ad esempio, è possibile utilizzare un pool di connessione come RDS Proxy. Per conoscere le best practice per una gestione efficace delle connessioni e il dimensionamento, consulta il whitepaper [Manuale di Amazon Aurora MySQL DBA per la gestione delle connessioni](https://d1.awsstatic.com/whitepapers/RDS/amazon-aurora-mysql-database-administrator-handbook.pdf).
# io/aurora\$1redo\$1log\$1flush
L’evento `io/aurora_redo_log_flush` si verifica quando una sessione sta scrivendo dati persistenti nell’archiviazione di Amazon Aurora.
**Topics**
+ [Versioni del motore supportate](#ams-waits.io-auredologflush.context.supported)
+ [Contesto](#ams-waits.io-auredologflush.context)
+ [Probabili cause di aumento delle attese](#ams-waits.io-auredologflush.causes)
+ [Azioni](#ams-waits.io-auredologflush.actions)
## Versioni del motore supportate
Queste informazioni sull'evento di attesa sono supportate per le seguenti versioni del motore:
+ Aurora MySQL versione 2
## Contesto
L'`io/aurora_redo_log_flush`evento riguarda un'operazione di scrittura input/output (I/O) in Aurora MySQL.
**Nota**
Nella versione 3 di Aurora MySQL, questo evento di attesa è denominato [io/redo\$1log\$1flush.](ams-waits.io-redologflush.md)
## Probabili cause di aumento delle attese
Per la persistenza dei dati, l’esecuzione dei commit richiede una scrittura duratura per un’archiviazione stabile. Se il database esegue troppi commit, c'è un evento di attesa nell' I/O operazione di scrittura, l'evento wait. `io/aurora_redo_log_flush`
Negli esempi seguenti, 50.000 dati vengono inseriti in un cluster di database di Aurora MySQL utilizzando la classe di istanza database db.r5.xlarge:
+ Nel primo esempio, ogni sessione inserisce 10.000 dati riga per riga. Per impostazione predefinita, se un comando del linguaggio di manipolazione dei dati (DML) non si trova all’interno di una transazione, Aurora MySQL utilizza l’esecuzione di commit impliciti. Autocommit è attivo. Ciò significa che per ogni inserimento di riga è presente l’esecuzione di un commit. Performance Insights mostra che le connessioni dedicano la maggior parte del tempo in attesa dell’evento di attesa `io/aurora_redo_log_flush`.
![\[Esempio di Performance Insights dell’evento di attesa\]](http://docs.aws.amazon.com/it_it/AmazonRDS/latest/AuroraUserGuide/images/auredologflush_PI_example1.png)
Ciò è causato dalle semplici istruzioni di inserimento utilizzate.
![\[Inserisci istruzioni in Istruzioni SQL principali\]](http://docs.aws.amazon.com/it_it/AmazonRDS/latest/AuroraUserGuide/images/auredologflush_top_SQL1.png)
I 50.000 dati richiedono 3,5 minuti per essere inseriti.
+ Nel secondo esempio, gli inserti sono realizzati in 1.000 batch, ovvero ogni connessione esegue 10 commit anziché 10.000. Performance Insights mostra che le connessioni non dedicano la maggior parte del loro tempo sull’evento di attesa `io/aurora_redo_log_flush`.
![\[Esempio di Performance Insights dell’evento di attesa con minore impatto\]](http://docs.aws.amazon.com/it_it/AmazonRDS/latest/AuroraUserGuide/images/auredologflush_PI_example2.png)
I 50.000 dati richiedono 4 secondi per essere inseriti.
## Azioni
Consigliamo azioni diverse a seconda delle cause dell’evento di attesa.
**Topics**
+ [Identificare le sessioni e le query problematiche](#ams-waits.io-auredologflush.actions.identify-queries)
+ [Raggruppa le operazioni di scrittura](#ams-waits.io-auredologflush.actions.action0)
+ [Disattivazione dell'autocommit](#ams-waits.io-auredologflush.actions.action1)
+ [Transazioni di utilizzo](#ams-waits.io-auredologflush.action2)
+ [Utilizza i batch](#ams-waits.io-auredologflush.action3)
### Identificare le sessioni e le query problematiche
Se l'istanza database sta riscontrando un collo di bottiglia, il primo compito è quello di trovare le sessioni e le query che lo causano. Per un utile post sul blog AWS Database, consulta [Analizza i carichi di lavoro MySQL di Amazon Aurora](https://aws.amazon.com/blogs/database/analyze-amazon-aurora-mysql-workloads-with-performance-insights/) con Performance Insights.
**Per identificare sessioni e query che causano un collo di bottiglia**
1. Accedi a Console di gestione AWS e apri 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 l'istanza database.
1. In **Carico del database**, scegli **Dividi per attesa**.
1. Nella parte inferiore della pagina scegli **Prime Instruzioni SQL**.
Le query nella parte superiore dell'elenco causano il carico più alto sul database.
### Raggruppa le operazioni di scrittura
Gli esempi seguenti attivano l’evento di attesa `io/aurora_redo_log_flush`. (Autocommit è attivo.)
```
INSERT INTO `sampleDB`.`sampleTable` (sampleCol2, sampleCol3) VALUES ('xxxx','xxxxx');
INSERT INTO `sampleDB`.`sampleTable` (sampleCol2, sampleCol3) VALUES ('xxxx','xxxxx');
INSERT INTO `sampleDB`.`sampleTable` (sampleCol2, sampleCol3) VALUES ('xxxx','xxxxx');
....
INSERT INTO `sampleDB`.`sampleTable` (sampleCol2, sampleCol3) VALUES ('xxxx','xxxxx');
UPDATE `sampleDB`.`sampleTable` SET sampleCol3='xxxxx' WHERE id=xx;
UPDATE `sampleDB`.`sampleTable` SET sampleCol3='xxxxx' WHERE id=xx;
UPDATE `sampleDB`.`sampleTable` SET sampleCol3='xxxxx' WHERE id=xx;
....
UPDATE `sampleDB`.`sampleTable` SET sampleCol3='xxxxx' WHERE id=xx;
DELETE FROM `sampleDB`.`sampleTable` WHERE sampleCol1=xx;
DELETE FROM `sampleDB`.`sampleTable` WHERE sampleCol1=xx;
DELETE FROM `sampleDB`.`sampleTable` WHERE sampleCol1=xx;
....
DELETE FROM `sampleDB`.`sampleTable` WHERE sampleCol1=xx;
```
Per ridurre il tempo impiegato in attesa dell’evento di attesa `io/aurora_redo_log_flush`, raggruppa logicamente le operazioni di scrittura in una singola esecuzione di commit per ridurre le chiamate persistenti all’archiviazione.
### Disattivazione dell'autocommit
Disattivare l'autocommit prima di apportare modifiche di grandi dimensioni che non si trovano all'interno di una transazione, come illustrato nell'esempio seguente.
```
SET SESSION AUTOCOMMIT=OFF;
UPDATE `sampleDB`.`sampleTable` SET sampleCol3='xxxxx' WHERE sampleCol1=xx;
UPDATE `sampleDB`.`sampleTable` SET sampleCol3='xxxxx' WHERE sampleCol1=xx;
UPDATE `sampleDB`.`sampleTable` SET sampleCol3='xxxxx' WHERE sampleCol1=xx;
....
UPDATE `sampleDB`.`sampleTable` SET sampleCol3='xxxxx' WHERE sampleCol1=xx;
-- Other DML statements here
COMMIT;
SET SESSION AUTOCOMMIT=ON;
```
### Transazioni di utilizzo
È possibile utilizzare le transazioni, come illustrato nell'esempio seguente.
```
BEGIN
INSERT INTO `sampleDB`.`sampleTable` (sampleCol2, sampleCol3) VALUES ('xxxx','xxxxx');
INSERT INTO `sampleDB`.`sampleTable` (sampleCol2, sampleCol3) VALUES ('xxxx','xxxxx');
INSERT INTO `sampleDB`.`sampleTable` (sampleCol2, sampleCol3) VALUES ('xxxx','xxxxx');
....
INSERT INTO `sampleDB`.`sampleTable` (sampleCol2, sampleCol3) VALUES ('xxxx','xxxxx');
DELETE FROM `sampleDB`.`sampleTable` WHERE sampleCol1=xx;
DELETE FROM `sampleDB`.`sampleTable` WHERE sampleCol1=xx;
DELETE FROM `sampleDB`.`sampleTable` WHERE sampleCol1=xx;
....
DELETE FROM `sampleDB`.`sampleTable` WHERE sampleCol1=xx;
-- Other DML statements here
END
```
### Utilizza i batch
Si può anche apportare modifiche in batch, come nell'esempio seguente: Tuttavia, l'utilizzo di batch troppo grandi può causare problemi di prestazioni, specialmente nelle repliche di lettura o durante il point-in-time ripristino (PITR).
```
INSERT INTO `sampleDB`.`sampleTable` (sampleCol2, sampleCol3) VALUES
('xxxx','xxxxx'),('xxxx','xxxxx'),...,('xxxx','xxxxx'),('xxxx','xxxxx');
UPDATE `sampleDB`.`sampleTable` SET sampleCol3='xxxxx' WHERE sampleCol1 BETWEEN xx AND xxx;
DELETE FROM `sampleDB`.`sampleTable` WHERE sampleCol1
L’evento `io/aurora_respond_to_client` si verifica quando un thread è in attesa di restituire una serie di risultati a un client.
**Topics**
+ [Versioni del motore supportate](#ams-waits.respond-to-client.context.supported)
+ [Contesto](#ams-waits.respond-to-client.context)
+ [Probabili cause di aumento delle attese](#ams-waits.respond-to-client.causes)
+ [Azioni](#ams-waits.respond-to-client.actions)
## Versioni del motore supportate
Queste informazioni sull'evento di attesa sono supportate per le seguenti versioni del motore:
+ Aurora MySQL versione 2
## Contesto
L'evento `io/aurora_respond_to_client` indica che un thread è in attesa di restituire una serie di risultati a un client.
L'elaborazione della query è completa e i risultati vengono restituiti al client dell'applicazione. Tuttavia, poiché non c'è abbastanza larghezza di banda di rete nel cluster del database, un thread è in attesa di restituire la serie di risultati.
## Probabili cause di aumento delle attese
Quando l’evento `io/aurora_respond_to_client` appare più che normale, possibilmente indicando un problema di prestazioni, le cause tipiche includono le seguenti:
**Classe di istanza database insufficiente per il carico di lavoro**
La classe di istanza database utilizzata dal cluster del database non dispone della larghezza di banda di rete necessaria per elaborare il carico di lavoro in modo efficiente.
**Serie di risultati di grandi dimensioni**
Si è verificato un aumento delle dimensioni della serie di risultati restituiti, poiché la query restituisce un numero maggiore di righe. La serie di risultati più ampia consuma una maggiore larghezza di banda di rete.
**Aumento del carico sul client**
Potrebbe esserci pressione della CPU, pressione della memoria o saturazione della rete sul client. Un aumento del carico sul client ritarda la ricezione dei dati dal cluster del database di Aurora MySQL.
**Maggiore latenza di rete**
Potrebbe esserci una maggiore latenza di rete tra il cluster del databalse di Aurora MySQL e il client. Una maggiore latenza di rete aumenta il tempo necessario per il client per la ricezione dei dati.
## Azioni
Consigliamo azioni diverse a seconda delle cause dell’evento di attesa.
**Topics**
+ [Identificare le sessioni e le query che causano gli eventi](#ams-waits.respond-to-client.actions.identify)
+ [Dimensionamento della classe dell’istanza database](#ams-waits.respond-to-client.actions.scale-db-instance-class)
+ [Verifica del carico di lavoro per risultati imprevisti](#ams-waits.respond-to-client.actions.workload)
+ [Distribuisci il carico di lavoro con le istanze del lettore](#ams-waits.respond-to-client.actions.balance)
+ [Utilizzare il modificatore SQL\$1BUFFER\$1RESULT](#ams-waits.respond-to-client.actions.sql-buffer-result)
### Identificare le sessioni e le query che causano gli eventi
È possibile utilizzare Performance Insights per mostrare le query bloccate dall’evento di attesa `io/aurora_respond_to_client`. 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 trovare query di SQL responsabili del carico elevato**
1. Accedi a Console di gestione AWS e apri 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. Nella parte inferiore della pagina scegli **Prime Instruzioni 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 un'utile panoramica sulla risoluzione dei problemi con Performance Insights, consulta il post sul blog AWS Database [Analyze Amazon Aurora MySQL Workloads](https://aws.amazon.com/blogs/database/analyze-amazon-aurora-mysql-workloads-with-performance-insights/) with Performance Insights.
### Dimensionamento della classe dell’istanza database
Verifica l'aumento del valore delle CloudWatch metriche di Amazon relative al throughput di rete, ad esempio `NetworkReceiveThroughput` e. `NetworkTransmitThroughput` Se viene raggiunta la larghezza di banda di rete della classe di istanza database, è possibile dimensionare la classe di istanza database utilizzata dal cluster del database modificando il cluster del database. Una classe di istanze database con larghezza di banda di rete maggiore restituisce i dati ai client in modo più efficiente.
Per informazioni sul monitoraggio dei CloudWatch parametri di Amazon, consulta[Visualizzazione delle metriche nella console Amazon RDS](USER_Monitoring.md). Per informazioni sulle classi di istanza database, consulta [Classi di istanze DB Amazon Aurora](Concepts.DBInstanceClass.md). Per informazioni sulla modifica di un cluster di database, consulta [Modifica di un cluster database Amazon Aurora](Aurora.Modifying.md).
### Verifica del carico di lavoro per risultati imprevisti
Controlla il carico di lavoro sul cluster del database e assicurati che non produca risultati imprevisti. Ad esempio, potrebbero esserci query che restituiscono un numero di righe più alto del previsto. In questo caso, puoi utilizzare i parametri del contatore di Performance Insights come `Innodb_rows_read`. Per ulteriori informazioni, consulta [Metriche contatore di Performance Insights](USER_PerfInsights_Counters.md).
### Distribuisci il carico di lavoro con le istanze del lettore
È possibile distribuire il carico di lavoro di sola lettura con le repliche di Aurora. È possibile dimensionare orizzontalmente aggiungendo più repliche di Aurora. Ciò può comportare un aumento dei limiti per la larghezza di banda della rete. Per ulteriori informazioni, consulta [Cluster database Amazon Aurora](Aurora.Overview.md).
### Utilizzare il modificatore SQL\$1BUFFER\$1RESULT
Puoi aggiungere il modificatore `SQL_BUFFER_RESULT` alle istruzioni `SELECT` per forzare il risultato in una tabella temporanea prima che vengano restituite al client. Questo modificatore può aiutare a risolvere i problemi di prestazioni quando i blocchi InnoDB non vengono liberati perché le query sono presenti nello stato di attesa `io/aurora_respond_to_client`. Per ulteriori informazioni, consulta [Istruzione SELECT](https://dev.mysql.com/doc/refman/5.7/en/select.html) nella documentazione di MySQL.
# io/redo\$1log\$1flush
L’evento `io/redo_log_flush` si verifica quando una sessione sta scrivendo dati persistenti nell’archiviazione di Amazon Aurora.
**Topics**
+ [Versioni del motore supportate](#ams-waits.io-redologflush.context.supported)
+ [Contesto](#ams-waits.io-redologflush.context)
+ [Probabili cause di aumento delle attese](#ams-waits.io-redologflush.causes)
+ [Azioni](#ams-waits.io-redologflush.actions)
## Versioni del motore supportate
Queste informazioni sull'evento di attesa sono supportate per le seguenti versioni del motore:
+ Aurora MySQL versione 3
## Contesto
L'`io/redo_log_flush`evento riguarda un'operazione di scrittura input/output (I/O) in Aurora MySQL.
**Nota**
In Aurora MySQL versione 2, questo evento di attesa è denominato [io/aurora\$1redo\$1log\$1flush](ams-waits.io-auredologflush.md).
## Probabili cause di aumento delle attese
Per la persistenza dei dati, l’esecuzione dei commit richiede una scrittura duratura per un’archiviazione stabile. Se il database esegue troppi commit, c'è un evento di attesa nell' I/O operazione di scrittura, l'evento wait. `io/redo_log_flush`
Per esempi del comportamento di questo evento di attesa, consulta [io/aurora\$1redo\$1log\$1flush](ams-waits.io-auredologflush.md).
## Azioni
Consigliamo azioni diverse a seconda delle cause dell’evento di attesa.
**Topics**
+ [Identificare le sessioni e le query problematiche](#ams-waits.io-redologflush.actions.identify-queries)
+ [Raggruppa le operazioni di scrittura](#ams-waits.io-redologflush.actions.action0)
+ [Disattivazione dell'autocommit](#ams-waits.io-redologflush.actions.action1)
+ [Transazioni di utilizzo](#ams-waits.io-redologflush.action2)
+ [Utilizza i batch](#ams-waits.io-redologflush.action3)
### Identificare le sessioni e le query problematiche
Se l'istanza database sta riscontrando un collo di bottiglia, il primo compito è quello di trovare le sessioni e le query che lo causano. Per un utile post sul blog AWS Database, consulta [Analizza i carichi di lavoro MySQL di Amazon Aurora](https://aws.amazon.com/blogs/database/analyze-amazon-aurora-mysql-workloads-with-performance-insights/) con Performance Insights.
**Per identificare sessioni e query che causano un collo di bottiglia**
1. Accedi a Console di gestione AWS e apri 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 l'istanza database.
1. In **Carico del database**, scegli **Dividi per attesa**.
1. Nella parte inferiore della pagina scegli **Prime Instruzioni SQL**.
Le query nella parte superiore dell'elenco causano il carico più alto sul database.
### Raggruppa le operazioni di scrittura
Gli esempi seguenti attivano l’evento di attesa `io/redo_log_flush`. (Autocommit è attivo.)
```
INSERT INTO `sampleDB`.`sampleTable` (sampleCol2, sampleCol3) VALUES ('xxxx','xxxxx');
INSERT INTO `sampleDB`.`sampleTable` (sampleCol2, sampleCol3) VALUES ('xxxx','xxxxx');
INSERT INTO `sampleDB`.`sampleTable` (sampleCol2, sampleCol3) VALUES ('xxxx','xxxxx');
....
INSERT INTO `sampleDB`.`sampleTable` (sampleCol2, sampleCol3) VALUES ('xxxx','xxxxx');
UPDATE `sampleDB`.`sampleTable` SET sampleCol3='xxxxx' WHERE id=xx;
UPDATE `sampleDB`.`sampleTable` SET sampleCol3='xxxxx' WHERE id=xx;
UPDATE `sampleDB`.`sampleTable` SET sampleCol3='xxxxx' WHERE id=xx;
....
UPDATE `sampleDB`.`sampleTable` SET sampleCol3='xxxxx' WHERE id=xx;
DELETE FROM `sampleDB`.`sampleTable` WHERE sampleCol1=xx;
DELETE FROM `sampleDB`.`sampleTable` WHERE sampleCol1=xx;
DELETE FROM `sampleDB`.`sampleTable` WHERE sampleCol1=xx;
....
DELETE FROM `sampleDB`.`sampleTable` WHERE sampleCol1=xx;
```
Per ridurre il tempo impiegato in attesa dell’evento di attesa `io/redo_log_flush`, raggruppa logicamente le operazioni di scrittura in una singola esecuzione di commit per ridurre le chiamate persistenti all’archiviazione.
### Disattivazione dell'autocommit
Disattivare l'autocommit prima di apportare modifiche di grandi dimensioni che non si trovano all'interno di una transazione, come illustrato nell'esempio seguente.
```
SET SESSION AUTOCOMMIT=OFF;
UPDATE `sampleDB`.`sampleTable` SET sampleCol3='xxxxx' WHERE sampleCol1=xx;
UPDATE `sampleDB`.`sampleTable` SET sampleCol3='xxxxx' WHERE sampleCol1=xx;
UPDATE `sampleDB`.`sampleTable` SET sampleCol3='xxxxx' WHERE sampleCol1=xx;
....
UPDATE `sampleDB`.`sampleTable` SET sampleCol3='xxxxx' WHERE sampleCol1=xx;
-- Other DML statements here
COMMIT;
SET SESSION AUTOCOMMIT=ON;
```
### Transazioni di utilizzo
È possibile utilizzare le transazioni, come illustrato nell'esempio seguente.
```
BEGIN
INSERT INTO `sampleDB`.`sampleTable` (sampleCol2, sampleCol3) VALUES ('xxxx','xxxxx');
INSERT INTO `sampleDB`.`sampleTable` (sampleCol2, sampleCol3) VALUES ('xxxx','xxxxx');
INSERT INTO `sampleDB`.`sampleTable` (sampleCol2, sampleCol3) VALUES ('xxxx','xxxxx');
....
INSERT INTO `sampleDB`.`sampleTable` (sampleCol2, sampleCol3) VALUES ('xxxx','xxxxx');
DELETE FROM `sampleDB`.`sampleTable` WHERE sampleCol1=xx;
DELETE FROM `sampleDB`.`sampleTable` WHERE sampleCol1=xx;
DELETE FROM `sampleDB`.`sampleTable` WHERE sampleCol1=xx;
....
DELETE FROM `sampleDB`.`sampleTable` WHERE sampleCol1=xx;
-- Other DML statements here
END
```
### Utilizza i batch
Si può anche apportare modifiche in batch, come nell'esempio seguente: Tuttavia, l'utilizzo di batch troppo grandi può causare problemi di prestazioni, specialmente nelle repliche di lettura o durante il point-in-time ripristino (PITR).
```
INSERT INTO `sampleDB`.`sampleTable` (sampleCol2, sampleCol3) VALUES
('xxxx','xxxxx'),('xxxx','xxxxx'),...,('xxxx','xxxxx'),('xxxx','xxxxx');
UPDATE `sampleDB`.`sampleTable` SET sampleCol3='xxxxx' WHERE sampleCol1 BETWEEN xx AND xxx;
DELETE FROM `sampleDB`.`sampleTable` WHERE sampleCol1
L’evento `io/socket/sql/client_connection` si verifica quando un thread sta per gestire una nuova connessione.
**Topics**
+ [Versioni del motore supportate](#ams-waits.client-connection.context.supported)
+ [Contesto](#ams-waits.client-connection.context)
+ [Probabili cause di aumento delle attese](#ams-waits.client-connection.causes)
+ [Azioni](#ams-waits.client-connection.actions)
## Versioni del motore supportate
Queste informazioni sull'evento di attesa sono supportate per le seguenti versioni del motore:
+ Aurora MySQL versioni 2 e 3
## Contesto
L'evento `io/socket/sql/client_connection` indica che mysqld è impegnato a creare thread per gestire le nuove connessioni client in arrivo. In questo scenario, l'elaborazione della manutenzione delle nuove richieste di connessione client rallenta mentre le connessioni attendono l'assegnazione del thread. Per ulteriori informazioni, consulta [Server MySQL (mysqld)](AuroraMySQL.Managing.Tuning.concepts.md#AuroraMySQL.Managing.Tuning.concepts.processes.mysqld).
## Probabili cause di aumento delle attese
Quando questo evento si verifica più del normale, probabilmente indicando un problema di prestazioni, le cause tipiche includono le seguenti:
+ C'è un improvviso aumento delle nuove connessioni utente dall'applicazione alla istanza Amazon RDS.
+ L'istanza database non è in grado di elaborare nuove connessioni perché la rete, la CPU o la memoria sono state limitate.
## Azioni
Se `io/socket/sql/client_connection` domina l'attività del database, non indica necessariamente un problema di prestazioni. In un database che non è inattivo, un evento di attesa è sempre in primo piano. Agisci solo quando le prestazioni diminuiscono. Consigliamo azioni diverse a seconda delle cause dell'evento di attesa.
**Topics**
+ [Identificare le sessioni e le query problematiche](#ams-waits.client-connection.actions.identify-queries)
+ [Seguire le best practice per la gestione delle connessioni](#ams-waits.client-connection.actions.manage-connections)
+ [Dimensiona verso l’alto la tua istanza se le risorse vengono limitate](#ams-waits.client-connection.upgrade)
+ [Controlla i principali host e i migliori utenti](#ams-waits.client-connection.top-hosts)
+ [Interrogare le tabelle performance\$1schema](#ams-waits.client-connection.perf-schema)
+ [Controlla lo stato del thread delle query](#ams-waits.client-connection.thread-states)
+ [Verifica le tue richieste e le query](#ams-waits.client-connection.auditing)
+ [Crea pool delle connessioni al database](#ams-waits.client-connection.pooling)
### Identificare le sessioni e le query problematiche
Se l'istanza database sta riscontrando un collo di bottiglia, il primo compito è quello di trovare le sessioni e le query che lo causano. Per un utile post sul blog, consulta [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/).
**Per identificare sessioni e query che causano un collo di bottiglia**
1. Accedi a Console di gestione AWS e apri 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 l'istanza database.
1. In **Carico del database**, scegli **Dividi per attesa**.
1. Nella parte inferiore della pagina scegli **Prime Instruzioni SQL**.
Le query nella parte superiore dell'elenco causano il carico più alto sul database.
### Seguire le best practice per la gestione delle connessioni
Per gestire le tue connessioni, considera le seguenti strategie:
+ Utilizza il pooling di connessioni.
È possibile aumentare gradualmente il numero di connessioni secondo necessità. Per ulteriori informazioni, consulta il whitepaper [Manuale dell'amministratore del database di Amazon Aurora MySQL](https://d1.awsstatic.com/whitepapers/RDS/amazon-aurora-mysql-database-administrator-handbook.pdf).
+ Usa un nodo lettore per ridistribuire il traffico di sola lettura.
Per ulteriori informazioni, consultare [Repliche di Aurora](Aurora.Replication.md#Aurora.Replication.Replicas) e [Connessioni degli endpoint Amazon Aurora](Aurora.Overview.Endpoints.md).
### Dimensiona verso l’alto la tua istanza se le risorse vengono limitate
Cerca esempi di limitazione nelle seguenti risorse:
+ CPU
Controlla i CloudWatch parametri di Amazon per un utilizzo elevato della CPU.
+ Rete
Verifica la presenza di un aumento del valore delle CloudWatch metriche `network receive throughput` e. `network transmit throughput` Se l’istanza ha raggiunto il limite di larghezza di banda di rete per la classe di istanza, è consigliabile dimensionare verso l’alto l'istanza RDS a un tipo di classe di istanza superiore. Per ulteriori informazioni, consulta [Classi di istanze DB Amazon Aurora](Concepts.DBInstanceClass.md).
+ Memoria liberabile
Verifica la presenza di un calo della CloudWatch metrica`FreeableMemory`. Inoltre, prendi in considerazione l'attivazione del monitoraggio avanzato. Per ulteriori informazioni, consulta [Monitoraggio dei parametri del sistema operativo con il monitoraggio avanzato](USER_Monitoring.OS.md).
### Controlla i principali host e i migliori utenti
Usa Performance Insights per controllare i principali host e i migliori utenti. Per ulteriori informazioni, consulta [Analisi delle metriche utilizzando il pannello di controllo Performance Insights](USER_PerfInsights.UsingDashboard.md).
### Interrogare le tabelle performance\$1schema
Per ottenere un conteggio accurato delle connessioni correnti e totali, eseguire una query sulle tabelle `performance_schema`. Con questa tecnica, si identifica l'utente o l'host di origine responsabile della creazione di un numero elevato di connessioni. Ad esempio, interrogare le tabelle `performance_schema` come indicato di seguito.
```
SELECT * FROM performance_schema.accounts;
SELECT * FROM performance_schema.users;
SELECT * FROM performance_schema.hosts;
```
### Controlla lo stato del thread delle query
Se il problema relativo alle prestazioni è continuo, controlla lo stato del thread delle query. Nel client `mysql`, eseguire il comando seguente.
```
show processlist;
```
### Verifica le tue richieste e le query
Per verificare la natura delle richieste e delle interrogazioni provenienti dagli account utente, usa AuroraAurora MySQL Advanced Auditing. Per informazioni su come attivare l'auditing, consulta [Utilizzo dell'audit avanzato con un cluster di database Amazon Aurora MySQL](AuroraMySQL.Auditing.md).
### Crea pool delle connessioni al database
Valuta l'utilizzo di Amazon RDS Proxy per la gestione della connessione. Con RDS Proxy, è possibile consentire alle applicazioni di creare pool delle connessioni di database e condividerle per migliorare la loro capacità di dimensionamento. RDS Proxy rende le applicazioni più resilienti agli errori del database connettendosi automaticamente a un'istanza database di standby, mantenendo al contempo le connessioni delle applicazioni. Per ulteriori informazioni, consulta [Proxy Amazon RDS per Aurora](rds-proxy.md).
# io/table/sql/handler
L’evento `io/table/sql/handler` si verifica quando il lavoro è stato delegato a un motore di archiviazione.
**Topics**
+ [Versioni del motore supportate](#ams-waits.waitio.context.supported)
+ [Contesto](#ams-waits.waitio.context)
+ [Probabili cause di aumento delle attese](#ams-waits.waitio.causes)
+ [Azioni](#ams-waits.waitio.actions)
## Versioni del motore supportate
Queste informazioni sull'evento di attesa sono supportate per le seguenti versioni del motore:
+ Aurora MySQL versioni 2 e 3
## Contesto
L’evento `io/table` indica un’attesa per l’accesso a una tabella. Questo evento si verifica indipendentemente dal fatto che i dati siano memorizzati nella cache nel pool di buffer o se si acceda su disco. L’evento `io/table/sql/handler` indica un aumento dell’attività del carico di lavoro.
Un *handler* è una routine specializzata in un determinato tipo di dati o incentrata su determinate attività speciali. Ad esempio, un handler di eventi riceve e digerisce eventi e segnali dal sistema operativo o da un’interfaccia utente. Un handler di memoria esegue processi relativi alla memoria. Un handler di input di file è una funzione che riceve l’input di file ed esegue attività speciali sui dati, in base al contesto.
Visualizzazioni come `performance_schema.events_waits_current` spesso mostrano `io/table/sql/handler` quando l’attesa effettiva è un evento di attesa annidato come un blocco. Quando l’attesa effettiva non è `io/table/sql/handler`, Approfondimenti sulle prestazioni segnala l’evento di attesa annidato. Quando Performance Insights riporta`io/table/sql/handler`, rappresenta l'elaborazione della I/O richiesta da parte di InnoDB e non un evento di attesa annidato nascosto. Per ulteriori informazioni consulta [Performance Schema Atom and Molecule Events](https://dev.mysql.com/doc/refman/5.7/en/performance-schema-atom-molecule-events.html) nel *Manuale di riferimento di MySQL*.
L'`io/table/sql/handler`evento compare spesso tra gli eventi di maggiore attesa con I/O attese come. `io/aurora_redo_log_flush`
## Probabili cause di aumento delle attese
In Approfondimenti sulle prestazioni, picchi improvvisi nell’evento `io/table/sql/handler` indicano un aumento dell’attività del carico di lavoro. Aumento dell’attività significa un aumento dell’I/O.
Performance Insights filtra l'evento di nidificazione IDs e non segnala un'`io/table/sql/handler`attesa quando l'evento nidificato sottostante è un'attesa di blocco. Ad esempio, se l’evento causa principale è [synch/mutex/innodb/aurora\$1lock\$1thread\$1slot\$1futex](ams-waits.waitsynch.md), Approfondimenti sulle prestazioni visualizza questa attesa nei primi eventi di attesa e non `io/table/sql/handler`.
In visualizzazioni come `performance_schema.events_waits_current`, le attese di `io/table/sql/handler` spesso appaiono quando l’attesa effettiva è un evento di attesa annidato come un blocco. Quando l’attesa effettiva è diversa da `io/table/sql/handler`, Approfondimenti sulle prestazioni cerca l’attesa annidata e segnala l’attesa effettiva anziché `io/table/sql/handler`. Quando Approfondimenti sulle prestazioni segnala `io/table/sql/handler`, la vera attesa è `io/table/sql/handler` e non un evento di attesa annidato nascosto. Per ulteriori informazioni consulta [Performance Schema Atom and Molecule Events](https://dev.mysql.com/doc/refman/5.7/en/performance-schema-atom-molecule-events.html) nel *Manuale di riferimento di MySQL 5.7*.
## Azioni
Se l’evento di attesa domina l’attività del database, non indica necessariamente un problema di prestazioni. Un evento di attesa è sempre in primo piano quando il database è attivo. È necessario agire solo quando le prestazioni diminuiscono.
Consigliamo azioni diverse a seconda degli altri eventi di attesa visualizzati.
**Topics**
+ [Identificare le sessioni e le query che causano gli eventi](#ams-waits.waitio.actions.identify)
+ [Verifica la presenza di una correlazione con i parametri dei contatori di Approfondimenti sulle prestazioni](#ams-waits.waitio.actions.filters)
+ [Verifica la presenza di altri eventi di attesa correlati](#ams-waits.waitio.actions.maintenance)
### 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 trovare query di SQL responsabili del carico elevato**
1. Accedi a Console di gestione AWS e apri 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. Nella parte inferiore della pagina scegli **Prime Instruzioni 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 Approfondimenti sulle prestazioni, consulta il post del blog[Analizza i carichi di lavoro di Amazon Aurora MySQL con Approfondimenti sulle prestazioni](https://aws.amazon.com/blogs/database/analyze-amazon-aurora-mysql-workloads-with-performance-insights/).
### Verifica la presenza di una correlazione con i parametri dei contatori di Approfondimenti sulle prestazioni
Verifica la presenza di parametri del contatore di Approfondimenti sulle prestazioni come `Innodb_rows_changed`. Se i parametri del contatore sono correlati con `io/table/sql/handler`, segui questi passaggi:
1. In Approfondimenti sulle prestazioni, cerca le istruzioni SQL che rappresentano l’evento di attesa principale `io/table/sql/handler`. Se possibile, ottimizza questa istruzione in modo che restituisca un numero inferiore di righe.
1. Recupera le tabelle principali dalle visualizzazione `schema_table_statistics` e `x$schema_table_statistics`. Queste visualizzazioni mostrano la quantità di tempo impiegato per tabella. Per ulteriori informazioni, consulta [Le visualizzazioni schema\$1table\$1statistics e x\$1schema\$1table\$1statistics](https://dev.mysql.com/doc/refman/5.7/en/sys-schema-table-statistics.html) nel *Manuale di riferimento di MySQL*.
Per impostazione predefinita, le righe vengono ordinate in base al tempo di attesa totale discendente. Le tabelle con il maggior numero di contese appaiono per prime. L’output indica se il tempo viene impiegato per le letture, le scritture, il recupero, gli inserimenti, gli aggiornamenti o le eliminazioni.
```
mysql> select * from sys.schema_table_statistics limit 1\G
*************************** 1. row ***************************
table_schema: read_only_db
table_name: sbtest41
total_latency: 54.11 m
rows_fetched: 6001557
fetch_latency: 39.14 m
rows_inserted: 14833
insert_latency: 5.78 m
rows_updated: 30470
update_latency: 5.39 m
rows_deleted: 14833
delete_latency: 3.81 m
io_read_requests: NULL
io_read: NULL
io_read_latency: NULL
io_write_requests: NULL
io_write: NULL
io_write_latency: NULL
io_misc_requests: NULL
io_misc_latency: NULL
1 row in set (0.11 sec)
```
### Verifica la presenza di altri eventi di attesa correlati
Se `synch/sxlock/innodb/btr_search_latch` e `io/table/sql/handler` insieme contribuiscono maggiormente all’anomalia del carico del database, verificare se la variabile `innodb_adaptive_hash_index` è attivata. Se lo è, considera la possibilità di aumentare il valore del parametro `innodb_adaptive_hash_index_parts`.
Se l’indice adattivo Hash è disattivato, considera la possibilità di attivarlo. Per ulteriori informazioni sull’indice adattivo Hash di MySQL, consulta le seguenti risorse:
+ L’articolo [L’indice adattivo Hash in InnoDB è adatto al mio carico di lavoro?](https://www.percona.com/blog/2016/04/12/is-adaptive-hash-index-in-innodb-right-for-my-workload) sul sito web di Percona
+ [Indice adattivo Hash](https://dev.mysql.com/doc/refman/5.7/en/innodb-adaptive-hash.html) nel *Manuale di riferimento di MySQL*
+ L’articolo [Contesa in MySQL InnoDB: informazioni utili dalla sezione Segnalazioni](https://www.percona.com/blog/2019/12/20/contention-in-mysql-innodb-useful-info-from-the-semaphores-section/) sul sito web di Percona
**Nota**
L’indice adattivo Hash non è supportato nelle istanze database di lettura di Aurora.
In alcuni casi, le prestazioni potrebbero risultare scadenti su un’istanza di lettura quando `synch/sxlock/innodb/btr_search_latch` e `io/table/sql/handler` sono dominanti. In tal caso, prendere in considerazione il reindirizzamento temporaneo del carico di lavoro all’istanza database di scrittura e l’attivazione dell’indice adattivo Hash.
# synch/cond/innodb/row\$1blocca\$1aspetta
L’evento `synch/cond/innodb/row_lock_wait` si verifica quando una sessione ha bloccato una riga per un aggiornamento e un'altra sessione tenta di aggiornare la stessa riga. Per ulteriori informazioni, consulta l'argomento sul [blocco in InnoDB](https://dev.mysql.com/doc/refman/8.0/en/innodb-locking.html) nella documentazione di MySQL.
## Versioni del motore supportate
Queste informazioni sull'evento di attesa sono supportate per le seguenti versioni del motore:
+ Aurora MySQL versione 3
## Probabili cause di aumento delle attese
Le diverse istruzioni relative al linguaggio di manipolazione dei dati (DML) accedono contemporaneamente alla stessa riga o righe.
## Azioni
Consigliamo azioni diverse a seconda degli altri eventi di attesa visualizzati.
**Topics**
+ [Trova e rispondi alle istruzioni SQL responsabili di questo evento di attesa](#ams-waits.row-lock-wait.actions.id)
+ [Trova e rispondi alla sessione di blocco](#ams-waits.row-lock-wait.actions.blocker)
### Trova e rispondi alle istruzioni SQL responsabili di questo evento di attesa
Utilizzare Approfondimenti sulle prestazioni per identificare le istruzioni SQL responsabili di questo evento di attesa. Considera le strategie seguenti:
+ Se i blocchi di riga sono un problema persistente, considera la possibilità di riscrivere l'applicazione per utilizzare il blocco ottimistico.
+ Utilizza istruzioni multiriga.
+ Distribuisci il carico di lavoro su diversi oggetti di database. Per farlo, puoi utilizzare il partizionamento.
+ Verifica il valore del parametro `innodb_lock_wait_timeout`. Controlla la durata di attesa delle transazioni prima di generare un errore di timeout.
Per una panoramica utile dell’identificazione e della risoluzione dei problemi con Approfondimenti sulle prestazioni, consulta il post del blog[Analizza i carichi di lavoro di Amazon Aurora MySQL con Approfondimenti sulle prestazioni](https://aws.amazon.com/blogs/database/analyze-amazon-aurora-mysql-workloads-with-performance-insights/).
### Trova e rispondi alla sessione di blocco
Determina se la sessione di blocco è inattiva o attiva. Inoltre, scopri se la sessione proviene da un'applicazione o da un utente attivo.
Per identificare la sessione che tiene il blocco, è possibile eseguire `SHOW ENGINE INNODB STATUS`. Il seguente esempio mostra un output campione.
```
mysql> SHOW ENGINE INNODB STATUS;
---TRANSACTION 1688153, ACTIVE 82 sec starting index read
mysql tables in use 1, locked 1
LOCK WAIT 2 lock struct(s), heap size 1136, 2 row lock(s)
MySQL thread id 4244, OS thread handle 70369524330224, query id 4020834 172.31.14.179 reinvent executing
select id1 from test.t1 where id1=1 for update
------- TRX HAS BEEN WAITING 24 SEC FOR THIS LOCK TO BE GRANTED:
RECORD LOCKS space id 11 page no 4 n bits 72 index GEN_CLUST_INDEX of table test.t1 trx id 1688153 lock_mode X waiting
Record lock, heap no 2 PHYSICAL RECORD: n_fields 5; compact format; info bits 0
```
In alternativa, è possibile usare la seguente query per estrarre i dettagli sui blocchi correnti.
```
mysql> SELECT p1.id waiting_thread,
p1.user waiting_user,
p1.host waiting_host,
it1.trx_query waiting_query,
ilw.requesting_engine_transaction_id waiting_transaction,
ilw.blocking_engine_lock_id blocking_lock,
il.lock_mode blocking_mode,
il.lock_type blocking_type,
ilw.blocking_engine_transaction_id blocking_transaction,
CASE it.trx_state
WHEN 'LOCK WAIT'
THEN it.trx_state
ELSE p.state end blocker_state,
concat(il.object_schema,'.', il.object_name) as locked_table,
it.trx_mysql_thread_id blocker_thread,
p.user blocker_user,
p.host blocker_host
FROM performance_schema.data_lock_waits ilw
JOIN performance_schema.data_locks il
ON ilw.blocking_engine_lock_id = il.engine_lock_id
AND ilw.blocking_engine_transaction_id = il.engine_transaction_id
JOIN information_schema.innodb_trx it
ON ilw.blocking_engine_transaction_id = it.trx_id join information_schema.processlist p
ON it.trx_mysql_thread_id = p.id join information_schema.innodb_trx it1
ON ilw.requesting_engine_transaction_id = it1.trx_id join information_schema.processlist p1
ON it1.trx_mysql_thread_id = p1.id\G
*************************** 1. row ***************************
waiting_thread: 4244
waiting_user: reinvent
waiting_host: 123.456.789.012:18158
waiting_query: select id1 from test.t1 where id1=1 for update
waiting_transaction: 1688153
blocking_lock: 70369562074216:11:4:2:70369549808672
blocking_mode: X
blocking_type: RECORD
blocking_transaction: 1688142
blocker_state: User sleep
locked_table: test.t1
blocker_thread: 4243
blocker_user: reinvent
blocker_host: 123.456.789.012:18156
1 row in set (0.00 sec)
```
Quando si identifica la sessione, le opzioni includono quanto segue:
+ Contattare il proprietario dell'applicazione o l'utente.
+ Se la sessione di blocco è inattiva, considerare di terminare la sessione di blocco. Questa azione potrebbe innescare un lungo ripristino dello stato precedente. Per informazioni su come terminare una sessione, consulta [Terminare una sessione o una query](mysql-stored-proc-ending.md).
Per ulteriori informazioni su come identificare le transazioni di blocco, consulta [Using InnoDB transaction and locking information](https://dev.mysql.com/doc/refman/8.0/en/innodb-information-schema-examples.html) nella documentazione di MySQL.
# synch/cond/innodb/row\$1lock\$1wait\$1cond
L’evento `synch/cond/innodb/row_lock_wait_cond` si verifica quando una sessione ha bloccato una riga per un aggiornamento e un'altra sessione tenta di aggiornare la stessa riga. Per ulteriori informazioni, consulta l'argomento sul [blocco in InnoDB](https://dev.mysql.com/doc/refman/5.7/en/innodb-locking.html) nella documentazione di MySQL.
## Versioni del motore supportate
Queste informazioni sull'evento di attesa sono supportate per le seguenti versioni del motore:
+ Aurora MySQL versione 2
## Probabili cause di aumento delle attese
Le diverse istruzioni relative al linguaggio di manipolazione dei dati (DML) accedono contemporaneamente alla stessa riga o righe.
## Azioni
Consigliamo azioni diverse a seconda degli altri eventi di attesa visualizzati.
**Topics**
+ [Trova e rispondi alle istruzioni SQL responsabili di questo evento di attesa](#ams-waits.row-lock-wait-cond.actions.id)
+ [Trova e rispondi alla sessione di blocco](#ams-waits.row-lock-wait-cond.actions.blocker)
### Trova e rispondi alle istruzioni SQL responsabili di questo evento di attesa
Utilizzare Approfondimenti sulle prestazioni per identificare le istruzioni SQL responsabili di questo evento di attesa. Considera le strategie seguenti:
+ Se i blocchi di riga sono un problema persistente, considera la possibilità di riscrivere l'applicazione per utilizzare il blocco ottimistico.
+ Utilizza istruzioni multiriga.
+ Distribuisci il carico di lavoro su diversi oggetti di database. Per farlo, puoi utilizzare il partizionamento.
+ Verifica il valore del parametro `innodb_lock_wait_timeout`. Controlla la durata di attesa delle transazioni prima di generare un errore di timeout.
Per una panoramica utile dell’identificazione e della risoluzione dei problemi con Approfondimenti sulle prestazioni, consulta il post del blog[Analizza i carichi di lavoro di Amazon Aurora MySQL con Approfondimenti sulle prestazioni](https://aws.amazon.com/blogs/database/analyze-amazon-aurora-mysql-workloads-with-performance-insights/).
### Trova e rispondi alla sessione di blocco
Determina se la sessione di blocco è inattiva o attiva. Inoltre, scopri se la sessione proviene da un'applicazione o da un utente attivo.
Per identificare la sessione che tiene il blocco, è possibile eseguire `SHOW ENGINE INNODB STATUS`. Il seguente esempio mostra un output campione.
```
mysql> SHOW ENGINE INNODB STATUS;
---TRANSACTION 2771110, ACTIVE 112 sec starting index read
mysql tables in use 1, locked 1
LOCK WAIT 2 lock struct(s), heap size 1136, 1 row lock(s)
MySQL thread id 24, OS thread handle 70369573642160, query id 13271336 172.31.14.179 reinvent Sending data
select id1 from test.t1 where id1=1 for update
------- TRX HAS BEEN WAITING 43 SEC FOR THIS LOCK TO BE GRANTED:
RECORD LOCKS space id 11 page no 3 n bits 0 index GEN_CLUST_INDEX of table test.t1 trx id 2771110 lock_mode X waiting
Record lock, heap no 2 PHYSICAL RECORD: n_fields 5; compact format; info bits 0
```
In alternativa, è possibile usare la seguente query per estrarre i dettagli sui blocchi correnti.
```
mysql> SELECT p1.id waiting_thread,
p1.user waiting_user,
p1.host waiting_host,
it1.trx_query waiting_query,
ilw.requesting_trx_id waiting_transaction,
ilw.blocking_lock_id blocking_lock,
il.lock_mode blocking_mode,
il.lock_type blocking_type,
ilw.blocking_trx_id blocking_transaction,
CASE it.trx_state
WHEN 'LOCK WAIT'
THEN it.trx_state
ELSE p.state
END blocker_state,
il.lock_table locked_table,
it.trx_mysql_thread_id blocker_thread,
p.user blocker_user,
p.host blocker_host
FROM information_schema.innodb_lock_waits ilw
JOIN information_schema.innodb_locks il
ON ilw.blocking_lock_id = il.lock_id
AND ilw.blocking_trx_id = il.lock_trx_id
JOIN information_schema.innodb_trx it
ON ilw.blocking_trx_id = it.trx_id
JOIN information_schema.processlist p
ON it.trx_mysql_thread_id = p.id
JOIN information_schema.innodb_trx it1
ON ilw.requesting_trx_id = it1.trx_id
JOIN information_schema.processlist p1
ON it1.trx_mysql_thread_id = p1.id\G
*************************** 1. row ***************************
waiting_thread: 3561959471
waiting_user: reinvent
waiting_host: 123.456.789.012:20485
waiting_query: select id1 from test.t1 where id1=1 for update
waiting_transaction: 312337314
blocking_lock: 312337287:261:3:2
blocking_mode: X
blocking_type: RECORD
blocking_transaction: 312337287
blocker_state: User sleep
locked_table: `test`.`t1`
blocker_thread: 3561223876
blocker_user: reinvent
blocker_host: 123.456.789.012:17746
1 row in set (0.04 sec)
```
Quando si identifica la sessione, le opzioni includono quanto segue:
+ Contattare il proprietario dell'applicazione o l'utente.
+ Se la sessione di blocco è inattiva, considerare di terminare la sessione di blocco. Questa azione potrebbe innescare un lungo ripristino dello stato precedente. Per informazioni su come terminare una sessione, consulta [Terminare una sessione o una query](mysql-stored-proc-ending.md).
Per ulteriori informazioni su come identificare le transazioni di blocco, consulta [Using InnoDB transaction and locking information](https://dev.mysql.com/doc/refman/5.7/en/innodb-information-schema-examples.html) nella documentazione di MySQL.
# synch/cond/sql/MDL\$1contesto: :COND\$1WAIT\$1STATUS
L’evento `synch/cond/sql/MDL_context::COND_wait_status` si verifica quando ci sono thread in attesa del blocco dei metadati di una tabella.
**Topics**
+ [Versioni del motore supportate](#ams-waits.cond-wait-status.context.supported)
+ [Contesto](#ams-waits.cond-wait-status.context)
+ [Probabili cause di aumento delle attese](#ams-waits.cond-wait-status.causes)
+ [Azioni](#ams-waits.cond-wait-status.actions)
## Versioni del motore supportate
Queste informazioni sull'evento di attesa sono supportate per le seguenti versioni del motore:
+ Aurora MySQL versioni 2 e 3
## Contesto
L'evento `synch/cond/sql/MDL_context::COND_wait_status` indica che ci sono thread in attesa di un blocco dei metadati di tabella. In alcuni casi, una sessione contiene un blocco di metadati su una tabella e un'altra sessione tenta di ottenere lo stesso blocco sulla stessa tabella. In tal caso, la seconda sessione attende l’evento di attesa `synch/cond/sql/MDL_context::COND_wait_status`.
MySQL utilizza il blocco dei metadati per gestire l'accesso simultaneo agli oggetti del database e garantire la coerenza dei dati. Il blocco dei metadati si applica a tabelle, schemi, eventi pianificati, tablespace e blocchi utente acquisiti con la funzione `get_lock` e i programmi memorizzati. I programmi memorizzati includono procedure, funzioni e attivazioni. Per ulteriori informazioni, consulta [Blocco dei metadati](https://dev.mysql.com/doc/refman/5.7/en/metadata-locking.html) nella documentazione di MySQL.
L'elenco dei processi MySQL mostra questa sessione nello stato `waiting for metadata lock`. In Approfondimenti sulle prestazioni, se `Performance_schema` è acceso, l'evento `synch/cond/sql/MDL_context::COND_wait_status` viene visualizzato.
Il timeout predefinito per una query in attesa di un blocco dei metadati si basa sul valore del parametro `lock_wait_timeout`, che viene impostato in modo predefinito a 31.536.000 secondi (365 giorni).
Per ulteriori dettagli sui diversi blocchi InnoDB e sui tipi di blocchi che possono causare conflitti, consultare [Blocco InnoDB](https://dev.mysql.com/doc/refman/5.7/en/innodb-locking.html) nella documentazione di MySQL.
## Probabili cause di aumento delle attese
Quando l’evento `synch/cond/sql/MDL_context::COND_wait_status` appare più che normale, possibilmente indicando un problema di prestazioni, le cause tipiche includono le seguenti:
**Transazioni di lunga durata**
Una o più transazioni stanno modificando una grande quantità di dati e mantengono i blocchi sulle tabelle per un tempo molto lungo.
**Transazioni inattive**
Una o più transazioni rimangono aperte per un lungo periodo, senza che venga eseguito il commit o riprimisto a una precedente versione.
**Istruzioni DDL su tabelle grandi**
Una o più istruzioni di definizione dei dati (DDL), ad esempio i comandi `ALTER TABLE`, sono state eseguite su tabelle molto grandi.
**Blocchi espliciti della tabella**
Ci sono blocchi espliciti sulle tabelle che non vengono rilasciate in modo tempestivo. Ad esempio, potrebbe essere eseguita un'applicazione su istruzioni `LOCK TABLE` impropriamente.
## Azioni
Consigliamo diverse azioni a seconda delle cause dell'evento di attesa e della versione del cluster del database di Aurora MySQL.
**Topics**
+ [Identificare le sessioni e le query che causano gli eventi](#ams-waits.cond-wait-status.actions.identify)
+ [Verifica la presenza di eventi passati](#ams-waits.cond-wait-status.actions.past-events)
+ [Esegui query su Aurora MySQL versione 2](#ams-waits.cond-wait-status.actions.run-queries-aurora-mysql-57)
+ [Rispondere alla sessione di blocco](#ams-waits.cond-wait-status.actions.blocker)
### Identificare le sessioni e le query che causano gli eventi
È possibile utilizzare Approfondimenti sulle prestazioni per mostrare le query bloccate dall’evento di attesa `synch/cond/sql/MDL_context::COND_wait_status`. Tuttavia, per identificare la sessione di blocco, eseguire una query sulle tabelle dei metadati da `performance_schema` e `information_schema` sul cluster del database.
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 trovare query di SQL responsabili del carico elevato**
1. Accedi a Console di gestione AWS e apri 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. Nella parte inferiore della pagina scegli **Prime Instruzioni 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 un'utile panoramica sulla risoluzione dei problemi con Performance Insights, consulta il post sul blog AWS Database [Analyze Amazon Aurora MySQL Workloads](https://aws.amazon.com/blogs/database/analyze-amazon-aurora-mysql-workloads-with-performance-insights/) with Performance Insights.
### Verifica la presenza di eventi passati
È possibile ottenere informazioni dettagliate su questo evento di attesa per verificare la presenza di occorrenze passate. Per fare ciò, completare questa procedura:
+ Controllare il linguaggio di manipolazione dei dati (DML) e la velocità effettiva e la latenza del DDL per verificare se sono state apportate modifiche al carico di lavoro.
È possibile utilizzare Approfondimenti sulle prestazioni per trovare query in attesa di questo evento al momento del problema. Inoltre, è possibile visualizzare il digest delle query eseguite vicino al momento del problema.
+ Se i registri di verifica o i registri generali sono attivati per il cluster el database, è possibile verificare la presenza di tutte le query eseguite sugli oggetti (schema.table) coinvolti nella transazione in attesa. È inoltre possibile verificare la presenza delle query completate in esecuzione prima della transazione.
Le informazioni disponibili per l’identificazione e la risoluzione dei problemi degli eventi passati sono limitate. L'esecuzione di queste verifiche non mostra quale oggetto è in attesa di informazioni. Tuttavia, è possibile identificare le tabelle con un carico pesante al momento dell'evento e la serie di righe gestite di frequente che causano conflitti al momento del problema. È quindi possibile utilizzare queste informazioni per riprodurre il problema in un ambiente di test e fornire informazioni dettagliate sulla sua causa.
### Esegui query su Aurora MySQL versione 2
In Aurora MySQL versione 2, è possibile identificare direttamente la sessione bloccata eseguendo una query sulle tabelle `performance_schema` o visualizzazione dello schema `sys`. Un esempio può illustrare come interrogare le tabelle per identificare query e sessioni di blocco.
Nel seguente output dell'elenco dei processi, l'ID di connessione `89` è in attesa di un blocco dei metadati e sta eseguendo un comando `TRUNCATE TABLE`. In una query sulle tabelle `performance_schema` o visualizzazioni dello schema `sys`, l'output mostra che la sessione di blocco è `76`.
```
MySQL [(none)]> select @@version, @@aurora_version;
+-----------+------------------+
| @@version | @@aurora_version |
+-----------+------------------+
| 5.7.12 | 2.11.5 |
+-----------+------------------+
1 row in set (0.01 sec)
MySQL [(none)]> show processlist;
+----+-----------------+--------------------+-----------+---------+------+---------------------------------+-------------------------------+
| Id | User | Host | db | Command | Time | State | Info |
+----+-----------------+--------------------+-----------+---------+------+---------------------------------+-------------------------------+
| 2 | rdsadmin | localhost | NULL | Sleep | 0 | NULL | NULL |
| 4 | rdsadmin | localhost | NULL | Sleep | 2 | NULL | NULL |
| 5 | rdsadmin | localhost | NULL | Sleep | 1 | NULL | NULL |
| 20 | rdsadmin | localhost | NULL | Sleep | 0 | NULL | NULL |
| 21 | rdsadmin | localhost | NULL | Sleep | 261 | NULL | NULL |
| 66 | auroramysql5712 | 172.31.21.51:52154 | sbtest123 | Sleep | 0 | NULL | NULL |
| 67 | auroramysql5712 | 172.31.21.51:52158 | sbtest123 | Sleep | 0 | NULL | NULL |
| 68 | auroramysql5712 | 172.31.21.51:52150 | sbtest123 | Sleep | 0 | NULL | NULL |
| 69 | auroramysql5712 | 172.31.21.51:52162 | sbtest123 | Sleep | 0 | NULL | NULL |
| 70 | auroramysql5712 | 172.31.21.51:52160 | sbtest123 | Sleep | 0 | NULL | NULL |
| 71 | auroramysql5712 | 172.31.21.51:52152 | sbtest123 | Sleep | 0 | NULL | NULL |
| 72 | auroramysql5712 | 172.31.21.51:52156 | sbtest123 | Sleep | 0 | NULL | NULL |
| 73 | auroramysql5712 | 172.31.21.51:52164 | sbtest123 | Sleep | 0 | NULL | NULL |
| 74 | auroramysql5712 | 172.31.21.51:52166 | sbtest123 | Sleep | 0 | NULL | NULL |
| 75 | auroramysql5712 | 172.31.21.51:52168 | sbtest123 | Sleep | 0 | NULL | NULL |
| 76 | auroramysql5712 | 172.31.21.51:52170 | NULL | Query | 0 | starting | show processlist |
| 88 | auroramysql5712 | 172.31.21.51:52194 | NULL | Query | 22 | User sleep | select sleep(10000) |
| 89 | auroramysql5712 | 172.31.21.51:52196 | NULL | Query | 5 | Waiting for table metadata lock | truncate table sbtest.sbtest1 |
+----+-----------------+--------------------+-----------+---------+------+---------------------------------+-------------------------------+
18 rows in set (0.00 sec)
```
Successivamente, una query sulle tabelle `performance_schema` o visualizzazioni dello schema `sys` mostra che la sessione di blocco è `76`.
```
MySQL [(none)]> select * from sys.schema_table_lock_waits;
+---------------+-------------+-------------------+-------------+------------------------------+-------------------+-----------------------+-------------------------------+--------------------+-----------------------------+-----------------------------+--------------------+--------------+------------------------------+--------------------+------------------------+-------------------------+------------------------------+
| object_schema | object_name | waiting_thread_id | waiting_pid | waiting_account | waiting_lock_type | waiting_lock_duration | waiting_query | waiting_query_secs | waiting_query_rows_affected | waiting_query_rows_examined | blocking_thread_id | blocking_pid | blocking_account | blocking_lock_type | blocking_lock_duration | sql_kill_blocking_query | sql_kill_blocking_connection |
+---------------+-------------+-------------------+-------------+------------------------------+-------------------+-----------------------+-------------------------------+--------------------+-----------------------------+-----------------------------+--------------------+--------------+------------------------------+--------------------+------------------------+-------------------------+------------------------------+
| sbtest | sbtest1 | 121 | 89 | auroramysql5712@192.0.2.0 | EXCLUSIVE | TRANSACTION | truncate table sbtest.sbtest1 | 10 | 0 | 0 | 108 | 76 | auroramysql5712@192.0.2.0 | SHARED_READ | TRANSACTION | KILL QUERY 76 | KILL 76 |
+---------------+-------------+-------------------+-------------+------------------------------+-------------------+-----------------------+-------------------------------+--------------------+-----------------------------+-----------------------------+--------------------+--------------+------------------------------+--------------------+------------------------+-------------------------+------------------------------+
1 row in set (0.00 sec)
```
### Rispondere alla sessione di blocco
Quando si identifica la sessione, le opzioni includono quanto segue:
+ Contattare il proprietario dell'applicazione o l'utente.
+ Se la sessione di blocco è inattiva, considerare di terminare la sessione di blocco. Questa azione potrebbe innescare un lungo ripristino dello stato precedente. Per informazioni su come terminare una sessione, consulta [Terminare una sessione o una query](mysql-stored-proc-ending.md).
Per ulteriori informazioni su come identificare le transazioni di blocco, consulta [Utilizzo delle informazioni sulle transazioni InnoDB e sul blocco](https://dev.mysql.com/doc/refman/5.7/en/innodb-information-schema-examples.html) nella documentazione di MySQL.
# synch/mutex/innodb/aurora\$1lock\$1thread\$1slot\$1futex
L’evento `synch/mutex/innodb/aurora_lock_thread_slot_futex` si verifica quando una sessione ha bloccato una riga per un aggiornamento e un'altra sessione tenta di aggiornare la stessa riga. Per ulteriori informazioni, consulta [Blocco in InnoDB](https://dev.mysql.com/doc/refman/5.7/en/innodb-locking.html) nel *Riferimento di MySQL*.
## Versioni del motore supportate
Queste informazioni sull'evento di attesa sono supportate per le seguenti versioni del motore:
+ Aurora MySQL versione 2
## Probabili cause di aumento delle attese
Le diverse istruzioni relative al linguaggio di manipolazione dei dati (DML) accedono contemporaneamente alla stessa riga o righe.
## Azioni
Consigliamo azioni diverse a seconda degli altri eventi di attesa visualizzati.
**Topics**
+ [Trova e rispondi alle istruzioni SQL responsabili di questo evento di attesa](#ams-waits.waitsynch.actions.id)
+ [Trova e rispondi alla sessione di blocco](#ams-waits.waitsynch.actions.blocker)
### Trova e rispondi alle istruzioni SQL responsabili di questo evento di attesa
Utilizzare Approfondimenti sulle prestazioni per identificare le istruzioni SQL responsabili di questo evento di attesa. Considera le strategie seguenti:
+ Se i blocchi di riga sono un problema persistente, considera la possibilità di riscrivere l'applicazione per utilizzare il blocco ottimistico.
+ Utilizza istruzioni multiriga.
+ Distribuisci il carico di lavoro su diversi oggetti di database. Per farlo, puoi utilizzare il partizionamento.
+ Verifica il valore del parametro `innodb_lock_wait_timeout`. Controlla la durata di attesa delle transazioni prima di generare un errore di timeout.
Per una panoramica utile dell’identificazione e della risoluzione dei problemi con Approfondimenti sulle prestazioni, consulta il post del blog[Analizza i carichi di lavoro di Amazon Aurora MySQL con Approfondimenti sulle prestazioni](https://aws.amazon.com/blogs/database/analyze-amazon-aurora-mysql-workloads-with-performance-insights/).
### Trova e rispondi alla sessione di blocco
Determina se la sessione di blocco è inattiva o attiva. Inoltre, scopri se la sessione proviene da un'applicazione o da un utente attivo.
Per identificare la sessione che tiene il blocco, è possibile eseguire `SHOW ENGINE INNODB STATUS`. Il seguente esempio mostra un output campione.
```
mysql> SHOW ENGINE INNODB STATUS;
---------------------TRANSACTION 302631452, ACTIVE 2 sec starting index read
mysql tables in use 1, locked 1
LOCK WAIT 2 lock struct(s), heap size 376, 1 row lock(s)
MySQL thread id 80109, OS thread handle 0x2ae915060700, query id 938819 10.0.4.12 reinvent updating
UPDATE sbtest1 SET k=k+1 WHERE id=503
------- TRX HAS BEEN WAITING 2 SEC FOR THIS LOCK TO BE GRANTED:
RECORD LOCKS space id 148 page no 11 n bits 30 index `PRIMARY` of table `sysbench2`.`sbtest1` trx id 302631452 lock_mode X locks rec but not gap waiting
Record lock, heap no 30 PHYSICAL RECORD: n_fields 6; compact format; info bits 0
```
In alternativa, è possibile usare la seguente query per estrarre i dettagli sui blocchi correnti.
```
mysql> SELECT p1.id waiting_thread,
p1.user waiting_user,
p1.host waiting_host,
it1.trx_query waiting_query,
ilw.requesting_trx_id waiting_transaction,
ilw.blocking_lock_id blocking_lock,
il.lock_mode blocking_mode,
il.lock_type blocking_type,
ilw.blocking_trx_id blocking_transaction,
CASE it.trx_state
WHEN 'LOCK WAIT'
THEN it.trx_state
ELSE p.state
END blocker_state,
il.lock_table locked_table,
it.trx_mysql_thread_id blocker_thread,
p.user blocker_user,
p.host blocker_host
FROM information_schema.innodb_lock_waits ilw
JOIN information_schema.innodb_locks il
ON ilw.blocking_lock_id = il.lock_id
AND ilw.blocking_trx_id = il.lock_trx_id
JOIN information_schema.innodb_trx it
ON ilw.blocking_trx_id = it.trx_id
JOIN information_schema.processlist p
ON it.trx_mysql_thread_id = p.id
JOIN information_schema.innodb_trx it1
ON ilw.requesting_trx_id = it1.trx_id
JOIN information_schema.processlist p1
ON it1.trx_mysql_thread_id = p1.id\G
*************************** 1. row ***************************
waiting_thread: 3561959471
waiting_user: reinvent
waiting_host: 123.456.789.012:20485
waiting_query: select id1 from test.t1 where id1=1 for update
waiting_transaction: 312337314
blocking_lock: 312337287:261:3:2
blocking_mode: X
blocking_type: RECORD
blocking_transaction: 312337287
blocker_state: User sleep
locked_table: `test`.`t1`
blocker_thread: 3561223876
blocker_user: reinvent
blocker_host: 123.456.789.012:17746
1 row in set (0.04 sec)
```
Quando si identifica la sessione, le opzioni includono quanto segue:
+ Contattare il proprietario dell'applicazione o l'utente.
+ Se la sessione di blocco è inattiva, considerare di terminare la sessione di blocco. Questa azione potrebbe innescare un lungo ripristino dello stato precedente. Per informazioni su come terminare una sessione, consulta [Terminare una sessione o una query](mysql-stored-proc-ending.md).
Per ulteriori informazioni su come identificare le transazioni di blocco, consulta [Utilizzo delle informazioni sulle transazioni InnoDB e sul blocco](https://dev.mysql.com/doc/refman/5.7/en/innodb-information-schema-examples.html) nel *Manuale di riferimento di MySQL*.
# synch/mutex/innodb/buf\$1pool\$1mutex
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)
+ [Context](#ams-waits.bufpoolmutex.context)
+ [Probabili cause di aumento delle attese](#ams-waits.bufpoolmutex.causes)
+ [Azioni](#ams-waits.bufpoolmutex.actions)
## 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](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
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
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
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/](https://console.aws.amazon.com/rds/).
1. Nel pannello di navigazione scegli **Performance Insights**.
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
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 [Dimensionamento automatico di Amazon Aurora con le repliche Aurora](Aurora.Integrating.AutoScaling.md).
### 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_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
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 parametri personalizzati di Amazon CloudWatch per monitorare le variabili di stato. Per ulteriori informazioni, consulta [Pubblicazione di parametri personalizzati](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/publishingMetrics.html).
# synch/mutex/innodb/fil\$1sistema\$1mutex
L’evento `synch/mutex/innodb/fil_system_mutex` si verifica quando una sessione è in attesa di accedere alla cache di memoria tablespace.
**Topics**
+ [Versioni del motore supportate](#ams-waits.innodb-fil-system-mutex.context.supported)
+ [Contesto](#ams-waits.innodb-fil-system-mutex.context)
+ [Probabili cause di aumento delle attese](#ams-waits.innodb-fil-system-mutex.causes)
+ [Azioni](#ams-waits.innodb-fil-system-mutex.actions)
## Versioni del motore supportate
Queste informazioni sull'evento di attesa sono supportate per le seguenti versioni del motore:
+ Aurora MySQL versioni 2 e 3
## Contesto
InnoDB utilizza tablespace per gestire l'area di archiviazione per tabelle e file di registro. La *cache di memoria di tablespace* è una struttura di memoria globale che mantiene le informazioni sulle tablespace. MySQL utilizza attese `synch/mutex/innodb/fil_system_mutex` per controllare l'accesso simultaneo alla cache di memoria di tablespace.
L'evento `synch/mutex/innodb/fil_system_mutex` indica che attualmente esistono più operazioni che devono recuperare e manipolare le informazioni nella cache di memoria di tablespace per la stessa tablespace.
## Probabili cause di aumento delle attese
Quando l’evento `synch/mutex/innodb/fil_system_mutex` appare più che normale, possibilmente indicando un problema di prestazioni, generalmente accade quando sono presenti tutte le seguenti condizioni:
+ Un aumento simultaneo delle operazioni relative al linguaggio di manipolazione dei dati (DM) che che aggiornano o eliminano i dati nella stessa tabella.
+ La tablespace per questa tabella è molto ampia e ha molte pagine di dati.
+ Il fattore di riempimento per queste pagine di dati è basso.
## Azioni
Consigliamo azioni diverse a seconda delle cause dell’evento di attesa.
**Topics**
+ [Identificare le sessioni e le query che causano gli eventi](#ams-waits.innodb-fil-system-mutex.actions.identify)
+ [Riorganizza tabelle di grandi dimensioni durante le ore non di picco](#ams-waits.innodb-fil-system-mutex.actions.reorganize)
### 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 trovare query di SQL responsabili del carico elevato**
1. Accedi a Console di gestione AWS e apri 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 Performance Insights per l'istanza database.
1. Nel grafico **Carico del database**, scegli **Dividi per attesa**.
1. Nella parte inferiore della pagina scegli **Prime Instruzioni 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/).
Un altro modo per scoprire quali query causano un numero elevato di attese `synch/mutex/innodb/fil_system_mutex` è di controllare `performance_schema`, come nel seguente esempio.
```
mysql> select * from performance_schema.events_waits_current where EVENT_NAME='wait/synch/mutex/innodb/fil_system_mutex'\G
*************************** 1. row ***************************
THREAD_ID: 19
EVENT_ID: 195057
END_EVENT_ID: 195057
EVENT_NAME: wait/synch/mutex/innodb/fil_system_mutex
SOURCE: fil0fil.cc:6700
TIMER_START: 1010146190118400
TIMER_END: 1010146196524000
TIMER_WAIT: 6405600
SPINS: NULL
OBJECT_SCHEMA: NULL
OBJECT_NAME: NULL
INDEX_NAME: NULL
OBJECT_TYPE: NULL
OBJECT_INSTANCE_BEGIN: 47285552262176
NESTING_EVENT_ID: NULL
NESTING_EVENT_TYPE: NULL
OPERATION: lock
NUMBER_OF_BYTES: NULL
FLAGS: NULL
*************************** 2. row ***************************
THREAD_ID: 23
EVENT_ID: 5480
END_EVENT_ID: 5480
EVENT_NAME: wait/synch/mutex/innodb/fil_system_mutex
SOURCE: fil0fil.cc:5906
TIMER_START: 995269979908800
TIMER_END: 995269980159200
TIMER_WAIT: 250400
SPINS: NULL
OBJECT_SCHEMA: NULL
OBJECT_NAME: NULL
INDEX_NAME: NULL
OBJECT_TYPE: NULL
OBJECT_INSTANCE_BEGIN: 47285552262176
NESTING_EVENT_ID: NULL
NESTING_EVENT_TYPE: NULL
OPERATION: lock
NUMBER_OF_BYTES: NULL
FLAGS: NULL
*************************** 3. row ***************************
THREAD_ID: 55
EVENT_ID: 23233794
END_EVENT_ID: NULL
EVENT_NAME: wait/synch/mutex/innodb/fil_system_mutex
SOURCE: fil0fil.cc:449
TIMER_START: 1010492125341600
TIMER_END: 1010494304900000
TIMER_WAIT: 2179558400
SPINS: NULL
OBJECT_SCHEMA: NULL
OBJECT_NAME: NULL
INDEX_NAME: NULL
OBJECT_TYPE: NULL
OBJECT_INSTANCE_BEGIN: 47285552262176
NESTING_EVENT_ID: 23233786
NESTING_EVENT_TYPE: WAIT
OPERATION: lock
NUMBER_OF_BYTES: NULL
FLAGS: NULL
```
### Riorganizza tabelle di grandi dimensioni durante le ore non di picco
Riorganizza tabelle di grandi dimensioni che identifichi come fonte di un numero elevato di eventi di attesa `synch/mutex/innodb/fil_system_mutex` durante una finestra temporale di manutenzione al di fuori dell'orario di produzione. In questo modo si assicura che la pulizia della mappa delle tablespace interne non si verifichi quando l'accesso rapido alla tabella è fondamentale. Per informazioni sulla riorganizzazione delle tabelle, consulta [Istruzione OPTIMIZE TABLE](https://dev.mysql.com/doc/refman/5.7/en/optimize-table.html) nel *Riferimento di MySQL*.
# synch/mutex/innodb/trx\$1sys\$1mutex
L’evento `synch/mutex/innodb/trx_sys_mutex` si verifica quando c'è un'elevata attività del database con un numero elevato di transazioni.
**Topics**
+ [Versioni del motore rilevanti](#ams-waits.trxsysmutex.context.supported)
+ [Context](#ams-waits.trxsysmutex.context)
+ [Probabili cause di aumento delle attese](#ams-waits.trxsysmutex.causes)
+ [Azioni](#ams-waits.trxsysmutex.actions)
## Versioni del motore rilevanti
Queste informazioni sull'evento di attesa sono supportate per le seguenti versioni del motore:
+ Aurora MySQL versioni 2 e 3
## Context
Internamente, il motore di database InnoDB utilizza il livello di isolamento della lettura ripetibile con snapshot per fornire coerenza di lettura. In questo modo viene consentita una visualizzazione istantanea del database al momento della creazione dello snapshot.
In InnoDB, tutte le modifiche vengono applicate al database non appena arrivano, indipendentemente dal fatto che sia stato eseguito il commit. Questo approccio significa che senza il controllo della concorrenza multiversione (MVCC), tutti gli utenti connessi al database vedono tutte le modifiche e le righe più recenti. Pertanto, InnoDB richiede un modo per tenere traccia delle modifiche per capire cosa ripristinare allo stato precedente quando necessario.
Per fare ciò, InnoDB utilizza un sistema di transazioni (`trx_sys`) per tenere traccia degli snapshot. Il sistema di transazioni effettua quanto segue:
+ Tiene traccia dell'ID della transazione per ogni riga nei registri di annullamento.
+ Utilizza una struttura interna InnoDB chiamata `ReadView` che aiuta a identificare quali ID di transazione sono visibili per uno snapshot.
## Probabili cause di aumento delle attese
Qualsiasi operazione di database che richiede la gestione coerente e controllata (creazione, lettura, aggiornamento ed eliminazione) degli ID delle transazioni genera una chiamata da `trx_sys` al mutex.
Queste chiamate avvengono all'interno di tre funzioni:
+ `trx_sys_mutex_enter` – Crea il mutex.
+ `trx_sys_mutex_exit` – Rilascia il mutex.
+ `trx_sys_mutex_own` – Verifica se il mutex è di proprietà.
La strumentazione InnoDB Performance Schema tiene traccia di tutte le chiamate mutex `trx_sys`. Il monitoraggio include, a titolo esemplificativo ma non esaustivo, la gestione di `trx_sys` all'avvio o allo spegnimento del database, operazioni di ripristino dello stato precedente, pulizia degli annullamenti, accesso in lettura di righe e carichi del pool di buffer. L'elevata attività del database con un numero elevato di transazioni comporta la comparsa di `synch/mutex/innodb/trx_sys_mutex` tra i principali eventi di attesa.
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.
## Azioni
Consigliamo azioni diverse a seconda delle cause dell'evento di attesa.
**Topics**
+ [Identificare le sessioni e le query che causano gli eventi](#ams-waits.trxsysmutex.actions.identify)
+ [Esamina altri eventi di attesa](#ams-waits.trxsysmutex.actions.action1)
### 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. Guarda gli eventi di attesa che contribuiscono al carico più elevato. Scopri se è possibile ottimizzare il database e l'applicazione per ridurre tali eventi.
**Per visualizzare il grafico Istruzioni SQL principali nella Console di gestione AWS**
1. Apri la console Amazon RDS all'indirizzo [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/).
1. Nel pannello di navigazione scegli **Performance Insights**.
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. Nel 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/).
### Esamina altri eventi di attesa
Esamina gli altri eventi di attesa associati all’evento di attesa `synch/mutex/innodb/trx_sys_mutex`. In questo modo, si possono acquisire ulteriori informazioni sulla natura del carico di lavoro. Un numero elevato di transazioni potrebbe ridurre la velocità effettiva, ma anche il carico di lavoro potrebbe renderlo necessario.
Per ulteriori informazioni su come ottimizzare le transazioni, consulta [Ottimizzazione della gestione delle transazioni InnoDB](https://dev.mysql.com/doc/refman/5.7/en/optimizing-innodb-transaction-management.html) nella documentazione di MySQL.
# synch/sxlock/innodb/hash\$1table\$1locks
L’evento `synch/sxlock/innodb/hash_table_locks` si verifica quando le pagine non trovate nel pool di buffer devono essere lette dall’archiviazione.
**Topics**
+ [Versioni del motore supportate](#ams-waits.sx-lock-hash-table-locks.context.supported)
+ [Contesto](#ams-waits.sx-lock-hash-table-locks.context)
+ [Probabili cause di aumento delle attese](#ams-waits.sx-lock-hash-table-locks.causes)
+ [Azioni](#ams-waits.sx-lock-hash-table-locks.actions)
## Versioni del motore supportate
Queste informazioni sull’evento di attesa sono supportate per le seguenti versioni:
+ Aurora MySQL versioni 2 e 3
## Contesto
L’evento `synch/sxlock/innodb/hash_table_locks` indica che un carico di lavoro accede frequentemente a dati che non sono memorizzati nel pool di buffer. Questo evento di attesa è associato ad aggiunte di nuove pagine e a espulsioni di dati vecchi dal pool di buffer. I dati memorizzati nei dati nuovi e vecchi del pool di buffer devono essere memorizzati nella cache, in modo che le pagine vecchie vengano espulse per consentire la memorizzazione nella cache delle nuove pagine. MySQL utilizza un algoritmo utilizzato meno di recente (LRU) per espellere pagine dal pool di buffer. Il carico di lavoro sta tentando di accedere ai dati che non sono stati caricati nel pool di buffer o ai dati che sono stati espulsi dal pool di buffer.
Questo evento di attesa si verifica quando il carico di lavoro deve accedere ai dati nei file su disco o quando i blocchi vengono liberati o aggiunti all’elenco LRU del pool di buffer. Queste operazioni attendono di ottenere un blocco condiviso escluso (SX-Lock). Questo SX-Lock viene utilizzato per la sincronizzazione su *tabella hash*, che è una tabella in memoria progettata per migliorare le prestazioni di accesso al pool di buffer.
Per ulteriori informazioni, consulta [Pool di buffer](https://dev.mysql.com/doc/refman/5.7/en/innodb-buffer-pool.html) nella documentazione di MySQL.
## Probabili cause di aumento delle attese
Quando l’evento di attesa `synch/sxlock/innodb/hash_table_locks` appare più che normale, probabilmente indicando un problema di prestazioni, le cause tipiche includono le seguenti:
**Un pool di buffer sottodimensionato**
La dimensione del pool di buffer è troppo piccola per mantenere in memoria tutte le pagine a cui si accede di frequente.
**Carico di lavoro pesante**
Il carico di lavoro sta causando frequenti espulsioni e ricariche di pagine di dati nella cache del buffer.
**Errori di lettura delle pagine**
Ci sono errori di lettura delle pagine nel pool di buffer, che potrebbero indicare il danneggiamento dei dati.
## Azioni
Consigliamo azioni diverse a seconda delle cause dell’evento di attesa.
**Topics**
+ [Aumenta le dimensioni del pool del buffer](#ams-waits.sx-lock-hash-table-locks.actions.increase-buffer-pool-size)
+ [Miglioramento dei modelli di accesso ai dati](#ams-waits.sx-lock-hash-table-locks.actions.improve-data-access-patterns)
+ [Riduci o evita le scansioni complete della tabella](#ams-waits.sx-lock-hash-table-locks.actions.reduce-full-table-scans)
+ [Controllare i registri degli errori per la presenza del danneggiamento della pagina](#ams-waits.sx-lock-hash-table-locks.actions.check-error-logs)
### Aumenta le dimensioni del pool del buffer
Assicurarsi che il pool del buffer sia ridimensionato in modo appropriato per il carico di lavoro. Per farlo è possibile controllare la percentuale di riscontri nella cache del pool di buffer. In genere, se il valore scende al di sotto del 95%, è consigliabile aumentare la dimensione del pool di buffer. Un pool di buffer più ampio può mantenere più a lungo in memoria le pagine a cui si accede di frequente. Per aumentare le dimensioni del pool di buffer, modificare il valore del parametro `innodb_buffer_pool_size`. Il valore predefinito di questo parametro è basato sulle dimensioni della classe di istanza database. Per ulteriori informazioni, consulta [Best practice per la configurazione del database di Amazon Aurora MySQL](https://aws.amazon.com/blogs/database/best-practices-for-amazon-aurora-mysql-database-configuration/).
### Miglioramento dei modelli di accesso ai dati
Controlla le query interessate da questa attesa e i relativi piani di esecuzione. Considera la possibilità di migliorare i modelli di accesso ai dati. Ad esempio, se si sta utilizzando[mysqli\$1result:: fetch\$1array](https://www.php.net/manual/en/mysqli-result.fetch-array.php), si può provare ad aumentare la dimensione del recupero dell’array.
È possibile utilizzare Performance Insights per visualizzare query e sessioni che potrebbero causare l’evento di attesa `synch/sxlock/innodb/hash_table_locks`.
**Per trovare query di SQL responsabili del carico elevato**
1. Accedi alla Console di gestione AWS e apri 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. Nella parte inferiore della pagina scegli **Prime Instruzioni 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 AWS [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/).
### Riduci o evita le scansioni complete della tabella
Monitora il carico di lavoro per verificare se sta eseguendo scansioni a tabella completa e, in caso affermativo, ridurle o evitarle. Ad esempio, è possibile monitorare le variabili di stato come ad esempio `Handler_read_rnd_next`. Per ulteriori dettagli, consulta [Variabili dello stato del server](https://dev.mysql.com/doc/refman/5.7/en/server-status-variables.html#statvar_Handler_read_rnd_next) nella documentazione di MySQL.
### Controllare i registri degli errori per la presenza del danneggiamento della pagina
È possibile controllare il mysql-error.log per la presenza di messaggi correlati al danneggiamento che sono stati rilevati in prossimità del momento in cui si è verificato il problema. I messaggi con cui è possibile lavorare per risolvere il problema si trovano nel registro degli errori. Potrebbe essere necessario ricreare oggetti segnalati come danneggiati.
# synch/mutex/innodb/temp\$1pool\$1manager\$1mutex
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.
**Topics**
+ [Versioni del motore supportate](#ams-waits.io-temppoolmanager.context.supported)
+ [Contesto](#ams-waits.io-temppoolmanager.context)
+ [Probabili cause di aumento delle attese](#ams-waits.io-temppoolmanager.causes)
+ [Azioni](#ams-waits.io-temppoolmanager.actions)
## 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 [https://dev.mysql.com/doc/refman/8.0/en/server-system-variables.html#sysvar_temptable_max_ram](https://dev.mysql.com/doc/refman/8.0/en/server-system-variables.html#sysvar_temptable_max_ram)limite.
+ 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. [https://dev.mysql.com/doc/refman/8.0/en/server-system-variables.html#sysvar_temptable_max_mmap](https://dev.mysql.com/doc/refman/8.0/en/server-system-variables.html#sysvar_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 `INACTIVE` tablespace 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.
**Topics**
+ [Monitora e ottimizza l'utilizzo temporaneo delle tabelle](#ams-waits.io-temppoolmanager.actions.monitor)
+ [Esamina le query utilizzando INFORMATION\$1SCHEMA](#ams-waits.io-temppoolmanager.actions.schema-queries)
+ [Aumenta il parametro innodb\$1sync\$1array\$1size](#ams-waits.io-temppoolmanager.actions.sync_array)
+ [Implementa un pool di connessioni](#ams-waits.io-temppoolmanager.actions.connection_pooling)
### 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_tables` contatore 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](ams3-temptable-behavior.md).
Dopo aver identificato le query che creano tabelle temporanee, esegui questi passaggi di ottimizzazione:
+ `EXPLAIN`Utilizzatelo 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:
+ [https://dev.mysql.com/doc/refman/8.0/en/server-system-variables.html#sysvar_temptable_max_ram](https://dev.mysql.com/doc/refman/8.0/en/server-system-variables.html#sysvar_temptable_max_ram)- Controlla l'utilizzo massimo della RAM per le tabelle temporanee.
+ [https://dev.mysql.com/doc/refman/8.0/en/server-system-variables.html#sysvar_temptable_max_mmap](https://dev.mysql.com/doc/refman/8.0/en/server-system-variables.html#sysvar_temptable_max_mmap)- Imposta il limite per l'archiviazione di file mappati in memoria.
+ [https://dev.mysql.com/doc/refman/8.4/en/server-system-variables.html#sysvar_tmp_table_size](https://dev.mysql.com/doc/refman/8.4/en/server-system-variables.html#sysvar_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](https://aws.amazon.com/blogs/database/use-the-temptable-storage-engine-on-amazon-rds-for-mysql-and-amazon-aurora-mysql/).
### Esamina le query utilizzando INFORMATION\$1SCHEMA
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_SCHEMA` al posto di `INFORMATION_SCHEMA` dove possibile.
+ Se necessario`INFORMATION_SCHEMA`, riduci la frequenza con cui esegui queste query.
### Aumenta il parametro innodb\$1sync\$1array\$1size
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_size` pari 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](https://aws.amazon.com/rds/instance-types/).
### 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.