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à.
invio dei dati
Lo stato del thread sending data indica che un thread sta leggendo e filtrando le righe per una query per determinare la serie di risultati corretti. Il nome è fuorviante perché implica che lo stato sta trasferendo i dati, non raccogliendo e preparando i dati da inviare in seguito.
Versioni del motore supportate
Queste informazioni sullo stato del thread sono supportate per le seguenti versioni:
-
Aurora MySQL versione 2 fino alla 2.09.2
Context
Molti stati del thread sono di breve durata. Operazioni che si verificano durante sending
data tendono a eseguire un numero elevato di letture su disco o cache. Pertanto, sending data è spesso lo stato di esecuzione più lungo per tutta la durata di una determinata query. Questo stato viene visualizzato quando Aurora MySQL sta effettuando le seguenti operazioni:
-
Lettura ed elaborazione di righe per un’istruzione
SELECT -
Esecuzione di un numero elevato di letture da disco o memoria
-
Completamento di una lettura completa di tutti i dati da una query specifica
-
Lettura di dati da una tabella, da un indice o dal lavoro di una procedura archiviata
-
Ordinamento, raggruppamento o ordinamento dei dati
Dopo che lo stato sending data termina la preparazione dei dati, lo stato del thread writing to net indica il ritorno dei dati al client. Tipicamente writing to net viene acquisito solo quando la serie di risultati è molto grande o una latenza di rete grave rallenta il trasferimento.
Probabili cause di aumento delle attese
La comparsa di sending data non indica di per sé un problema. Se le prestazioni sono scadenti e si vedono frequenti istanze di sending data, le cause più probabili sono le seguenti.
Query inefficiente
Nella maggior parte dei casi, ciò che è responsabile di questo stato è una query che non utilizza un indice appropriato per trovare la serie di risultati di una query specifica. Ad esempio, si consideri una query che legge una tabella di dati di 10 milioni per tutti gli ordini effettuati in California, in cui la colonna di stato non è indicizzata o è scarsamente indicizzata. In quest'ultimo caso, l'indice potrebbe esistere, ma l'ottimizzatore lo ignora a causa della bassa cardinalità.
Configurazione del server non ottimale
Se vengono visualizzate diverse query nello stato sending data, il server di database potrebbe essere configurato in modo errato. In particolare, il server potrebbe presentare i seguenti problemi:
-
Il server di database non dispone di capacità di calcolo sufficiente: I/O del disco, tipo e velocità del disco, CPU o numero di CPU.
-
Il server necessita delle risorse allocate, come il pool di buffer di InnoDB per le tabelle InnoDB o il buffer di chiavi per le tabelle MyIsam.
-
Impostazioni di memoria per thread come
sort_buffer,read_bufferejoin_bufferconsumano più RAM di quanto richiesto, portando il server fisico a necessitare risorse di memoria.
Operazioni
La linea guida generale consiste nel trovare query che restituiscono un numero elevato di righe controllando il Performance Schema. Se la registrazione di query che non utilizzano indici è attivata, è anche possibile esaminare i risultati dei registri lenti.
Argomenti
Attiva il Performance Schema se non è attivato
Performance Insights segnala gli stati del thread solo se gli strumenti di Performance Schema non sono attivati. Quando gli strumenti di Performance Schema sono attivati, Performance Insights segnala invece gli eventi di attesa. Gli strumenti di Performance Schema forniscono informazioni dettagliate aggiuntive e strumenti migliori quando si esaminano potenziali problemi di prestazione. Pertanto, è consigliabile attivare il Performance Schema. Per ulteriori informazioni, consulta Panoramica dello schema delle prestazioni per Performance Insights su Aurora My SQL Amazon o My SQL.
Analisi delle impostazioni della memoria
Esaminare le impostazioni di memoria per i pool di buffer primari. Assicurarsi che questi pool siano ridimensionati in modo appropriato per il carico di lavoro. Se il database utilizza più istanze del pool di buffer, assicurati che non siano divisi in molti piccoli pool di buffer. I thread possono utilizzare solo un pool di buffer alla volta.
Assicurarsi che le seguenti impostazioni di memoria utilizzate per ciascun thread siano dimensionate correttamente:
-
read_buffer
-
read_rnd_buffer
-
sort_buffer
-
join_buffer
-
binlog_cache
A meno che non si abbiano ragioni specifiche per modificare le impostazioni, utilizzare i valori predefiniti.
Esaminare i piani di spiegazione per l'utilizzo dell'indice
Per queri nello stato del thread sending data, esaminare il piano per determinare se vengono utilizzati indici appropriati. Se una query non utilizza un indice utile, si prenda in considerazione l'aggiunta di suggerimenti come USE INDEX o FORCE
INDEX. I suggerimenti possono aumentare o diminuire notevolmente il tempo necessario per eseguire una query, quindi occorre prestare attenzione prima di aggiungerli.
Controllare il volume di dati restituiti
Controllare le tabelle sottoposte a query e la quantità di dati che contengono. È possibile archiviare qualcuno di questi dati? In molti casi, la causa di tempi di esecuzione delle query scadenti non è il risultato del piano della query, ma il volume di dati da elaborare. Molti sviluppatori sono molto efficienti nell'aggiungere dati a un database, ma raramente considerano il ciclo di vita del set di dati nelle fasi di progettazione e sviluppo.
Si consiglia di cercare query che funzionino bene nei database con volumi ridotti ma che funzionino male nel sistema attuale. A volte gli sviluppatori che progettano query specifiche potrebbero non rendersi conto che queste query restituiscono 350.000 righe. Gli sviluppatori potrebbero aver sviluppato le query in un ambiente con volumi inferiori con set di dati più piccoli rispetto agli ambienti di produzione.
Verifica la presenza di problemi di concorrenza
Verifica se sono in esecuzione contemporaneamente più query dello stesso tipo. Alcune forme di query vengono eseguite in modo efficiente quando vengono eseguite da sole. Tuttavia, se forme di query simili vengono eseguite insieme o in volume elevato, possono causare problemi di concorrenza. Spesso questi problemi sono causati quando il database utilizza tabelle temporanee per restituire dei risultati. Un livello di isolamento restrittivo delle transazioni può anche causare problemi di concorrenza.
Se le tabelle vengono lette e scritte contemporaneamente, il database potrebbe utilizzare i blocchi. Per aiutare a identificare i periodi di prestazioni scadenti, esaminare l'uso dei database attraverso processi batch su larga scala. Per visualizzare i blocchi e i ripristini degli stati precedenti recenti, esaminare l'output del comando SHOW ENGINE INNODB STATUS.
Verificare la struttura delle query
Verifica se le query acquisite da questi stati utilizzano sottoquery. Questo tipo di query spesso porta a prestazioni scadenti perché il database compila i risultati internamente e li sostituisce nuovamente nella query per la restituzione dei dati. Questo processo è un passaggio aggiuntivo per il database. In molti casi, questo passaggio può causare prestazioni scadenti in condizioni di caricamento altamente concomitante.
Controlla anche se le tue query utilizzano un numero elevato di clausole ORDER BY e GROUP BY. In tali operazioni, spesso il database deve prima formare l'intero set di dati in memoria. Quindi deve ordinarlo o raggrupparlo in modo specifico prima di restituirlo al client.
