Om pglogisk prestanda

För några dagar sedan släppte vi pglogical, en logisk replikeringslösning med helt öppen källkod för PostgreSQL, som förhoppningsvis kommer att inkluderas i PostgreSQL-trädet inom en inte alltför avlägsen framtid. Jag tänker inte diskutera alla de saker som möjliggörs av logisk replikering – det pglogical releasemeddelandet ger en ganska bra översikt, och Simon förklarade också kort fördelarna med logisk replikering i ett annat inlägg för några dagar sedan.

Istället skulle jag vilja prata om en speciell aspekt som nämns i tillkännagivandet – prestandajämförelse med befintliga lösningar. Den pglogiska sidan nämner

Benchmark

Det här inlägget förklarar detaljerna för de riktmärken vi utförde för att hitta den maximala "hållbara" genomströmningen (transaktioner per sekund) som var och en av lösningarna kan hantera utan att släpa. För att göra det har jag kört ett antal pgbench-tester på ett par i2.4xlarge AWS-instanser med varierande antal klienter, och mätt genomströmningen på mastern och hur lång tid det tog standby-läget att komma ikapp (om det låg efter) . Resultaten användes sedan för att beräkna en uppskattning av den maximala genomströmningen på standbynoden.

Låt oss till exempel säga att vi har kört pgbench med 16 klienter i 30 minuter, och vi har mätt 10 000 tps på mastern, men standbyläget släpade och tog ytterligare 15 minuter att komma ikapp. Då är den maximala hållbara genomströmningsuppskattningen

tps =(transaktioner utförda) / (total körtid tills standby-läge kom ikapp)

dvs.

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

Så i det fallet är den maximala hållbara genomströmningen i standby-läge 6,666 tps, dvs. endast ~66 % av transaktionshastigheten uppmätt på mastern.

System

Riktmärket utfördes på ett par i2.4xlarge AWS-instanser, konfigurerade i samma placeringsgrupp (så med ~2Gbit nätverksanslutning mellan dem), och 4x SSD-enheter konfigurerade i RAID-0 (så I/O är osannolikt att vara en problem här). Förekomsterna har ~122 GB RAM, så datamängden (pgbench med skala 5000) passar in i RAM. Alla tester utfördes på PostgreSQL 9.5.0 med exakt samma konfiguration:

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

För alla replikeringssystem användes den senaste tillgängliga versionen, särskilt

• slony1 2.2.4
• skytools 3.2

och en enkel replikering sattes upp enligt beskrivningen i handledningarna (båda använder pgbench-exemplet som används för benchmark).

Resultat

Resultaten som presenteras härnäst inkluderar även strömmande replikering (asynkront läge) för att ge dig en bättre uppfattning om de overhead som är förknippade med logisk replikering. Transaktionskurserna är inte de "råa" siffrorna som mäts av pgbench, utan de "hållbara" priserna beräknade med formeln som presenteras i början av det här inlägget.