pgbench: PostgreSQL benchmarken und unter Last testen

pgbench ist das Benchmark-Programm, das mit PostgreSQL ausgeliefert wird: Es führt dieselbe SQL-Transaktion in mehreren gleichzeitigen Datenbanksitzungen immer wieder aus und meldet Transaktionen pro Sekunde und Latenz. Die Testtabellen legen Sie mit pgbench -i -s 50 mydb an, danach startet etwa pgbench -c 10 -j 2 -T 300 mydb zehn Clients auf zwei Threads für fünf Minuten. Es misst nur die Datenbank und sagt daher nichts darüber, was Benutzer über die Anwendung davor erleben.

Wir haben pgbench für diesen Leitfaden nicht selbst ausgeführt. Die Fakten stammen aus der pgbench-Seite der Dokumentation zu PostgreSQL 18, der Version, die postgresql.org als aktuell führt, geprüft am 31. Oktober 2026; die Einschätzungen sind unsere eigenen.

Was misst pgbench?

Es führt ein Transaktionsskript in einer festen Zahl von Datenbanksitzungen immer wieder aus und meldet die durchschnittliche Transaktionsrate und die Latenz. Das Standardskript lehnt sich lose an den Banken-Benchmark TPC-B an.

Laut pgbench-Dokumentation ist das Standardszenario von TPC-B inspiriert und eben kein echtes TPC-B, daher der Name: Die Ausgabe nennt es TPC-B (sort of) (geprüft am 31. Oktober 2026).

Wie richten Sie eine pgbench-Datenbank ein?

Führen Sie pgbench -i gegen eine bestehende Datenbank aus, mit -s für den Skalierungsfaktor. Der Befehl legt vier Tabellen an und löscht vorhandene Tabellen gleichen Namens, geben Sie pgbench also eine eigene Datenbank.

Bei Faktor 1 enthält pgbench_branches eine Zeile, pgbench_tellers 10, pgbench_accounts 100.000 und pgbench_history keine, und -s vervielfacht diese Zeilen: -s 100 ergibt 10.000.000 Zeilen in pgbench_accounts. Eine Größe auf der Festplatte nennt die Dokumentation nicht, messen Sie sie also nach der Initialisierung (geprüft am 31. Oktober 2026).

Welche eingebauten Skripte bringt pgbench mit?

Drei: tpcb-like (der Standard), simple-update und select-only. Sie wählen eines mit -b oder mit den Kurzformen -N und -S.

Das Standardskript führt sieben Befehle pro Transaktion aus: BEGIN, ein Update und ein Select auf ein zufälliges Konto, Updates auf pgbench_tellers und pgbench_branches, einen Insert in pgbench_history und END. simple-update lässt die beiden Updates auf den kleinen Tabellen weg, vermeidet so Konflikte dort und entfernt den Test laut Dokumentation noch weiter von TPC-B. select-only sendet nur das Select.

Wie schreiben Sie ein eigenes pgbench-Skript?

Schreiben Sie Ihr SQL in eine Datei, setzen Sie Variablen mit \set und den Zufallsfunktionen und übergeben Sie die Datei mit -f. Jede Ausführung der Datei zählt als eine Transaktion.

\set aid random(1, 100000 * :scale)
\set delta random(-5000, 5000)
BEGIN;
UPDATE pgbench_accounts SET abalance = abalance + :delta
  WHERE aid = :aid;
SELECT abalance FROM pgbench_accounts WHERE aid = :aid;
END;

Ein Gewicht nach @ legt fest, wie oft jedes Skript gewählt wird: -f update.sql@9 -b select-only@1 wählt die Datei in etwa neun von zehn Fällen. Die Dokumentation nennt außerdem random_exponential, random_gaussian und random_zipfian, mit denen sich einige Zeilen zu Hotspots machen lassen. \sleep fügt eine Pause ein, das Datenbank-Gegenstück zur Think Time. Wenn Sie nur eigene Dateien ausführen, geben Sie den Skalierungsfaktor der Datenbank mit -s an, sonst bleibt :scale bei 1 und das Skript oben trifft nur die ersten 100.000 Konten. Mit eigenen Tabellen lassen Sie -i weg und setzen -n, damit pgbench die Standardtabellen nicht per VACUUM bereinigt (geprüft am 31. Oktober 2026).

Welche Optionen machen pgbench zum Lasttest?

Die Parallelität kommt aus -c und -j, die Dauer aus -T und die Form der Last aus -R. Ohne -R startet jeder Client seine nächste Transaktion, sobald die vorige endet.

Diese Voreinstellung ist ein geschlossenes Lastmodell, wie unser Artikel zum offenen vs geschlossenen Lastmodell erklärt. Mit -R startet pgbench Transaktionen nach einem Poisson-verteilten Zeitplan, der ab dem Start des Clients voranschreitet, egal wie es früheren Transaktionen ergangen ist. Die gemeldete Latenz zählt dann ab dem geplanten Start und enthält so den Rückstand auf den Plan (Schedule Lag), dessen Mittelwert und Maximum getrennt erscheinen: genau die Korrektur, die unser Artikel zu Coordinated Omission beschreibt. Die Zahl der Clients bleibt fest; wächst der Rückstand immer weiter, schafft das System diese Rate mit den gewählten Clients und Threads nicht: Senken Sie -R oder erhöhen Sie die Zahl der Clients.

--latency-limit (-L) zählt Transaktionen, die länger als eine Grenze in Millisekunden dauern, als verspätet; mit -R überspringt pgbench außerdem Transaktionen, die schon zu weit hinter dem Plan liegen, und meldet sie als übersprungen. -M prepared nutzt Prepared Statements und läuft laut Dokumentation schneller als die anderen Modi (geprüft am 31. Oktober 2026).

Wie lesen Sie die Ausgabe von pgbench?

Die Zusammenfassung nennt die Einstellungen, verarbeitete und fehlgeschlagene Transaktionen, die mittlere Latenz, die anfängliche Verbindungszeit und tps. Die Form unten stammt aus der Dokumentation, ohne die Zahlen:

transaction type: <builtin: TPC-B (sort of)>
number of transactions actually processed: ...
number of failed transactions: ... (...%)
latency average = ... ms
latency stddev = ... ms   (only with -P, -R or -L)
initial connection time = ... ms
tps = ... (without initial connection time)

Fehlgeschlagene Transaktionen sind Serialisierungs- oder Deadlock-Fehler, die --max-tries wiederholen kann. Andere SQL-Fehler brechen den betroffenen Client ab und führen zum Exit-Status 2. Perzentile enthält die Zusammenfassung nicht: Für die Tail-Latenz protokollieren Sie jede Transaktion mit -l, das ihre Dauer in Mikrosekunden festhält, und berechnen p95 oder p99 selbst.

Ohne -P, -R oder -L wird die mittlere Latenz der Zusammenfassung nicht gemessen: pgbench leitet sie aus Laufzeit und Client-Zahl ab, also Little’s Law rückwärts gerechnet, Fehlschläge eingeschlossen. Setzen Sie -P, wenn es auf die Latenz ankommt.

Wie bekommen Sie pgbench-Zahlen, denen Sie trauen können?

Lassen Sie jeden Lauf mehrere Minuten dauern, wiederholen Sie ihn, halten Sie den Skalierungsfaktor mindestens so groß wie die Zahl der Clients und behalten Sie VACUUM im Blick. Wird pgbench selbst zum Engpass, verlegen Sie es auf eine andere Maschine.

Die erste Richtlinie im Abschnitt „Good Practices“ der Dokumentation warnt davor, einem Test zu glauben, der nur wenige Sekunden läuft, und ergänzt, dass reproduzierbare Zahlen Stunden brauchen können (geprüft am 31. Oktober 2026). Mit dem Standardskript misst ein Skalierungsfaktor unter der Client-Zahl vor allem Update-Konflikte, weil pgbench_branches nur -s Zeilen hat und jede Transaktion eine davon ändert. Tote Zeilen und Autovacuum verschieben die Ergebnisse zwischen den Läufen. Bei vielen Sitzungen kann pgbench seinen eigenen Host auslasten: Führen Sie es auf einer separaten Maschine mit niedriger Netzwerklatenz aus oder verteilen Sie mehrere Instanzen auf mehrere Maschinen.

Wann ist pgbench das falsche Tool?

Wenn es um Benutzer, eine andere Datenbank oder einen standardisierten OLTP-Mix geht. pgbench misst PostgreSQL allein, ohne Ihren Connection-Pool, Ihr ORM, Ihren Cache und Ihre HTTP-Schicht.

Um zu sehen, was Benutzer erleben, setzen Sie die HTTP- oder API-Schicht davor unter Last. LoadFocus, der Herausgeber dieser Website, führt kein pgbench aus und kann sich nicht direkt mit PostgreSQL verbinden: LoadFocus führt JMeter-Testpläne und k6-Skripte aus 25 Cloud-Regionen gegen Web- und API-Endpoints aus.

Wählen Sie für MySQL sysbench: Sein Repository beschreibt ein skriptfähiges Benchmark-Tool mit mehreren Threads und OLTP-artigen Datenbanktests. Wählen Sie HammerDB für einen Mix im Stil von TPC-C: Die Dokumentation beschreibt TPROC-C, einen von TPC-C abgeleiteten Workload, den HammerDB auf PostgreSQL und anderen Datenbanken ausführt. Wählen Sie JMeter mit dem Sampler JDBC Request, um SQL und HTTP in einem Testplan auf Ihren eigenen Maschinen zu mischen (alles geprüft am 31. Oktober 2026).

FAQ

Was bewirkt die Option -s in pgbench? Sie setzt bei der Initialisierung den Skalierungsfaktor. Jede Einheit fügt pgbench_accounts 100.000 Zeilen hinzu, -s 100 erzeugt also 10.000.000 Zeilen. Halten Sie den Wert beim Standardskript mindestens so groß wie Ihre Client-Zahl.

Was ist der Unterschied zwischen -c und -j in pgbench? Die Option -c legt die Zahl der simulierten Clients fest, jeder davon eine gleichzeitige Datenbanksitzung. Die Option -j legt fest, wie viele Worker-Threads in pgbench sich diese Clients teilen.

Kann LoadFocus pgbench ausführen? Nein. LoadFocus führt JMeter-Testpläne und k6-Skripte aus und hat keine direkte Verbindung zu PostgreSQL, Sie setzen damit also die Web- oder API-Schicht vor der Datenbank unter Last.

Weiterlesen

• Coordinated Omission: was es ist und wie man es vermeidet
• Offenes vs geschlossenes Lastmodell: welches passt wann?
• Tail-Latenz: was sie ist und wie man sie misst
• Little’s Law im Lasttest: Tests dimensionieren und prüfen
• sysbench nutzen: CPU-, Festplatten- und MySQL-Benchmarks
• YCSB: Workloads A-F, Ausführung und Grenzen
• redis-benchmark: richtig nutzen und die Zahlen lesen
• TPC-H: was der Benchmark misst und wie Sie ihn ausführen

Die technischen Aussagen in diesem Artikel wurden nicht unabhängig geprüft.