Performances de postgresql 8.3

Il était grand temps que je passe à PostgreSQL 8.3. Je ne sais d'ailleurs pas bien pourquoi j'ai autant retardé cette migration qui m'a prise en tout et pour tout 10 minutes. Toujours est-il que j'en ai profité pour tenter quelques tests de performances dont voici les résultats.

Performances de la 8.2

Il ne faut pas se leurrer PostgreSQL est clairement un poil en dessous des performances de mySQL. Un gros poil en MyISSAM, et un petit poil en InnoDB. ceci dit, il faut comparer ce qui est comparable et MyISSAM étant bien loin de ce que l'on peut attendre d'une base de données. De toute façon je ne ferais aucune comparaison car 1/ cela attires les trolls comme les mouches et 2/ En 3 ans sous PostgreSQL je n'ai jamais perdu une seule donnée, ce qui est loin d'être le cas MySQL.

Pour commencer, utilisation de l'ami pgbench pour vérifier le nombre de transactions par minutes avec l'ancienne 8.2, histoire de voir ce qui a évolué.

root#createdb tests

Database created

root#pgbench -i -U postgres tests

creating tables...

10000 tuples done.

20000 tuples done.

...

root#pgbench -s 10 -c 10 -t 100 -U postgres tests

starting vacuum...end.

transaction type: TPC-B (sort of)

scaling factor: 1

number of clients: 10

number of transactions per client: 100

number of transactions actually processed: 1000/1000

tps = 190.293871 (including connections establishing)

tps = 192.064251 (excluding connections establishing)

root# 

Performances de la 8.3

Oui je sais, c'est pas beaucoup, une bonne vieille dedibox v1 avec son gentil via c7, faut pas non plus s'attendre à des miracles . Maintenant mise à jour vers la 8.3 et re-test.

root#pgbench -s 10 -c 10 -t 100 -U postgres tests

starting vacuum...end.

transaction type: TPC-B (sort of)

scaling factor: 1

number of clients: 10

number of transactions per client: 100

number of transactions actually processed: 1000/1000

tps = 210.847159 (including connections establishing)

tps = 213.308078 (excluding connections establishing)

root# 

12% de performances supplémentaires comme cela, hors de la boîte comme on dit, c'est plutôt pas mal.

Optimisation de la 8.3

Après il est toujours possible d'optimiser. Le plus classique consiste à augmenter l'espace de mémoire partagée à 25% de la mémoire totale, la taille du cache à 50%, et l'espace de hashage par session à disons 32mo. Ce qui nous donne à rajouter dans postgresql.conf les lignes suivantes :

shared_buffers = 256MB
work_mem=32MB
effective_cache_size = 512MB

L'autre optimisation, un peu plus casse-binette, consiste à déconnecter le fsync à chaque transaction, laissant cela au système de fichier sous-jacent. Attention, en cas de panne électrique, ceci peut entraîner une corruption des données. Mais avec des backups toutes les nuits et une si petite bécane, c'est un risque que je prends.

fsync=false
full_page_writes=false

Il ne reste dés lors plus qu'à tester les nouveaux réglages.

starting vacuum...end.

transaction type: TPC-B (sort of)

scaling factor: 1

number of clients: 10

number of transactions per client: 100

number of transactions actually processed: 1000/1000

tps = 230.752581 (including connections establishing)

tps = 233.833402 (excluding connections establishing)

root# 

Et hop, 10% de performances en plus, c'est toujours ça de pris.

Dans la série des optimisations, j'ai aussi tenté d'ajouter pgpool qui m'aurait permis d'après certains post glanés à droite à gauche, de gagner encore en vitesse grâce à son cache de connections et la parallélisation des requêtes. Et bien ce ne fût pas concluant du tout et même au contraire. Je ne sais pas si je m'y suis mal pris mais le résultat était moins bon avec pgpool que sans.

Conclusion

Voilà, il ne reste plus qu'à attendre la version 8.4 pour voir si les performances s'améliorent encore un peu plus permettant ainsi de rattraper les tout de même 20% en faveur de MySQL/InnoDB. En attendant mes basottes vivent très bien et pour rien au monde je ne reviendrait sur cette stabilité.