it-swarm.it

Perché i thread MySQL mostrano spesso lo stato di "liberazione di elementi" quando la cache delle query è disabilitata?

Quando corro SHOW PROCESSLIST, ci sono spesso un gran numero di thread INSERT/UPDATE nello stato "liberazione di elementi".

Il manuale di MySQL suggerisce che almeno una parte del motivo per cui un thread si trova in questo stato riguarda la cache delle query - presumibilmente sarebbe invalidare le query memorizzate nella cache a causa dei dati modificati.

Tuttavia, il mio query_cache_size è impostato su 0 che dovrebbe disabilitare del tutto la cache delle query.

Quali altri motivi ci sarebbero per avere così tanti thread in questo stato?

Le tabelle pertinenti utilizzano il motore di archiviazione InnoDB.

16
Dan Grossman

Controlla il valore di innodb_thread_concurrency.

Per il mio sistema, l'aumento del valore da 8 a 32, secondo le linee guida in documentazione MySql , ha provocato una discreta diminuzione del numero di thread che riportavano contemporaneamente lo stato "liberazione di elementi". Inoltre, il tempo di query medio obesrved è sceso di un ordine di grandezza.

Sebbene ciò abbia fatto una grande differenza nelle prestazioni complessive del server, non è stato il proiettile d'argento "liberare oggetti". Il mio ecosistema hardware mi porta a ipotizzare che questo stato sia visto principalmente sui sistemi con dischi "lenti" (2x10k dischi raid 1) ed è meno prevalente su sistemi con storage più veloce (12x15k dischi raid 10). Pertanto, può anche essere garantito un controllo delle prestazioni del disco.

In bocca al lupo!

Anche:

Vale la pena notare che il valore predefinito di innodb_thread_concurrency è radicalmente diverso a seconda del rilascio del punto 5.0 utilizzato.

Il valore predefinito è stato modificato più volte: 8 prima di MySQL 5.0.8, 20 (infinito) da 5.0.8 a 5.0.18, 0 (infinito) da 5.0.19 a 5.0.20 e 8 (finito) da 5.0.21 su. - fonte

Ciò significa che un aggiornamento apparentemente innocuo dalla 5.0.20 alla 5.0.21 ha cambiato il valore predefinito da infinito a 8 e ha portato con sé le ramificazioni delle prestazioni.

7
jphofmann

La liberazione di elementi è una fase di esecuzione della query in cui strutture temporanee, buffer, ecc. Sono deallocati. In questa fase viene eseguita una parte della query cache, ma non è l'unica cosa che accade lì. Suggerirei di utilizzare SHOW PROFILES per vedere quanto tempo impiega questa fase rispetto ad altre fasi, e se il tempo impiegato finisce per essere un problema, la risoluzione dei problemi con strumenti come il profiler del povero e l'oprofile.

5
Baron Schwartz

È stato segnalato un bug su questo problema relativo a "liberare elementi" e cache delle query . Sebbene il bug sia chiuso, non è stato menzionato innodb_thread_concurrency .

Per coincidenza, ho parlato con Ronald Bradford al Percona Live di New York a maggio. Gli ho raccontato di una situazione in cui ho twittato innodb_thread_concurrency perché il multiplo pool di buffer InnoDB di MySQL 5.5 ha prodotto un sacco di blocco dei thread e sospettavo che i dati memorizzati nella cache di cui avevo bisogno molto probabilmente si fossero diffusi tra i pool di buffer multipli.

Mi ha chiaramente detto che non avrei mai dovuto impostare valori contro innodb_thread_concurrency. Lascia che sia sempre il valore predefinito, che ora è zero (0). In questo modo, lasci che l'archiviazione InnoDB decida quanti innodb_concurrency_tickets generare da solo. Questo è ciò che fa la concorrenza infinita.

Molto probabilmente "liberare oggetti" si verifica più spesso quando imponiamo limiti a innodb_thread_concurrency. Dovrebbe essere sempre zero (0). Vorrei correre un rischio e sollevare innodb_concurrency_tickets e vedere se aiuta o no.

3
RolandoMySQLDBA

Abbiamo avuto un problema con esattamente gli stessi sintomi. Si è scoperto che il disco con i file di registro di InnoDB si è riempito. Vale la pena controllare.

2
RedBlueThing

Un altro suggerimento: potrebbe essere innodb fsync (). Prova a impostare

innodb_flush_log_at_trx_commit = 2

In my.cnf

Il file di registro innodb viene quindi scaricato su disco ogni 1-2 secondi, invece di eseguire ogni commit. Leggera penalità per l'integrità dei dati, grande guadagno in velocità.

1
sto