Om pglogisk ydeevne

For et par dage siden udgav vi pglogical, en logisk replikeringsløsning med fuldt åben kildekode til PostgreSQL, som forhåbentlig vil blive inkluderet i PostgreSQL-træet i en ikke alt for fjern fremtid. Jeg vil ikke diskutere alle de ting, der er muliggjort af logisk replikering - den pglogiske udgivelsesmeddelelse giver et ganske godt overblik, og Simon forklarede også kort fordelene ved logisk replikering i et andet indlæg for et par dage siden.

I stedet vil jeg gerne tale om et bestemt aspekt, der er nævnt i meddelelsen – sammenligning af ydeevne med eksisterende løsninger. Den pglogiske side nævner

Benchmark

Dette indlæg forklarer detaljerne for de benchmarks, vi udførte for at finde den maksimale "bæredygtige" gennemstrømning (transaktioner pr. sekund), som hver af løsningerne kan håndtere uden at halte. For at gøre det har jeg kørt en række pgbench-tests på et par i2.4xlarge AWS-instanser med varierende antal klienter og målt gennemløbet på masteren, og hvor lang tid det tog standby at indhente (hvis det haltede) . Resultaterne blev derefter brugt til at beregne et estimat af den maksimale gennemstrømning på standby-knuden.

Lad os for eksempel sige, at vi har kørt pgbench med 16 klienter i 30 minutter, og vi har målt 10000 tps på masteren, men standbyen haltede og tog yderligere 15 minutter at indhente det. Så er det maksimale bæredygtige gennemløbsestimat

tps =(transaktioner udført) / (samlet køretid indtil standby indhentet)

dvs.

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

Så i det tilfælde er den maksimale bæredygtige gennemstrømning på standby 6.666 tps, dvs. kun ~66 % af transaktionshastigheden målt på masteren.

System

Benchmark blev udført på et par i2.4xlarge AWS-instanser, konfigureret i den samme placeringsgruppe (så med ~2Gbit netværksforbindelse mellem dem), og 4x SSD-drev konfigureret i RAID-0 (så I/O er usandsynligt at være en problem her). Forekomsterne har ~122 GB RAM, så datasættet (pgbench med skala 5000) passer ind i RAM. Alle testene blev udført på PostgreSQL 9.5.0 med nøjagtig den samme konfiguration:

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

For alle replikeringssystemer blev den seneste tilgængelige version brugt, især

• slony1 2.2.4
• skytools 3.2

og en simpel replikering blev sat op som beskrevet i selvstudierne (begge bruger pgbench-eksemplet brugt til benchmark).

Resultater

Resultaterne, der præsenteres herefter, inkluderer også streamingreplikering (asynkron tilstand) for at give dig en bedre idé om de overhead, der er forbundet med logisk replikering. Transaktionssatserne er ikke de "rå" tal målt af pgbench, men de "bæredygtige" satser beregnet ved hjælp af formlen præsenteret i begyndelsen af ​​dette indlæg.