Hallo Habr! Ich präsentiere Ihnen die Übersetzung des Originalartikels
„PostgreSQL-Benchmark für FreeBSD, CentOS, Ubuntu Debian und openSUSE“ von Martin Kováčik. Es untersucht die PostgreSQL 10.1-DBMS-Tests in Umgebungen, die den realen Bedingungen auf verschiedenen Unix-Systemen nahe kommen.
Übersetzung
In diesem Beitrag werde ich die Testergebnisse des kürzlich veröffentlichten PostgreSQL 10.1 zeigen. Ich habe die Datenbank auf diesen Betriebssystemen (alle 64-Bit) überprüft:
- Ubuntu 16.04 , Kernel 4.10.0-38-generic
- openSUSE 42.3 , Kernel 4.4.87-25-Standard
- CentOS 7.4 , Kernel 3.10.0-693.2.2.el7.x86_64
- Debian 9.2 , Kernel 4.9.0-4-amd64
- FreeBSD 11.1
Testmethodik
Ziel des Tests war es, die Leistung von PostgreSQL unter ähnlichen Bedingungen wie bei (typischen) Produktionsbereitstellungen zu messen:
- Clients stellen eine Verbindung über den Verbindungspool her, um sicherzustellen, dass keine dauerhafte erneute Verbindung zur Datenbank besteht (ich habe den Verbindungspool nicht verwendet, stattdessen nicht das Flag -C pgbench).
- Clients stellen eine Verbindung über ein Netzwerk her, nicht über einen Unix-Socket
- PostgreSQL-Datenverzeichnis auf dem RAID 1-Spiegel
Für jedes der getesteten Betriebssysteme wurde eine Steuerdatenbank mit ~ 74 GB erstellt:
pgbench -i -s 5000 pgbench
Die Testinfrastruktur bestand aus zwei dedizierten Servern, die mit einem 1-Gbit / s-Netzwerk verbunden waren:
- EX41-SSD: Intel i7-6700, 4 Kerne, 8 Threads, 32 GB DDR4-RAM, zum Generieren von SQL-Abfragen mit pgbench
- PX121-SSD: Intel Xeon E5-1650 v3, 6 Kerne, 12 Threads, 256 GB RAM DDR4 ECC, 2 x 480 GB SATA 6 Gbit / s, Rechenzentrum der SSD-Serie, verwendet als PostgreSQL-Server
Diese Testkombinationen haben mich interessiert:
- 32 GB schreibgeschützt : Nur-Lese-Test (nur Beispiele ohne Datenänderung), der Datensatz passt nicht in den PostgreSQL-Cache
- 200 GB schreibgeschützt : Nur-Lese-Test, der Datensatz wird in PostgreSQL zwischengespeichert
- 32 GB TCP-B : Lese- / Schreibzugriff, Datensatz passt nicht in den PostgreSQL-Cache
- TCP-B 200 GB : Lesen, Schreiben, Datensatz wird in PostgreSQL zwischengespeichert
pgbench setup
Das Programm pgbench Version 10.1, das auf einem separaten FreeBSD 11.1-Computer ausgeführt wird, wurde zum Generieren der Last verwendet. Das Testskript bestand aus drei Teilen: Vakuum + Erhitzen, einem Nur-Lese-Test und einem Lese- und Schreibtest. Vor jedem Lese- / Schreibtest wurden die pgbench-Tabellen gelöscht (das Flag -v wurde verwendet). Während des Tests habe ich die Anzahl der Clients, die auf die Datenbank zugreifen, schrittweise erhöht.
PostgreSQL Server-Einstellungen
Für Linux-Distributionen wurde PostgreSQL im RAID1-Setup (Software-RAID mit mdraid) auf zwei SSDs mit deaktiviertem
atime auf dem ext4-Dateisystem installiert. Bei FreeBSD wurde bei der Konfiguration von RAID1 das OpenZFS-Dateisystem auf zwei SSDs verwendet. Ein ZFS-Dataset mit PostgreSQL-Daten wurde mit den folgenden Parametern erstellt:
zfs get recordsize,logbias,primarycache,atime,compression zroot/var/db/postgres NAME PROPERTY VALUE SOURCE zroot/var/db/postgres recordsize 8K local zroot/var/db/postgres logbias throughput local zroot/var/db/postgres primarycache all default zroot/var/db/postgres atime off inherited from zroot zroot/var/db/postgres compression lz4 local
Die Konfiguration des PostgreSQL-Servers war auf allen Betriebssystemen mit Ausnahme der Dateipfade gleich (jedes Betriebssystem verwendet seine eigene Verzeichnisstruktur). Der Inhalt der Datei
postgresql.conf (Grundeinstellungen) für eine 32-GB-Instanz:
autovacuum = off default_statistics_target = 100 maintenance_work_mem = 1GB checkpoint_completion_target = 0.9 effective_cache_size = 24GB work_mem = 104MB wal_buffers = 16MB shared_buffers = 8GB max_connections = 300
Der Inhalt der Datei
postgresql.conf für die 200-GB-Instanz:
autovacuum = off default_statistics_target = 100 maintenance_work_mem = 2GB checkpoint_completion_target = 0.9 effective_cache_size = 144GB work_mem = 640MB wal_buffers = 16MB shared_buffers = 48GB max_connections = 300
Benchmarking
Ich habe PostgreSQL auf fünf verschiedenen Betriebssystemen in zwei Modi getestet - schreibgeschützt und TCP-B (Lese- / Schreibzugriff) mit zwei verschiedenen Speicherprofilen. Der Test jedes Betriebssystems dauerte ungefähr 30 Stunden (ohne die zum Konfigurieren des Betriebssystems erforderliche Zeit). Die Ergebnisse jedes pgbench-Laufs wurden zur späteren Auswertung gespeichert.
Ergebnisse - schreibgeschützt
Ergebnisse - TCP-B
Zusammenfassung
Der Test zeigte, dass der Unterschied zwischen den verschiedenen GNU / Linux-Distributionen nicht sehr signifikant ist. OpenSUSE 42.3 war das beste Betriebssystem im schreibgeschützten Test, während FreeBSD etwa 40% langsamer lief. Leider habe ich nicht herausgefunden, was solch eine mittelmäßige FreeBSD-Leistung verursacht hat.
Ein realistischeres Bild der Leistung von PostgreSQL wurde im Lese- / Schreibtest (TCP-B) erhalten. Unter den GNU / Linux-Distributionen war Centos 7.4 die schnellste und Debian 9.2 die langsamste. Ich war angenehm überrascht von FreeBSD 11.1, das mehr als doppelt so schnell lief wie das beste Linux, obwohl FreeBSD ZFS verwendete, ein Copy-on-Write-Dateisystem. Ich nahm an, dass dieser Unterschied durch die Kosten für Software-RAID unter Linux verursacht wurde, und führte drei weitere TCP-B-Tests für 100 gleichzeitige Clients durch, diesmal ohne Software-RAID:
- FreeBSD 11.1 + UFS : 5623,86 TPS
- FreeBSD 11.1 + ZFS : 8331,85 TPS
- CentOS 7.4 + ext4 : 8987,65 TPS
Die Ergebnisse zeigen die Ineffizienz von Linux SW RAID (oder die Effizienz von ZFS RAID). Die Leistung von CentOS 7.4 ohne SW-RAID ist nur geringfügig höher als die von FreeBSD 11.1 mit ZFS-RAID (für TCP-B und 100 gleichzeitige Clients).