Warum sind die PostgreSQL-Standardwerte für Parallel-Worker oft zu niedrig?

PostgreSQL setzt standardmäßig max_parallel_workers_per_gather auf 2 und max_worker_processes auf 8. Auf modernen Multi-Core-Servern (16 bis 64 Cores) bedeutet das, dass rechenintensive Abfragen und Scans 90 % der CPU-Kerne ungenutzt lassen. Die richtige Anpassung bringt in der Praxis regelmäßig Beschleunigungen um den Faktor 3 bis 5.

Wie berechnet man work_mem sicher, um Out-of-Memory (OOM) zu vermeiden?

work_mem wird nicht pro Verbindung allokiert, sondern pro Sortier-, Hash- oder Aggregations-Knoten und pro parallelem Worker. Eine komplexe Abfrage mit 4 Workern und 3 Sortieroperationen kann bis zu 12-mal work_mem belegen. Die Formel muss daher sowohl max_connections als auch max_parallel_workers_per_gather berücksichtigen.

Wann sollten HugePages auf Linux für PostgreSQL aktiviert werden?

HugePages (2 MB Pagesize) lohnen sich ab einer shared_buffers-Größe von ca. 8 bis 16 GB. Sie reduzieren den Page-Table-Overhead im Kernel, verhindern TLB-Misses und sorgen für stabilere Latenzen. Der Kernel-Wert vm.nr_hugepages muss passend zu shared_buffers konfiguriert werden.

⚡ Performance-Engineering

PostgreSQL Performance- & Parallel-Worker Konfigurator

Berechnen Sie maßgeschneiderte Einstellungen für Ihre postgresql.conf und das darunterliegende Betriebssystem. Berücksichtigt CPU-Kerne, Arbeitsspeicher, NVMe-Storage und die entscheidenden Multi-Core Parallel-Worker-Hebel für spürbare Beschleunigung (Faktor 3–5).

1. Betriebssystem & Version

Betriebssystem

PostgreSQL Version

2. Hardware-Ausstattung

CPU-Kerne (physisch / Threads) 16 Cores

System-Arbeitsspeicher (RAM) 32 GB

Storage / Datenträger

Dediziertes, separates Laufwerk für das Write-Ahead-Log (pg_wal)

3. Workload & Verbindungen

Anwendungs-Charakteristik

Gleichzeitige Verbindungen (max_connections) 100 Verbindungen

Empfohlene Konfiguration für postgresql.conf

Kernel-Tuning für /etc/sysctl.d/99-postgresql.conf

🚀 Der Multi-Core Parallel-Worker Hebel

In Standard-Installationen bremst PostgreSQL moderne Mehrkern-Server künstlich aus: max_parallel_workers_per_gather = 2 bedeutet, dass selbst bei 16 oder 64 verfügbaren Kernen nur maximal zwei Worker gleichzeitig an einem Tabellenscan arbeiten dürfen.

Erst die gezielte Anhebung von max_worker_processes, max_parallel_workers und max_parallel_workers_per_gather ermöglicht es der Datenbank, Abfragen über 4 bis 8 Worker zu parallelisieren – dies bringt den oft beobachteten Faktor 3–5 Geschwindigkeitsgewinn.

⚠️ Die work_mem-Multiplikationsfalle

work_mem wird nicht einmalig pro Verbindung reserviert, sondern pro Sortier- oder Hash-Knoten im Ausführungsplan und pro parallelem Worker!

Ein Beispiel: Eine Abfrage mit 2 Sorts und 1 Hash-Join, ausgeführt mit 4 parallelen Workern, belegt bis zu 3 × 5 = 15 × work_mem. Bei 100 gleichzeitigen Verbindungen führt ein unbedacht gewähltes work_mem = 256MB unvermeidlich zum Eingreifen des Linux OOM-Killers.

💾 HugePages & I/O-Concurrency

Standard-Speicherseiten in Linux sind 4 KB klein. Bei 32 GB shared_buffers muss die CPU über 8 Millionen Page-Table-Einträge verwalten. Der Wechsel auf 2-MB-HugePages reduziert diesen Aufwand um den Faktor 512, senkt die TLB-Misses drastisch und stabilisiert die Latenzen unter Hochlast.

Häufige Fragen zur PostgreSQL-Konfiguration

Warum sind die Standard-Einstellungen von PostgreSQL so defensiv?

PostgreSQL wird so ausgeliefert, dass es selbst auf schwächster Hardware (z. B. 512 MB RAM und 1 CPU-Kern) sofort startet, ohne das System zu überlasten. Für moderne Produktionsserver mit Multi-Core-CPUs, NVMe-SSDs und vielen Gigabyte RAM sind diese Vorgaben jedoch völlig ungeeignet.

Wie übernehme ich die Werte auf meinem Server?

Die Einstellungen für postgresql.conf können in /etc/postgresql/{version}/main/conf.d/99-tuning.conf (Debian/Ubuntu) oder direkt am Ende der postgresql.conf eingefügt werden. Die meisten Werte erfordern einen Neustart (systemctl restart postgresql), insbesondere shared_buffers und max_worker_processes.

Lohnt sich ein Connection Pooler wie PgBouncer?

Ja, absolut. Jede PostgreSQL-Verbindung ist ein eigener Betriebssystem-Prozess, der 5–20 MB Speicher verbraucht und den Kontextwechsel der CPU belastet. Mit PgBouncer genügen oft 20–50 echte Datenbankverbindungen, um Tausende Web-Anfragen latenzarm abzuwickeln.

🎓 Inhouse-Seminar: PostgreSQL Performance-Tuning

Lernen Sie Ausführungspläne lesen, Index-Scans optimieren, Speicherparameter abstimmen und Engpässe systematisch beheben – praxisnah an Ihren eigenen Datenbanken.

Zum Tuning-Seminar →

🚀 Automatisches Backup: pg-clusterbackup

Sichern Sie alle PostgreSQL-Cluster und -Instanzen auf einem Host automatisch mit parallelen Dumps und Generations-Rotation. Open Source unter MIT-Lizenz.

Open Source Tool entdecken →