Zur pglogischen Leistung

Vor ein paar Tagen haben wir pglogical veröffentlicht, eine vollständig quelloffene logische Replikationslösung für PostgreSQL, die hoffentlich in nicht allzu ferner Zukunft in den PostgreSQL-Baum aufgenommen wird. Ich werde nicht auf all die Dinge eingehen, die durch die logische Replikation ermöglicht werden – die pglogical Release-Ankündigung bietet einen recht guten Überblick, und Simon hat vor einigen Tagen in einem anderen Beitrag auch kurz die Vorteile der logischen Replikation erläutert.

Stattdessen möchte ich auf einen bestimmten Aspekt eingehen, der in der Ankündigung erwähnt wird – den Leistungsvergleich mit bestehenden Lösungen. Die pglogische Seite erwähnt

Benchmark

Dieser Beitrag erläutert die Details für die Benchmarks, die wir durchgeführt haben, um den maximalen „nachhaltigen“ Durchsatz (Transaktionen pro Sekunde) zu finden, den jede der Lösungen ohne Verzögerung bewältigen kann. Dazu habe ich eine Reihe von pgbench-Tests auf zwei i2.4xlarge-AWS-Instanzen mit unterschiedlicher Anzahl von Clients durchgeführt und den Durchsatz auf dem Master gemessen und wie lange es gedauert hat, bis der Standby aufgeholt hat (falls er verzögert war). . Die Ergebnisse wurden dann verwendet, um eine Schätzung des maximalen Durchsatzes auf dem Standby-Knoten zu berechnen.

Nehmen wir zum Beispiel an, wir haben pgbench 30 Minuten lang mit 16 Clients ausgeführt und wir haben 10000 tps auf dem Master gemessen, aber der Standby war verzögert und brauchte weitere 15 Minuten, um aufzuholen. Dann ist die maximal tragfähige Durchsatzschätzung

tps =(ausgeführte Transaktionen) / (Gesamtlaufzeit bis Standby aufgeholt)

d.h.

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

In diesem Fall beträgt der maximale nachhaltige Durchsatz auf dem Standby also 6.666 tps, d. h. nur ~66 % der auf dem Master gemessenen Transaktionsrate.

System

Der Benchmark wurde auf einem Paar i2.4xlarge-AWS-Instanzen durchgeführt, die in derselben Platzierungsgruppe konfiguriert waren (also mit einer Netzwerkverbindung von ~2 Gbit zwischen ihnen), und 4x SSD-Laufwerken, die in RAID-0 konfiguriert waren (daher ist es unwahrscheinlich, dass E/A a Problem hier). Die Instanzen haben ~122 GB RAM, sodass der Datensatz (pgbench mit Maßstab 5000) in den RAM passt. Alle Tests wurden auf PostgreSQL 9.5.0 mit genau derselben Konfiguration durchgeführt:

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

Für alle Replikationssysteme wurde die neueste verfügbare Version verwendet, insbesondere

• slony1 2.2.4
• skytools 3.2

und eine einfache Replikation wurde wie in den Tutorials beschrieben eingerichtet (beide verwenden das für den Benchmark verwendete pgbench-Beispiel).

Ergebnisse

Die als Nächstes präsentierten Ergebnisse beinhalten auch die Streaming-Replikation (asynchroner Modus), um Ihnen eine bessere Vorstellung vom Overhead zu geben, der mit der logischen Replikation verbunden ist. Die Transaktionsraten sind nicht die von pgbench gemessenen „rohen“ Zahlen, sondern die „nachhaltigen“ Raten, die mit der am Anfang dieses Beitrags vorgestellten Formel berechnet werden.