Un sacco di "Fine query" afferma in MySQL, tutte le connessioni utilizzate in pochi minuti

Question

Questa mattina ho notato che il carico del nostro server MySQL stava salendo alle stelle. Max dovrebbe essere 8 ma ha colpito più di 100 in un punto. Quando ho controllato l'elenco dei processi ho trovato molte query di aggiornamento (quelle semplici, che incrementavano un "hitcounter") che erano nello stato query end. Non potremmo ucciderli (beh, potremmo, ma sono rimasti nello stato killed indefinitamente) e il nostro sito si è fermato.

Abbiamo avuto molti problemi a riavviare il servizio e abbiamo dovuto forzare alcuni processi. Quando lo abbiamo fatto, siamo riusciti a far tornare MySQLd, ma i processi hanno iniziato a riacquistare immediatamente. Per quanto ne sappiamo, nessuna configurazione è stata modificata a questo punto.

Quindi, abbiamo modificato innodb_flush_log_at_trx_commit da 2 a 1 (si noti che abbiamo bisogno di conformità ACID) nella speranza che questo risolva il problema e impostare le connessioni in PHP/PDO per essere persistenti. Questo sembrava funzionare per un'ora o giù di lì, e poi le connessioni iniziarono a esaurirsi di nuovo.

Fortunatamente, ho impostato un server slave fino a un paio di mesi fa e sono stato in grado di promuoverlo e per il momento sta assorbendo il gioco, ma ho bisogno di capire perché questo è successo e come fermarlo, dal momento che lo schiavo il server è notevolmente sottodimensionato rispetto al master, quindi ho bisogno di tornare presto.

Qualcuno ha qualche idea? Potrebbe essere che qualcosa debba essere ripulito? Non so cosa, forse i registri binari o qualcosa del genere? Qualche idea? È estremamente importante poter recuperare questo server come il master ASAP ma francamente non ho idea di dove cercare e tutto ciò che ho provato finora ha portato solo a una soluzione temporanea.

Help! :)

Answer 1

Risponderò alla mia domanda qui. Ho controllato le dimensioni delle partizioni con un semplice comando df e lì ho potuto vedere che/var era pieno al 100%. Ho trovato un archivio che qualcuno aveva lasciato che era di 10 GB. Eliminato che, avviato MySQL, è stata eseguita una query PURGE LOGS BEFORE '2012-10-01 00:00:00' per eliminare un carico di spazio e ridotto la dimensione della directory/var/lib/mysql da 346 GB a 169 GB. Ritornato al master e tutto è di nuovo alla grande.

Da questo ho imparato che i nostri file di registro diventano MOLTO grandi, MOLTO rapidamente. Quindi stabilirò una routine di manutenzione per non solo tenere giù i file di registro, ma anche per avvisarmi quando ci avvicineremo a una partizione completa.

Spero che sia utile a qualcuno in futuro che si imbatte in questo con lo stesso problema. Controlla il tuo spazio di guida! :)

Answer 2

Abbiamo avuto un problema molto simile, in cui la lista di processi mysql ha mostrato che quasi tutte le nostre connessioni erano bloccate nello stato "query end". Il nostro problema era anche legato alla replica e alla scrittura del binlog.

Abbiamo modificato la variabile sync_binlog da 1 a 0, il che significa che invece di eseguire il flushing delle modifiche binlog su disco su ciascun commit, consente al sistema operativo di decidere quando fsync() nel binlog. Questo ha completamente risolto il problema della "fine della query" per noi.

Secondo this post from Mats Kindahl, scrivere nel binlog non sarà un problema nella versione 5.6 di MySQL.

Answer 3

Nel mio caso, era indicativo del massimo carico di I/O su disco. Avevo già ridotto al minimo i fsync, quindi non era quello. Un altro sintomo è "log * .tokulog *" i file iniziano ad accumularsi perché il sistema non riesce a recuperare tutte le scritture.