PostgreSQL 10 : installation des binaires et performances

de | 2017-09-08
0 Commentaire

La version « beta 4 » des PostgreSQL est sortie fin août et la date de la première version stable approche à grands pas (normalement fin septembre).

Sortant tout juste d’une journée d’ateliers organisée par Dalibo, nous vous proposons une série d’articles visant à vous préparer à la transition.

Aujourd’hui, par exemple, nous allons voir comment installer une distribution binaire en version 10 à coté d’une version 9.6, puis nous ferons quelques tests et reviendrons sur les mesures de performances dont les résultats étaient loin de ceux annoncés.

Pas de panique : la version 10 apporte en effet des améliorations visibles sur les performances. Il y a un juste un piège avec la version béta et cela fausse les mesures.

Avec une introduction aussi accrocheuse, pas de doute : vous allez cliquer sur « lire la suite » !

 

Installation de PostgreSQL 10

Première chose : récupérer la définition des dépôts Yum pour les développeurs car Postgresql 10 n’est pas encore disponible sur les dépôts habituels :


wget https://download.postgresql.org/pub/repos/yum//testing/10/redhat/rhel-6-x86_64/pgdg-centos10-10-1.noarch.rpm

yum install -y pgdg-centos10-10-1.noarch.rpm

Ensuite, installer les RPM :

 yum install -y postgresql10 postgresql10-server postgresql10-contrib

 

Initialiser l’instance v10 à l’aide de la commande initdb après avoir configuré votre environnement  :


su - postgres

export PGDATA=/var/lib/pgsql/10/data

export PATH=/usr/pgsql-10/bin:$PATH

initdb

pg_ctl start

Tester la connexion avec « psql ». Vous devez voir ceci :


-bash-4.2$ psql
psql (10beta4)
Saisissez « help » pour l'aide.

postgres=# select version();
version

------------------------------------------------------------------------------------------------------
------
PostgreSQL 10beta4 on x86_64-pc-linux-gnu, compiled by gcc (GCC) 4.8.5 20150623 (Red Hat 4.8.5-11), 6
4-bit
(1 ligne)

Bienvenue dans le futur. Passons maintenant à l’installation de la 9.6.

Installation de Postgresql 9.6

Mêmes commandes, seules la version change.

Pour pouvoir démarrer deux instances côte à côte, il faut modifier le port d’écoute de la seconde.


wget https://download.postgresql.org/pub/repos/yum/9.6/redhat/rhel-6-x86_64/pgdg-centos96-9.6-3.noarch.rpm

yum install -y pgdg-centos96-9.6-3.noarch.rpm

<span class="fontstyle0">yum install -y postgresql96 postgresql96-server postgresql96-contrib</span>

export PGDATA=/var/lib/pgsql/9.6/data

export PATH=/usr/pgsql-9.6/bin:$PATH

export PGPORT=5433

initdb

perl -pi.bak -e 's/#port = 5432/port = 5433/g' $PGDATA/postgresql.conf

pg_ctl start

Reste à tester la connexion et la version :


-bash-4.2$ psql
psql (9.6.5)
Saisissez « help » pour l'aide.

postgres=# select version();
version

------------------------------------------------------------------------------------------------------
----
PostgreSQL 9.6.5 on x86_64-pc-linux-gnu, compiled by gcc (GCC) 4.8.5 20150623 (Red Hat 4.8.5-11), 64-
bit
(1 ligne)

Nous voici donc avec nos deux instances installées et démarrées. Voyons comment elles se comportent.

 

Mesure des temps d’insertion

Dans chacune des instances, créer une base de test pour pgbench et l’initialiser :


psql> create database bench;

psql> exit;

shell> pgbench -i bench

Puis lancer un test pgbench en mode… hum… vigoureux :

pgbench bench -T 30 -j 4 -c 8 -r

Pour la v10, sur une VM de test, nous obtenons ce résultat (moyenne sur 10 exécutions) :


number of transactions actually processed: 19079

latency average = 12.587 ms

tps = 635.577918 (including connections establishing)

- statement latencies in milliseconds:
0.003  \set aid random(1, 100000 * :scale)
0.000  \set bid random(1, 1 * :scale)
0.001  \set tid random(1, 10 * :scale)
0.000  \set delta random(-5000, 5000)
0.360  BEGIN;
0.413  UPDATE pgbench_accounts SET abalance = abalance + :delta WHERE aid = :aid;
0.462  SELECT abalance FROM pgbench_accounts WHERE aid = :aid;
4.361  UPDATE pgbench_tellers SET tbalance = tbalance + :delta WHERE tid = :tid;
6.335  UPDATE pgbench_branches SET bbalance = bbalance + :delta WHERE bid = :bid;
0.277  INSERT INTO pgbench_history (tid, bid, aid, delta, mtime) VALUES (:tid, :bid, :aid, :delta, CURRENT_TIMESTAMP);
1.157  END;

Et pour la v9.6 :


number of transactions actually processed: 22728

latency average = 10.565 ms

tps = 757.229589 (including connections establishing)

tps = 757.498710 (excluding connections establishing)

- statement latencies in milliseconds:
0.002  \set aid random(1, 100000 * :scale)
0.000  \set bid random(1, 1 * :scale)
0.000  \set tid random(1, 10 * :scale)
0.000  \set delta random(-5000, 5000)
0.230  BEGIN;
0.280  UPDATE pgbench_accounts SET abalance = abalance + :delta WHERE aid = :aid;
0.325  SELECT abalance FROM pgbench_accounts WHERE aid = :aid;
3.492  UPDATE pgbench_tellers SET tbalance = tbalance + :delta WHERE tid = :tid;
4.733  UPDATE pgbench_branches SET bbalance = bbalance + :delta WHERE bid = :bid;
0.168  INSERT INTO pgbench_history (tid, bid, aid, delta, mtime) VALUES (:tid, :bid, :aid, :delta, CURRENT_TIMESTAMP);
0.963  END;

Etrange : malgré les annonces et les mesures officielles, l’avantage de performance va à la 9.6. Pourquoi donc ?

 

Pourquoi est-ce plus lent ?

C’est toute la question, sachant que l’équipe de développement du projet PostgreSQL n’a pas l’habitude d’avancer des chiffres faux. C’est le privilège des gens qui ne cherchent pas à vendre à tout pris leur dernière version.  Suivez mon regard.

L’explication est logique et vient du status de béta de la v10.

En comparant ligne à ligne les options de compilation des binaires v10 et v9.6, on remarque une grosse différence sur la v10 :

pg_config --configure | tr '\ ' '\n'

(…)

‘–enable-debug’

‘–enable-cassert’

(…)

Forcément, avec les options déboggage et de suivi des assertions ( c’est à dire de tous les tests booléens du programme), la V10 fait la course avec des chaussures en béton. Vu les circonstance, elle s’en tire plutôt bien.

Pour en avoir le cœur net, nous avons refait le benchmark avec une version compilée depuis les sources (vous trouverez la procédure de compilation sur ce site. C’est pour la version alpha4 mais le principe est identique) et les résultats sont nettement meilleurs, confirmant les gains de performance annoncés.

 

Conclusion

La prochaine version majeure de PostgreSQL arrive rapidement à maturation et laisse augurer un très bon cru.

Dans les prochains articles, nous verrons les améliorations du partitionnement (qui déplace les mécanismes de triggers pour les intégrer au noyau, apportant un gain de performance et une facilité accrue pour la mise en place) ainsi que la réplication logique, qui sera sûrement le gros morceau de cette version.

Au passage et en bonus, cet article a permis de revoir quelques commandes utiles pour l’installation et l’utilisation. C’est tout nous : généreux et serviables. Mais vous valez bien ça.

Des problèmes ? des questions ? Exprimez-vous ! Les commentaires sont ouverts. Coquilles et fautes de grammaires sont notre lot quotidien : signalez-les nous à m.capello@dbsqware.com