Относно pglogical производителност

Преди няколко дни пуснахме pglogical, решение за логическа репликация с напълно отворен код за PostgreSQL, което се надяваме да бъде включено в дървото на PostgreSQL в недалечно бъдеще. Няма да обсъждам всички неща, разрешени от логическата репликация – съобщението за pglogical версията представя доста добър преглед, а Саймън също накратко обясни предимствата на логическата репликация в друга публикация преди няколко дни.

Вместо това бих искал да говоря за един конкретен аспект, споменат в съобщението – сравнение на производителността със съществуващите решения. Страницата pglogical споменава

Сравнение

Тази публикация обяснява подробностите за сравнителните показатели, които извършихме, за да намерим максималната „устойчива“ пропускателна способност (транзакции в секунда), която всяко от решенията може да поеме без изоставане. За да направя това, проведох редица тестове на pgbench на чифт i2.4xlarge AWS инстанции с различен брой клиенти и измервах пропускателната способност на главния и колко време е отнело готовността, за да навакса (ако е изоставал) . След това резултатите бяха използвани за изчисляване на оценка на максималната пропускателна способност на възела в режим на готовност.

Например, да кажем, че работихме с pgbench с 16 клиента в продължение на 30 минути и сме измерили 10 000 tps на главния, но режимът на готовност изоставаше и отне още 15 минути, за да го навакса. Тогава оценката за максимална устойчива производителност е

tps =(изпълнени транзакции) / (общо време на изпълнение до достигане на режим на готовност)

т.е.

tps =(30 60 10 000) / (45 * 60) =18 000 000 / 2 700 =6 666

Така че в този случай максималната устойчива пропускателна способност в режим на готовност е 6,666 tps, т.е. само ~66% от скоростта на транзакциите, измерена на главния.

Система

Бенчмаркът беше извършен на чифт i2.4xlarge AWS инстанции, конфигурирани в една и съща група за разположение (така че с ~2Gbit мрежова връзка между тях) и 4x SSD дискове, конфигурирани в RAID-0 (така че I/O е малко вероятно да бъде проблем тук). Екземплярите имат ~122 GB RAM, така че наборът от данни (pgbench с мащаб 5000) се вписва в RAM. Всички тестове бяха извършени на PostgreSQL 9.5.0 с абсолютно същата конфигурация:

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

За всички системи за репликация беше използвана най-новата налична версия, особено

• slony1 2.2.4
• skytools 3.2

и беше настроена проста репликация, както е описано в уроците (и двете използват примера на pgbench, използван за еталон).

Резултати

Представените по-долу резултати включват също поточно репликация (асинхронен режим), за да ви дадат по-добра представа за режийните разходи, свързани с логическата репликация. Цените на транзакциите не са „суровите“ числа, измерени от pgbench, а „устойчивите“ проценти, изчислени по формулата, представена в началото на тази публикация.