La journalisation nuit aux performances de MySQL - mais pourquoi?

Je suis assez surpris de ne pas voir de réponse à cela nulle part sur le site, ni dans la documentation MySQL (la section 5.2 semble avoir une journalisation bien couverte sinon!)

Si j'active les binlogs, je vois un petit hit de performance (subjectivement), ce qui est normal avec un peu d'E / S supplémentaire - mais quand j'active un journal de requête général, je vois un énorme hit de performance (doubler le temps d'exécution des requêtes, ou pire), bien au-delà de ce que je vois avec les binlogs. Bien sûr, j'enregistre maintenant chaque SELECT ainsi que chaque UPDATE / INSERT, mais, d'autres démons enregistrent chacune de leurs requêtes (Apache, Exim) sans s'arrêter.

Suis-je juste en train de voir les effets d'être proche d'un «point de basculement» des performances en ce qui concerne les E / S, ou y a-t-il quelque chose de fondamentalement difficile dans la journalisation des requêtes qui provoque cela? J'adorerais pouvoir journaliser toutes les requêtes pour faciliter le développement, mais je ne peux pas justifier le type de matériel dont nous avons besoin pour obtenir des performances de sauvegarde avec la connexion générale aux requêtes.

Bien sûr, je journalise les requêtes lentes, et il y a une amélioration négligeable de l'utilisation générale si je la désactive.

(Tout cela est sur Ubuntu 10.04 LTS, MySQLd 5.1.49, mais la recherche suggère que c'est un problème assez universel)

Les journaux de requête généraux sont beaucoup plus d'E / S que les journaux binaires. Outre le fait que la plupart des serveurs SQL effectuent 90% des lectures pour 10% des écritures, les journaux binaires sont stockés dans un format binaire plutôt que du texte brut qui utilise moins d'espace disque. (Combien d'espace en moins? Je ne suis pas sûr. Désolé.)

Il existe deux aspects pour lesquels Apache et Exim peuvent enregistrer chaque demande sans impact significatif sur les performances. La première est qu'ils enregistrent le fait qu'une demande a eu lieu mais que ce qu'ils ont mis dans le journal est généralement beaucoup plus petit que la demande réelle. Une requête HTTP est souvent deux fois plus grande que la ligne qui va dans le journal et même un court e-mail en texte brut est 10 ou 20 fois plus grand que la ligne de journal qui l'accompagne. Un e-mail avec une pièce jointe de 10 Mo n'aura toujours que quelques lignes écrites dans le journal.

La deuxième partie est que dans une application Web normale, il existe généralement des dizaines de requêtes SQL associées à une seule page HTTP. Les e-mails ont tendance à venir en nombre encore plus petit que les requêtes HTTP. Votre serveur MySQL essaie probablement de se connecter bien plus que Apache ou Exim.

Regardez la taille (non compressée) de vos journaux binaires et généraux MySQL et de vos journaux Apache et Exim à la fin de la journée. Je parie que vous trouvez que le journal général MySQL est le plus grand par un facteur d'au moins 5.

Pour ajouter à la réponse fournie , vous verrez également un impact sur les performances si vous vous connectez au même appareil que vos magasins de données MySQL - si c'est le même disque, vous allez lire et écrire à plusieurs emplacements tout le temps, ralentissant tout le processus.

Cela est vrai même s'il s'agit d'une partition différente sur le même disque physique.

Si la journalisation va sur un autre appareil, cela devrait atténuer certains des problèmes de performances.