O wydajności pglogicznej

Kilka dni temu wypuściliśmy pglogical, w pełni otwarte rozwiązanie do replikacji logicznej dla PostgreSQL, które, miejmy nadzieję, zostanie włączone do drzewa PostgreSQL w niedalekiej przyszłości. Nie będę omawiał wszystkich rzeczy, które umożliwia replikacja logiczna – ogłoszenie o wydaniu pglogical przedstawia całkiem dobry przegląd, a Simon również pokrótce wyjaśnił zalety replikacji logicznej w innym poście kilka dni temu.

Zamiast tego chciałbym omówić jeden konkretny aspekt wspomniany w ogłoszeniu – porównanie wydajności z istniejącymi rozwiązaniami. Strona pglogiczna wspomina

Wzorzec

W tym poście wyjaśniono szczegóły testów porównawczych, które przeprowadziliśmy, aby znaleźć maksymalną „zrównoważoną” przepustowość (transakcje na sekundę), którą każde z rozwiązań może obsłużyć bez opóźnień. W tym celu przeprowadziłem szereg testów pgbench na parze instancji i2.4xlarge AWS z różną liczbą klientów i mierzyłem przepustowość na masterze oraz czas oczekiwania na nadrobienie zaległości (jeśli był opóźniony) . Wyniki zostały następnie wykorzystane do obliczenia szacunkowej maksymalnej przepustowości w węźle gotowości.

Załóżmy na przykład, że przez 30 minut korzystaliśmy z pgbencha z 16 klientami i zmierzyliśmy 10000 tps na masterze, ale stan gotowości był opóźniony i nadrobienie zajęło nam kolejne 15 minut. Wtedy maksymalna trwała szacunkowa przepustowość wynosi

tps =(wykonane transakcje) / (całkowity czas działania do czasu oczekiwania)

tj.

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

W takim przypadku maksymalna możliwa do utrzymania przepustowość w trybie gotowości wynosi 6,666 t/s, czyli tylko ~66% szybkości transakcji mierzonej na urządzeniu głównym.

System

Test porównawczy został przeprowadzony na parze instancji i2.4xlarge AWS, skonfigurowanych w tej samej grupie rozmieszczenia (a więc z połączeniem sieciowym ~2Gbit między nimi) i 4x dyskami SSD skonfigurowanymi w RAID-0 (więc jest mało prawdopodobne, że I/O będzie problem tutaj). Instancje mają ~122 GB pamięci RAM, więc zestaw danych (pgbench ze skalą 5000) mieści się w pamięci RAM. Wszystkie testy zostały przeprowadzone na PostgreSQL 9.5.0 z dokładnie taką samą konfiguracją:

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

W przypadku wszystkich systemów replikacji została użyta najnowsza dostępna wersja, w szczególności

• slony1 2.2.4
• Skytools 3.2

i skonfigurowano prostą replikację, jak opisano w samouczkach (oba używają przykładu pgbench użytego do testu porównawczego).

Wyniki

Wyniki przedstawione dalej obejmują również replikację strumieniową (tryb asynchroniczny), aby dać lepsze pojęcie o narzutach związanych z replikacją logiczną. Stawki transakcyjne nie są „surowymi” liczbami mierzonymi przez pgbench, ale „zrównoważonymi” stawkami obliczonymi przy użyciu wzoru przedstawionego na początku tego postu.