Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.
synch/sxlock/innodb/hash_table_locks
L'synch/sxlock/innodb/hash_table_locksevento si verifica quando le pagine non trovate nel buffer pool devono essere lette dallo storage.
Versioni del motore supportate
Queste informazioni sull'evento di attesa sono supportate per le seguenti versioni:
-
Aurora MySQL versioni 2 e 3
Context
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
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.
Argomenti
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
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 utilizzandomysqli_result:: fetch_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
Accedi alla AWS Management Console e apri la console Amazon RDS all'indirizzo https://console.aws.amazon.com/rds/
. -
Nel pannello di navigazione scegli Approfondimenti sulle prestazioni.
-
Scegli un'istanza database. Viene visualizzato il pannello di controllo di Approfondimenti sulle prestazioni per l'istanza database.
-
Nel grafico Carico del database, scegli Dividi per attesa.
-
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
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
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.
