Ich bin ziemlich überrascht, dass ich nirgendwo auf der Site und auch nicht in der MySQL-Dokumentation eine Antwort darauf finden kann (Abschnitt 5.2scheint die Protokollierung ansonsten gut abgedeckt zu haben!)
Wenn ich Binlogs aktiviere, sehe ich (subjektiv) einen kleinen Leistungseinbruch, was bei etwas mehr IO zu erwarten ist – aber wenn ich ein allgemeines Abfrageprotokoll aktiviere, sehe ich einen enormen Leistungseinbruch (doppelte Zeit zum Ausführen von Abfragen oder schlimmer), der weit über das hinausgeht, was ich mit Binlogs sehe. Natürlich protokolliere ich jetzt jedes SELECT sowie jedes UPDATE/INSERT, aber andere Daemons zeichnen jede ihrer Anfragen auf (Apache, Exim), ohne zum Stillstand zu kommen.
Sehe ich nur die Auswirkungen davon, dass ich mich in Bezug auf IO einem Leistungs-„Kipppunkt“ nähere, oder gibt es etwas grundsätzlich Schwieriges beim Protokollieren von Abfragen, das dies verursacht? Ich würde gerne alle Abfragen protokollieren können, um die Entwicklung zu vereinfachen, aber ich kann nicht rechtfertigen, welche Art von Hardware wir meiner Meinung nach benötigen würden, um die Leistung mit aktivierter allgemeiner Abfrageprotokollierung wieder zu steigern.
Natürlich protokolliere ich langsame Abfragen und die Verbesserung der allgemeinen Nutzung ist kaum nennenswert, wenn ich dies deaktiviere.
(All dies basiert auf Ubuntu 10.04 LTS, MySQLd 5.1.49, aber Untersuchungen legen nahe, dass dies ein ziemlich universelles Problem ist.)
Antwort1
Allgemeine Abfrageprotokolle sind einvielmehr IO als Binärprotokolle. Abgesehen davon, dass die meisten SQL-Server zu 90 % aus Lese- und zu 10 % aus Schreibvorgängen bestehen, werden die Binärprotokolle in einem Binärformat und nicht in reinem Text gespeichert, was weniger Speicherplatz beansprucht. (Wie viel weniger Speicherplatz? Ich bin nicht sicher. Tut mir leid.)
Es gibt zwei Gründe, warum Apache und Exim jede Anfrage ohne nennenswerte Leistungseinbußen aufzeichnen können. Erstens zeichnen sie zwar die Tatsache auf, dass eine Anfrage stattgefunden hat, aber was sie ins Protokoll schreiben, ist normalerweise deutlich kleiner als die eigentliche Anfrage. Eine HTTP-Anfrage ist oft doppelt so lang wie die Zeile, die ins Protokoll kommt, und selbst eine kurze E-Mail im Klartext ist 10 oder 20 Mal länger als die dazugehörige Protokollzeile. Bei einer E-Mail mit einem 10 MB großen Anhang werden trotzdem nur wenige Zeilen ins Protokoll geschrieben.
Der zweite Aspekt besteht darin, dass in einer normalen Webanwendung normalerweise Dutzende von SQL-Anfragen mit einer einzigen HTTP-Seite verknüpft sind. E-Mails kommen in der Regel in noch geringerer Zahl als HTTP-Anfragen. Ihr MySQL-Server versucht wahrscheinlich, viel mehr zu protokollieren als Apache oder Exim.
Schauen 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 werden feststellen, dass das allgemeine MySQL-Protokoll mindestens fünfmal so groß ist.
Antwort2
Zur Ergänzung der bereitgestelltenAntwort, werden Sie auch dann eine Leistungseinbuße feststellen, wenn Sie sich bei demselben Gerät anmelden, auf dem sich Ihre MySQL-Datenspeicher befinden – wenn es sich um dieselbe Festplatte handelt, lesen und schreiben Sie die ganze Zeit an mehreren Orten, was den gesamten Prozess verlangsamt.
Dies gilt auch, wenn es sich um eine andere Partition auf derselben physischen Festplatte handelt.
Wenn die Protokollierung auf ein anderes Gerät erfolgt, sollte dasmancheder Leistungsprobleme.