Il y a quelques mois, je me suis retrouvé confronté à un postreSQL complètement poussif sur une machine pourtant performante et fraichement installée. Alors PostgreSQL fautif ? Pas du tout car le même problème s'est reproduit sur une autre machine, mais cette fois tournant avec MySQL. La source du problème : EXT4.

EXT4 et la barrière d'écriture

En fait le problème apparaît uniquement en écriture. À haut débit, celles-ci peuvent être jusqu'à 30% plus lentes qu'avec un disque formaté sous EXT3. Les répercutions se font donc sentir sur tout système amené à écrire à haute fréquence, bases de données en tête évidemment.

La raison tient en un système ajouté pour garantir l'intégrité des caches lors des écritures. EXT4 va en effet émettre un "write barrier" (barrière d'écriture) à chaque synchronisation des caches (fsync). De la sorte, si un crash complet du système survient (ou si quelqu'un se prend les pieds dans les prises du rack de serveurs), EX4 garanti que je journal est parfaitement à jour. Tout ceci est très bien pour un serveur critique, c'est un peu moins pertinent pour une machine utilisée comme serveur web ou une machine de développement.

La "solution" consiste donc à désactiver la levée des barrières, ce qui se fait à chaud par

$sudo mount /dev/sdaX -o remount,nobarrier

levée des barrières d'écriture sur EXT4

Conclusion

On est bien d'accord que la chose n'est pas à faire sur une machine où l'atomicité des écritures est critique. Mais dans tous les autres cas, c'est un gain de 30% en écriture, ce qui m'a un peu sauvé la vie lors d'une énorme migration d'un PHPBB de 12 ans d'age sous Drupal :).