Sur les performances de pglogical

Il y a quelques jours, nous avons publié pglogical, une solution de réplication logique entièrement open source pour PostgreSQL, qui, espérons-le, sera incluse dans l'arborescence PostgreSQL dans un avenir pas trop lointain. Je ne vais pas discuter de toutes les choses permises par la réplication logique - l'annonce de la version de pglogical présente un assez bon aperçu, et Simon a également brièvement expliqué les avantages de la réplication logique dans un autre article il y a quelques jours.

Au lieu de cela, j'aimerais parler d'un aspect particulier mentionné dans l'annonce - la comparaison des performances avec les solutions existantes. La page pglogical mentionne

Référence

Cet article explique les détails des benchmarks que nous avons effectués pour trouver le débit « durable » maximal (transactions par seconde) que chacune des solutions peut gérer sans retard. Pour ce faire, j'ai exécuté un certain nombre de tests pgbench sur une paire d'instances AWS i2.4xlarge avec un nombre variable de clients, et mesuré le débit sur le maître et le temps qu'il a fallu à la veille pour rattraper son retard (s'il était en retard) . Les résultats ont ensuite été utilisés pour calculer une estimation du débit maximal sur le nœud de secours.

Par exemple, disons que nous avons exécuté pgbench avec 16 clients pendant 30 minutes, et que nous avons mesuré 10 000 tps sur le maître, mais que la veille était à la traîne et a mis encore 15 minutes à rattraper. Ensuite, l'estimation du débit maximal durable est

tps =(transactions exécutées) / (durée totale d'exécution jusqu'au rattrapage de la veille)

c'est-à-dire

tps =(30 60 10.000) / (45 * 60) =18.000.000 / 2.700 =6.666

Ainsi, dans ce cas, le débit maximal durable en veille est de 6,666 tps, soit seulement ~ 66 % du taux de transaction mesuré sur le maître.

Système

Le benchmark a été effectué sur une paire d'instances AWS i2.4xlarge, configurées dans le même groupe de placement (donc avec une connexion réseau d'environ 2 Gbit entre elles) et 4 disques SSD configurés en RAID-0 (il est donc peu probable que les E/S soient un problème ici). Les instances ont ~122 Go de RAM, donc l'ensemble de données (pgbench avec échelle 5000) tient dans la RAM. Tous les tests ont été effectués sur PostgreSQL 9.5.0 avec exactement la même configuration :

checkpoint_timeout = 15min
effective_io_concurrency = 32
maintenance_work_mem = 1GB
max_wal_size = 8GB
min_wal_size = 2GB
shared_buffers = 16GB

Pour tous les systèmes de réplication, la version disponible la plus récente a été utilisée, en particulier

• slony1 2.2.4
• skytools 3.2

et une réplication simple a été mise en place comme décrit dans les tutoriels (les deux utilisent l'exemple pgbench utilisé pour le benchmark).

Résultats

Les résultats présentés ensuite incluent également la réplication en continu (mode asynchrone) pour vous donner une meilleure idée de la surcharge associée à la réplication logique. Les taux de transaction ne sont pas les chiffres "bruts" tels que mesurés par pgbench, mais les taux "durables" calculés à l'aide de la formule présentée au début de cet article.