Bonjour, Habr! Je vous présente la traduction de l'article original
«Benchmark PostgreSQL sur FreeBSD, CentOS, Ubuntu Debian et openSUSE» de Martin Kováčik. Il examine les tests du SGBD PostgreSQL 10.1 dans des environnements proches des conditions réelles sur divers systèmes Unix.
La traduction
Dans cet article, je vais montrer les résultats des tests de PostgreSQL 10.1 récemment publié. J'ai vérifié la base de données sur ces systèmes d'exploitation (tous 64 bits):
- Ubuntu 16.04 , noyau 4.10.0-38-générique
- openSUSE 42.3, noyau 4.4.87-25 par défaut
- CentOS 7.4 , noyau 3.10.0-693.2.2.el7.x86_64
- Debian 9.2 , noyau 4.9.0-4-amd64
- FreeBSD 11.1
Méthodologie de test
L'objectif du test était de mesurer les performances de PostgreSQL dans des conditions similaires aux déploiements de production (typiques):
- les clients se connectent via le pool de connexions pour s'assurer qu'il n'y a pas de reconnexion permanente à la base de données (je n'ai pas utilisé le pool de connexions, je n'ai pas utilisé l'indicateur -C pgbench à la place)
- les clients se connectent sur un réseau, pas sur une socket unix
- Répertoire de données PostgreSQL situé sur le miroir RAID 1
Pour chacun des OS testés, une base de données de contrôle de ~ 74 Go a été créée:
pgbench -i -s 5000 pgbench
L'infrastructure de test était constituée de deux serveurs dédiés connectés à un réseau à 1 Gbit / s:
- EX41-SSD: Intel i7-6700, 4 cœurs, 8 threads, 32 Go de RAM DDR4, utilisé pour générer des requêtes SQL à l'aide de pgbench
- PX121-SSD: Intel Xeon E5-1650 v3, 6 cœurs, 12 threads, 256 Go de RAM DDR4 ECC, 2 x 480 Go SATA 6 Gb / s, centre de données de la série SSD, utilisé comme serveur PostgreSQL
Je me suis intéressé à ces combinaisons de tests:
- 32 Go en lecture seule : test en lecture seule (uniquement des échantillons sans modification des données), l'ensemble de données ne tient pas dans le cache PostgreSQL
- 200 Go en lecture seule : test en lecture seule, l'ensemble de données est mis en cache dans PostgreSQL
- 32 Go TCP-B : lecture-écriture, l'ensemble de données ne tient pas dans le cache PostgreSQL
- TCP-B 200 Go : lecture, écriture, l'ensemble de données est mis en cache dans PostgreSQL
configuration de pgbench
Le programme pgbench version 10.1, fonctionnant sur un ordinateur FreeBSD 11.1 distinct, a été utilisé pour générer la charge. Le script de test se composait de trois parties: vide + chauffage, un test en lecture seule et un test de lecture et d'écriture. Avant chaque test de lecture-écriture, les tables pgbench étaient effacées (l'indicateur -v était utilisé). Pendant le test, j'ai progressivement augmenté le nombre de clients accédant à la base de données.
Paramètres du serveur PostgreSQL
Pour les distributions Linux, PostgreSQL a été installé sur le système de fichiers ext4 dans la configuration RAID1 (RAID logiciel utilisant mdraid) sur deux SSD avec
atime désactivé. Dans le cas de FreeBSD, le système de fichiers OpenZFS a été utilisé sur deux SSD lors de la configuration de RAID1. Un ensemble de données ZFS avec des données PostgreSQL a été créé avec les paramètres suivants:
zfs get recordsize,logbias,primarycache,atime,compression zroot/var/db/postgres NAME PROPERTY VALUE SOURCE zroot/var/db/postgres recordsize 8K local zroot/var/db/postgres logbias throughput local zroot/var/db/postgres primarycache all default zroot/var/db/postgres atime off inherited from zroot zroot/var/db/postgres compression lz4 local
La configuration du serveur PostgreSQL était la même sur tous les systèmes d'exploitation à l'exception des chemins de fichiers (chaque système d'exploitation utilise sa propre structure de répertoires). Le contenu du fichier
postgresql.conf (paramètres de base) pour une instance de 32 Go:
autovacuum = off default_statistics_target = 100 maintenance_work_mem = 1GB checkpoint_completion_target = 0.9 effective_cache_size = 24GB work_mem = 104MB wal_buffers = 16MB shared_buffers = 8GB max_connections = 300
Le contenu du fichier
postgresql.conf pour l'instance de 200 Go:
autovacuum = off default_statistics_target = 100 maintenance_work_mem = 2GB checkpoint_completion_target = 0.9 effective_cache_size = 144GB work_mem = 640MB wal_buffers = 16MB shared_buffers = 48GB max_connections = 300
Analyse comparative
J'ai testé PostgreSQL sur cinq systèmes d'exploitation différents dans deux modes - lecture seule et TCP-B (lecture-écriture) avec deux profils de mémoire différents. Le test de chaque système d'exploitation a pris environ 30 heures (sans compter le temps requis pour configurer le système d'exploitation). Les résultats de chaque analyse pgbench ont été enregistrés pour une évaluation ultérieure.
Résultats - Lecture seule
Résultats - TCP-B
Résumé
Le test a montré que la différence entre les différentes distributions GNU / Linux n'est pas très significative. OpenSUSE 42.3 était le meilleur système d'exploitation du test en lecture seule, tandis que FreeBSD fonctionnait environ 40% plus lentement. Malheureusement, je n'ai pas compris ce qui a causé une performance médiocre de FreeBSD.
Une image plus réaliste des performances de PostgreSQL a été obtenue dans le test de lecture-écriture (TCP-B). Parmi les distributions GNU / Linux, Centos 7.4 était la plus rapide et Debian 9.2 la plus lente. J'ai été agréablement surpris par FreeBSD 11.1, qui fonctionnait plus de deux fois plus vite que le meilleur Linux, malgré le fait que FreeBSD utilisait ZFS, qui est un système de fichiers de copie sur écriture. J'ai supposé que cette différence était causée par le coût du RAID logiciel sous Linux, j'ai donc fait trois tests TCP-B supplémentaires pour 100 clients simultanés, cette fois sans RAID logiciel:
- FreeBSD 11.1 + UFS : 5623.86 TPS
- FreeBSD 11.1 + ZFS : 8331.85 TPS
- CentOS 7.4 + ext4 : 8987.65 TPS
Les résultats montrent l'inefficacité de Linux SW RAID (ou l'efficacité de ZFS RAID). Les performances de CentOS 7.4 sans SW RAID ne sont que légèrement supérieures à celles de FreeBSD 11.1 avec ZFS RAID (pour TCP-B et 100 clients simultanés).