Die Protokollierung beeinträchtigt die MySQL-Leistung - aber warum?

Ich bin ziemlich überrascht, dass ich weder auf der Website noch in der MySQL-Dokumentation eine Antwort darauf finden kann ( Abschnitt 5.2 scheint die Protokollierung ansonsten gut abgedeckt zu haben!).

Wenn ich Binlogs aktiviere, wird (subjektiv) ein kleiner Leistungseinbruch angezeigt, der mit einem kleinen zusätzlichen E / A zu erwarten ist. Wenn ich jedoch ein allgemeines Abfrageprotokoll aktiviere, wird ein enormer Leistungseinbruch angezeigt (doppelte Zeit zum Ausführen von Abfragen). oder schlimmer), weit über das hinaus, was ich mit Binlogs sehe. Natürlich protokolliere ich jetzt jedes SELECT sowie jedes UPDATE / INSERT, aber andere Daemons zeichnen jede Anfrage (Apache, Exim) auf, ohne anzuhalten.

Sehe ich nur die Auswirkungen der Nähe zu einem "Wendepunkt" der Leistung, wenn es um E / A geht, oder ist das Protokollieren von Abfragen etwas grundlegend Schwieriges, das dies verursacht? Ich würde gerne in der Lage sein, alle Abfragen zu protokollieren, um die Entwicklung zu vereinfachen, aber ich kann die Art von Hardware nicht rechtfertigen, die wir benötigen, um die Leistung bei der allgemeinen Anmeldung von Abfragen wiederherzustellen.

Ich protokolliere natürlich langsame Abfragen, und es gibt eine vernachlässigbare Verbesserung der allgemeinen Verwendung, wenn ich dies deaktiviere.

(All dies ist unter Ubuntu 10.04 LTS, MySQLd 5.1.49, aber die Forschung legt nahe, dass dies ein ziemlich universelles Problem ist.)

Allgemeine Abfrageprotokolle sind viel mehr E / A als Binärprotokolle. Neben der Tatsache, dass die meisten SQL Server zu 90% gelesen und zu 10% geschrieben werden, werden die Binärprotokolle in einem Binärformat gespeichert und nicht in einfachem Text, der weniger Speicherplatz benötigt. (Wie viel weniger Platz? Ich bin nicht sicher. Entschuldigung.)

Es gibt zwei Aspekte, warum Apache und Exim jede Anforderung ohne wesentliche Auswirkungen auf die Leistung aufzeichnen können. Das erste ist, dass sie die Tatsache aufzeichnen, dass eine Anfrage stattgefunden hat, aber was sie in das Protokoll eintragen, ist normalerweise erheblich kleiner als die tatsächliche Anfrage. Eine HTTP-Anforderung ist häufig doppelt so groß wie die Zeile im Protokoll, und selbst eine kurze Nur-Text-E-Mail ist 10- oder 20-mal größer als die dazugehörige Protokollzeile. Bei einer E-Mail mit einem 10-MB-Anhang werden nur noch wenige Zeilen in das Protokoll geschrieben.

Der zweite Teil davon ist, dass in einer normalen Webanwendung normalerweise Dutzende von SQL-Abfragen einer einzelnen HTTP-Seite zugeordnet sind. E-Mails kommen in der Regel in noch geringerer Anzahl als HTTP-Anfragen. Ihr MySQL-Server versucht wahrscheinlich, viel mehr als Apache oder Exim zu protokollieren.

Sehen Sie sich am Ende des Tages die Größe (unkomprimiert) Ihrer MySQL-Binär- und allgemeinen Protokolle sowie Ihrer Apache- und Exim-Protokolle an. Ich wette, Sie finden, dass das allgemeine MySQL-Protokoll mit einem Faktor von mindestens 5 das größte ist.

Um die bereitgestellte Antwort zu ergänzen , wird auch ein Leistungseinbruch angezeigt, wenn Sie sich auf demselben Gerät anmelden, auf dem sich Ihre MySQL-Datenspeicher befinden. Wenn es sich um dieselbe Festplatte handelt, werden Sie an mehreren Speicherorten lesen und schreiben die ganze Zeit, verlangsamt den gesamten Prozess.

Dies gilt auch dann, wenn es sich um eine andere Partition auf derselben physischen Festplatte handelt.

Wenn die Protokollierung auf einem anderen Gerät erfolgt, sollten einige Leistungsprobleme behoben werden.