La registrazione danneggia le prestazioni di MySQL, ma perché?


9

Sono abbastanza sorpreso di non riuscire a vedere una risposta a questo già sul sito, né nella documentazione di MySQL (la sezione 5.2 sembra avere una registrazione altrimenti ben coperta!)

Se abilito i binlog, vedo un piccolo hit delle prestazioni (soggettivamente), che è prevedibile con un po 'di IO in più - ma quando abilito un registro generale delle query, vedo un enorme hit delle prestazioni (il doppio del tempo per eseguire query, o peggio), molto più di quello che vedo con i binlog. Ovviamente ora sto registrando ogni SELECT e ogni UPDATE / INSERT, ma altri demoni registrano ogni loro richiesta (Apache, Exim) senza fermarsi.

Sto solo vedendo gli effetti dell'essere vicini a un "punto di non ritorno" delle prestazioni quando si tratta di IO, o c'è qualcosa di fondamentalmente difficile nel registrare le query che causa questo? Mi piacerebbe essere in grado di registrare tutte le query per rendere più semplice lo sviluppo, ma non posso giustificare il tipo di hardware che sentiamo come se avessimo bisogno di ripristinare le prestazioni con l'accesso generale alle query.

Ovviamente, registro le query lente e c'è un miglioramento trascurabile nell'uso generale se lo disabilito.

(Tutto questo è su Ubuntu 10.04 LTS, MySQLd 5.1.49, ma la ricerca suggerisce che questo è un problema abbastanza universale)

Risposte:


9

I log di query generali sono molto più IO rispetto ai log binari. Oltre al fatto che la maggior parte dei server SQL ha una lettura del 90% e una scrittura del 10%, i registri binari sono archiviati in un formato binario anziché in testo normale che utilizza meno spazio su disco. (Quanto meno spazio? Non ne sono sicuro. Mi dispiace.)

Ci sono due aspetti per cui Apache ed Exim possono registrare ogni richiesta senza un impatto significativo sulle prestazioni. Il primo è che registrano il fatto che sia avvenuta una richiesta ma ciò che hanno inserito nel registro è di solito significativamente più piccolo della richiesta effettiva. Una richiesta HTTP è spesso doppia rispetto alla linea che va nel registro e anche una breve e-mail di testo semplice è 10 o 20 volte più grande della linea di registro che la accompagna. Un'e-mail con un allegato da 10 MB avrà ancora solo poche righe scritte nel registro.

La seconda parte è che in una normale applicazione Web di solito ci sono dozzine di query SQL associate a una singola pagina HTTP. Le e-mail tendono ad arrivare in numeri anche inferiori rispetto alle richieste HTTP. Il tuo server MySQL sta probabilmente provando a registrare molto più di Apache o Exim.

Guarda le dimensioni (non compresse) del tuo binario MySQL e dei registri generali e dei tuoi registri Apache ed Exim alla fine della giornata. Scommetto che troverai che il registro generale di MySQL è il più grande di un fattore di almeno 5.


1
Alcuni aspetti positivi - in particolare sì, un singolo OTTENERE alla nostra applicazione può causare centinaia di SELECT, poiché anche se proviamo a fare il più possibile in una singola query a volte scambiamo le prestazioni / pulizia di questo per struttura più elegante, codice più leggibile e un DB più pulito. (A parte questo, tutto è iniziato davvero parlando del contenuto dei POST di registrazione e dell'URL dei GET, poiché vediamo i parametri che CGI.pm vede in un caso e non nell'altro, e da lì in registrazione / prestazioni in generale). Comunque, sono passate alcune ore, quindi, risposta accettata. Grazie!
James Green,

4

Per aggiungere la risposta fornita , vedrai anche un aumento delle prestazioni se stai accedendo allo stesso dispositivo su cui risiedono i tuoi archivi di dati MySQL - se si trova sullo stesso disco, stai per leggere e scrivere in più posizioni continuamente, rallentando l'intero processo.

Questo è vero anche se si tratta di una partizione diversa sullo stesso disco fisico.

Se la registrazione sta andando su un dispositivo diverso, ciò dovrebbe alleviare alcuni dei problemi di prestazioni.


1
Non pertinente alla mia situazione: è una macchina virtuale ospitata e i DB si trovano su un volume logico separato su / var, fornito a sua volta dallo stesso array di archiviazione. Suppongo che in teoria potrebbero essere sugli stessi mandrini, ma sembrerebbe una coincidenza infernale :-) Detto questo, +1 a parte, perché questo sarebbe assolutamente rilevante per qualcuno con ad esempio un'impostazione Debian / Ubuntu predefinita (DB in / var / mysql, accedi / var / log)!
James Green,

@jimbo - grazie per gli oggetti di scena anche se non è direttamente applicabile alla tua situazione particolare :)
warren
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.