Op pglogische prestaties

Een paar dagen geleden hebben we pglogical uitgebracht, een volledig open-source logische replicatie-oplossing voor PostgreSQL, die hopelijk in een niet al te verre toekomst zal worden opgenomen in de PostgreSQL-structuur. Ik ga het niet hebben over alle dingen die mogelijk worden gemaakt door logische replicatie - de aankondiging van de pglogical-release geeft een redelijk goed overzicht, en Simon legde ook kort de voordelen van logische replicatie uit in een ander bericht een paar dagen geleden.

In plaats daarvan wil ik het hebben over een bepaald aspect dat in de aankondiging wordt genoemd:prestatievergelijking met bestaande oplossingen. De pglogische pagina vermeldt

Benchmark

In dit bericht worden de details uitgelegd voor de benchmarks die we hebben uitgevoerd om de maximale "duurzame" doorvoer (transacties per seconde) te vinden die elk van de oplossingen aankan zonder vertraging op te lopen. Om dat te doen heb ik een aantal pgbench-tests uitgevoerd op een paar i2.4xlarge AWS-instanties met een variërend aantal clients, en de doorvoer op de master gemeten en hoe lang het duurde voordat de stand-by was ingehaald (als deze achterbleef) . De resultaten werden vervolgens gebruikt om een ​​schatting te maken van de maximale doorvoer op het standby-knooppunt.

Laten we bijvoorbeeld zeggen dat we pgbench 30 minuten met 16 clients hebben uitgevoerd en dat we 10000 tps op de master hebben gemeten, maar de stand-by bleef achter en duurde nog eens 15 minuten om in te halen. Dan is de maximale schatting van de duurzame doorvoer

tps =(transacties uitgevoerd) / (totale looptijd tot stand-by ingehaald)

d.w.z.

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

Dus in dat geval is de maximale duurzame doorvoer op de standby 6,666 tps, d.w.z. slechts ~66% van de transactiesnelheid gemeten op de master.

Systeem

De benchmark is uitgevoerd op een paar i2.4xlarge AWS-instanties, geconfigureerd in dezelfde plaatsingsgroep (dus met ~2Gbit netwerkverbinding ertussen), en 4x SSD-schijven geconfigureerd in RAID-0 (dus I/O is waarschijnlijk geen probleem hier). De instances hebben ~122GB RAM, dus de dataset (pgbench met schaal 5000) past in RAM. Alle tests zijn uitgevoerd op PostgreSQL 9.5.0 met exact dezelfde configuratie:

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

Voor alle replicatiesystemen werd de meest recent beschikbare versie gebruikt, met name

• slony1 2.2.4
• skytools 3.2

en er is een eenvoudige replicatie opgezet zoals beschreven in de tutorials (beide gebruiken het pgbench-voorbeeld dat voor de benchmark wordt gebruikt).

Resultaten

De resultaten die hierna worden gepresenteerd, omvatten ook streamingreplicatie (asynchrone modus) om u een beter idee te geven van de overhead die gepaard gaat met logische replicatie. De transactietarieven zijn niet de "ruwe" cijfers zoals gemeten door pgbench, maar de "duurzame" tarieven berekend met behulp van de formule aan het begin van dit bericht.