Sulla performance pglogica

Pochi giorni fa abbiamo rilasciato pglogical, una soluzione di replica logica completamente open source per PostgreSQL, che si spera venga inclusa nell'albero di PostgreSQL in un futuro non troppo lontano. Non discuterò di tutte le cose abilitate dalla replica logica:l'annuncio del rilascio di pglogical offre una panoramica abbastanza buona e Simon ha anche spiegato brevemente i vantaggi della replicazione logica in un altro post qualche giorno fa.

Vorrei invece parlare di un aspetto particolare menzionato nell'annuncio:il confronto delle prestazioni con le soluzioni esistenti. La pagina pglogical cita

Parametro

Questo post spiega i dettagli per i benchmark che abbiamo eseguito per trovare il massimo throughput "sostenibile" (transazioni al secondo) che ciascuna delle soluzioni può gestire senza ritardi. Per fare ciò, ho eseguito una serie di test pgbench su una coppia di istanze AWS i2.4xlarge con un numero variabile di client e ho misurato il throughput sul master e quanto tempo ci è voluto in standby per recuperare (se era in ritardo) . I risultati sono stati quindi utilizzati per calcolare una stima del throughput massimo sul nodo standby.

Ad esempio, supponiamo di aver eseguito pgbench con 16 client per 30 minuti e di aver misurato 10000 tps sul master, ma lo standby era in ritardo e ci sono voluti altri 15 minuti per recuperare. Quindi la stima del throughput massimo sostenibile è

tps =(transazioni eseguite) / (tempo di esecuzione totale fino al raggiungimento dello standby)

cioè

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

Quindi in tal caso il throughput massimo sostenibile in standby è di 6.666 tps, ovvero solo il 66% circa del tasso di transazione misurato sul master.

Sistema

Il benchmark è stato eseguito su una coppia di istanze AWS i2.4xlarge, configurate nello stesso gruppo di posizionamento (quindi con una connessione di rete di ~2 Gbit tra di loro) e 4 unità SSD configurate in RAID-0 (quindi è improbabile che l'I/O sia un problema qui). Le istanze hanno circa 122 GB di RAM, quindi il set di dati (pgbench con scala 5000) si adatta alla RAM. Tutti i test sono stati eseguiti su PostgreSQL 9.5.0 con esattamente la stessa configurazione:

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

Per tutti i sistemi di replica è stata utilizzata la versione più recente disponibile, in particolare

• slony1 2.2.4
• skytools 3.2

ed è stata impostata una semplice replica come descritto nei tutorial (entrambi utilizzano l'esempio di pgbench utilizzato per il benchmark).

Risultati

I risultati presentati di seguito includono anche la replica in streaming (modalità asincrona) per fornire un'idea migliore dell'overhead associato alla replica logica. I tassi di transazione non sono i numeri "grezzi" misurati da pgbench, ma i tassi "sostenibili" calcolati utilizzando la formula presentata all'inizio di questo post.