Publié le: 2013-04-10

PostgreSQL 9.1 benchmark

Suite à une volonté de tester l’arbre de dports de DragonFlyBSD, et voulant voir ce que vallaient les performances de PostGreSQL sur DragonFlyBSD j’ai décidé de monter un rapide benchmark de performances afin de comparer plusieurs systèmes ayant une version de PostGreSQL commune. J’ai choisi pour ces raisons PostGreSQL 9.1.

Lors de mon benchmark sous Linux (Debian), je me suis retrouvé confronté à des statistiques étonnantes en terme de performances, de ce fait, j’ai décidé de voir ce que vallait une Redhat, j’ai donc pris Centos 6.4.

Les tests ont été effectués sur les plateformes suivantes:

  • DragonFlyBSD 3.4.1 (système de fichiers Hammer)
  • FreeBSD 9.1-p3 (système de fichiers UFS2+J)
  • FreeBSD 9.1-p3 (système de fichiers ZFS v28)
  • Debian 7: Wheezy (système de fichiers ext4)
  • Centos 6.4 (système de fichiers ext4)

En terme de hardware, le test a été effectué sur un système de virtualisation de type KVM (libvirt) avec 24GBit de mémoire et un processeur Phenom x6 1055T

qemu 1.4.1-3
libvirt 1.0.5-4

Chaque machine virtuelle possède les caractéristiques suivantes:

  • 50Go de disque (virtio pour tous les OS sauf FreeBSD)
  • 12Go de mémoire
  • 4 coeurs de processeur

Passons maintenant au benchmark. La commande utilisée est la suivante: pgbench -T 60 -cX -jX Concrètement, nous demandons à l’utilitaire pgbench de faire un test de 60 secondes sur la base de données, en utilisant X clients et X threads (1 client par thread). Chacune des bases de données est configurée par défaut, avec un support de 300 connexions simultannées.

Première partie: test sur disque virtuel

Le premier graphique représentera le nombre de transations sur la durée, le second par secondes. PGBench1 PGBench2

Le test de performances est surprenant. Nous avons en tête DragonFlyBSD qui surpasse tous les autres systèmes, suivi par FreeBSD. Les performances de DragonFlyBSD sont exceptionnelles, et dépassent de plus de 25% celles de FreeBSD lors de la montée en charge et de près de 200% les Linux.

Loin derrière, avec des performances 2 à 3 fois moindres, nous avons les deux Linux (Debian et Centos) qui plafonnent à près de 7000 transactions sur la durée sans vraiment les dépasser, et peu importe le nombre de clients. Cette courbe est particulièrement étonnante, d’une uniformité sans faille. Seul Debian ne réussit pas à passer le test entièrement en n’arrivant pas à gérer plus de 100 connexions sans devoir à toucher d’autres paramètres.

En fait, cette valeur de 7000 s’explique par l’option barrier du système de fichiers ext4. L’option protège le système de fichiers de la corruption des données en cas de panne matérielle (reboot inopiné…), et bride complètement les performances de PostgreSQL. Dans un second test nous avons ajouté l’option nobarrier/barrier=0 au système de fichiers (via /etc/fstab).

Notez que cette option est risquée, si un redémarrage dû à un problème d’alimentation survient, les fichiers en cours d’écriture sur le disque, voir l’ensemble du système de fichiers peuvent être corrompus. Ne l’utilisez que si vous possédez un contrôleur RAID matériel (Raid 1/5/6) avec une batterie.

Enfin, bon dernier, notre FreeBSD avec ZFS peine à rattraper les Linux. Peut être est-ce dû à la virtualisation ? Ou bien à la conception du système de fichiers lui-même ?

Seconde partie: test sur disque physique

Afin de vérifier nos résultats, il a été décidé de réaliser le même benchmark sur disque Physique. J’ai retenu uniquement les performances avec optimisations, hormis pour ZFS, qui devait avoir un point de comparaison en terme de performances sur disque physique (gérant la couche blocks). Centos a également été écartés n’offrant que peu de différences par rapport à Debian (un peu moins performant). Cette première courbe montre le nombre de transactions totales sur 1 minute: benchpostgrereal1 Cette seconde capture définit le nombre de transactions par secondes traitées: benchpostgrereal2 Etonnament DragonFlyBSD a des performances quasiment identiques à celles sur disque virtuel, ce qui pourrait signifier que les drivers virtio sont très performants et au point. Debian reste aussi performant en virtuel qu’en physique, et plafone à 50K transactions par minute. Les deux points qu’on pourra remarquer sont:

  • Les performances d’UFS (options async et noatime activées), qui doublent voire triplent avec l’optimisation, mais nécessitent les mêmes précautions que le nobarrier de ext4
  • ZFS multiplie par 10-15 ses performances en activant les optimisations sync=disabled et atime=off, surpassant nettement tout autre système de fichier et offrant des performances défiant toute concurrence. De plus l’option sync=disabled est moins dangeureuse que les options de débridages des autres systèmes de fichiers, bien que peu recommandée pour une base de données nécessitant un maximum de fiabilité en cas de panne.

ZFS est donc le leader sur ce benchmark physique, une fois débridé. En virtuel peut-être atteint-il les mêmes performances ?

Conclusion

Vous retrouverez les données complètes du benchmark dans le lien suivant: Benchmarks - PostGreSQL

En conclusion, si vous deviez choisir un système pour vos bases de données PostGreSQL, orientez vous sur un BSD sans hésiter, que ce soit un FreeBSD (UFS) ou un DragonFlyBSD (Hammer) si vous ne possédez pas de contrôleur raid matériel autrement choississez un Linux avec ext4 et nobarrier, ou encore un FreeBSD avec UFS avec async et noatime.

ZFS sur FreeBSD avec les options sync=disabled et atime=off est très tentant (n’oublions pas que NetApp est un FreeBSD avec ZFS), et devra nécessiter le raccordement des disques directements sur la carte mère sans passer par le contrôleur RAID

Merci à Emmanuel Florac et Axel Perrier pour leurs précisions sur l’option nobarrier