O pglogickém výkonu

Před několika dny jsme vydali pglogical, plně open-source řešení logické replikace pro PostgreSQL, které snad bude zahrnuto do stromu PostgreSQL v nepříliš vzdálené budoucnosti. Nebudu diskutovat o všech věcech, které umožňuje logická replikace – oznámení o vydání pglogical představuje docela dobrý přehled a Simon také stručně vysvětlil výhody logické replikace v jiném příspěvku před několika dny.

Místo toho bych chtěl mluvit o jednom konkrétním aspektu zmíněném v oznámení – srovnání výkonu se stávajícími řešeními. Pgologická stránka zmiňuje

Srovnávací

Tento příspěvek vysvětluje podrobnosti o benchmarkech, které jsme provedli, abychom našli maximální „udržitelnou“ propustnost (transakce za sekundu), kterou každé z řešení zvládne bez zpoždění. Abych to udělal, provedl jsem řadu testů pgbench na páru instancí i2.4xlarge AWS s různým počtem klientů a změřil jsem propustnost na hlavním serveru a jak dlouho trvalo, než pohotovostní režim dohnal (pokud se zpožďoval) . Výsledky byly poté použity k výpočtu odhadu maximální propustnosti v pohotovostním uzlu.

Řekněme například, že jsme spustili pgbench se 16 klienty po dobu 30 minut a na masteru jsme naměřili 10 000 tps, ale pohotovostní režim se zpožďoval a trvalo dalších 15 minut, než to dohnal. Pak je odhad maximální udržitelné propustnosti

tps =(transakce provedené) / (celková doba běhu do doby, než dojde k pohotovostnímu režimu)

tj.

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

Takže v takovém případě je maximální udržitelná propustnost v pohotovostním režimu 6,666 tps, tj. pouze ~66 % transakční rychlosti naměřené na masteru.

Systém

Srovnávací test byl proveden na dvojici instancí i2.4xlarge AWS, konfigurovaných ve stejné skupině umístění (tedy s ~2Gbitovým síťovým připojením mezi nimi) a 4x SSD discích nakonfigurovaných v RAID-0 (takže I/O pravděpodobně nebude problém zde). Instance mají ~122GB RAM, takže datová sada (pgbench s měřítkem 5000) se vejde do RAM. Všechny testy byly provedeny na PostgreSQL 9.5.0 s naprosto stejnou konfigurací:

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

Pro všechny replikační systémy byla použita nejnovější dostupná verze, zejména

• slony1 2.2.4
• skytools 3.2

a byla nastavena jednoduchá replikace, jak je popsáno v tutoriálech (oba používají příklad pgbench použitý pro benchmark).

Výsledky

Výsledky uvedené dále zahrnují také streamingovou replikaci (asynchronní režim), abyste získali lepší představu o režii spojené s logickou replikací. Transakční sazby nejsou „surová“ čísla měřená pgbench, ale „udržitelné“ sazby vypočítané pomocí vzorce uvedeného na začátku tohoto příspěvku.