Kategorien:	credativ® Inside

Die richtige Dimensionierung eines PostgreSQL®-Servers ist eine der wichtigsten Entscheidungen, die Sie vor dem Produktivbetrieb treffen. Wer zu knapp kalkuliert, riskiert Performance-Engpässe unter Last. Wer überdimensioniert, verschwendet Budget und Ressourcen. Dieser Leitfaden führt Sie Schritt für Schritt durch den gesamten Planungsprozess: von der Workload-Analyse über die Hardware-Auswahl bis zur Validierung im laufenden Betrieb.

Das Ziel ist ein PostgreSQL-Server, der Ihre produktiven Workloads stabil, performant und skalierbar bewältigt. Die hier beschriebenen Schritte gelten sowohl für On-Premises-Umgebungen als auch für Cloud-Instanzen und lassen sich unabhängig von der Unternehmensgröße anwenden.

Voraussetzungen und Workload-Analyse vor der Planung

Bevor Sie auch nur eine einzige Konfigurationszeile schreiben, müssen Sie Ihren Workload verstehen. PostgreSQL Server Sizing ohne Workload-Analyse ist Raten, kein Planen. Sammeln Sie zunächst alle relevanten Informationen über die geplante oder bestehende Datenbanknutzung.

Datenbankgröße: Wie viele Daten werden gespeichert, und wie stark wächst das Volumen pro Monat oder Jahr?
Verbindungsanzahl: Wie viele gleichzeitige Datenbankverbindungen sind realistisch zu erwarten?
Lese-/Schreib-Verhältnis: Handelt es sich eher um einen leselastigen (OLAP) oder schreiblastigen (OLTP) Workload?
Abfragekomplexität: Gibt es häufige Aggregationen, Joins über viele Tabellen oder analytische Abfragen?
Spitzenlastzeiten: Wann treten die höchsten Lasten auf, und wie lange dauern diese Phasen?
Verfügbarkeitsanforderungen: Sind Hochverfügbarkeit und Replikation erforderlich?

Wenn Sie eine Migrationssituation haben und bereits eine bestehende Datenbank betreiben, nutzen Sie Monitoring-Daten aus dem Altsystem als Ausgangsbasis. Werkzeuge wie pg_stat_statements, pg_stat_bgwriter und externe Monitoring-Lösungen liefern belastbare Kennzahlen. Liegt noch keine Datenbasis vor, orientieren Sie sich an vergleichbaren Projekten und planen Sie einen Sicherheitspuffer von mindestens 30 Prozent ein.

CPU-Anforderungen für PostgreSQL richtig einschätzen

Kalkulieren Sie die CPU-Kapazität auf Basis der gleichzeitigen Abfragen und deren Komplexität. PostgreSQL nutzt für jede Verbindung einen eigenen Prozess, was bedeutet: Parallele Abfragen beanspruchen direkt mehrere CPU-Kerne.

Ermitteln Sie die maximale Anzahl gleichzeitiger aktiver Abfragen zu Spitzenlastzeiten.
Schätzen Sie, ob Ihre Abfragen CPU-intensiv sind (komplexe Joins, Sortierungen, Aggregationen) oder eher I/O-gebunden.
Planen Sie für OLTP-Systeme mit vielen kurzen Transaktionen mindestens 4 bis 8 CPU-Kerne ein; für analytische Workloads mit paralleler Abfrageverarbeitung können 16 oder mehr Kerne sinnvoll sein.
Beachten Sie, dass PostgreSQL ab Version 9.6 parallele Abfragen unterstützt. Mit dem Parameter max_parallel_workers_per_gather steuern Sie, wie viele Kerne eine einzelne Abfrage nutzen darf.

Nach der CPU-Planung prüfen Sie, ob Ihre Schätzung mit dem erwarteten Verbindungsmodell übereinstimmt. Wenn Sie einen Connection Pooler wie PgBouncer einsetzen, können Sie die tatsächliche Prozessanzahl deutlich reduzieren und die CPU-Last gleichmäßiger verteilen. Das ist besonders bei Anwendungen mit vielen kurzlebigen Verbindungen empfehlenswert.

Arbeitsspeicher kalkulieren: shared_buffers und darüber hinaus

Arbeitsspeicher ist einer der wichtigsten Hebel für die PostgreSQL-Performance. Der Parameter shared_buffers definiert, wie viel RAM PostgreSQL direkt für den Daten-Cache nutzt. Darüber hinaus spielen aber weitere Speicherbereiche eine entscheidende Rolle.

Setzen Sie shared_buffers auf etwa 25 Prozent des gesamten verfügbaren RAM. Bei einem Server mit 64 GB RAM wären das 16 GB. Dieser Richtwert gilt für dedizierte Datenbankserver.
Planen Sie zusätzlich den Betriebssystem-Page-Cache ein. PostgreSQL nutzt diesen intensiv für sequenzielle Lesezugriffe. Der Parameter effective_cache_size teilt dem Query-Planer mit, wie viel Speicher insgesamt für Caching zur Verfügung steht. Setzen Sie diesen Wert auf 50 bis 75 Prozent des Gesamt-RAMs.
Konfigurieren Sie work_mem sorgfältig: Dieser Speicher wird pro Sortier- oder Hash-Operation pro Verbindung reserviert. Bei 100 gleichzeitigen Verbindungen und 4 MB work_mem können das schnell 400 MB oder mehr sein. Beginnen Sie konservativ mit 4 bis 16 MB und erhöhen Sie den Wert gezielt für analytische Workloads.
Reservieren Sie für maintenance_work_mem (genutzt für VACUUM, CREATE INDEX) einen höheren Wert, zum Beispiel 256 MB bis 1 GB, da diese Operationen nicht gleichzeitig in großer Zahl ausgeführt werden.

Nach der Konfiguration dieser Parameter beobachten Sie im Betrieb, ob die Cache-Hit-Ratio bei pg_stat_bgwriter und pg_statio_user_tables über 95 Prozent liegt. Liegt sie darunter, ist Ihr Arbeitsspeicher für den Workload möglicherweise zu knapp bemessen.

Storage-Architektur und I/O-Kapazität auslegen

Speicher ist häufig der kritischste Engpass bei produktiven PostgreSQL-Workloads. Die Wahl des richtigen Storage-Setups beeinflusst Latenz, Durchsatz und Zuverlässigkeit unmittelbar.

Verwenden Sie für Produktivsysteme ausschließlich SSDs oder NVMe-Laufwerke. Mechanische Festplatten sind für PostgreSQL unter Last in der Regel nicht geeignet, da Random-I/O-Operationen zu langsam sind.
Trennen Sie die Datenbankdaten (PGDATA) und die Write-Ahead-Log-Dateien (WAL) auf separate physische Laufwerke oder zumindest auf separate Volumes. Das WAL-Schreiben ist sequenziell und profitiert von einer eigenen I/O-Lane.
Planen Sie ausreichend IOPS ein. Für OLTP-Systeme mit hoher Schreiblast können mehrere tausend IOPS erforderlich sein. Ermitteln Sie den Bedarf anhand Ihrer Transaktionsrate und der durchschnittlichen Schreibgröße.
Konfigurieren Sie das Dateisystem mit den für PostgreSQL empfohlenen Optionen. Unter Linux hat sich ext4 oder XFS bewährt. Deaktivieren Sie atime-Updates mit der Mount-Option noatime, um unnötige Schreiboperationen zu vermeiden.
Prüfen Sie, ob RAID-Konfigurationen oder Storage-Cluster-Lösungen für Ihre Verfügbarkeitsanforderungen notwendig sind.

Zur Validierung messen Sie die I/O-Leistung mit Werkzeugen wie fio oder iostat, bevor Sie PostgreSQL in Betrieb nehmen. So erkennen Sie Storage-Engpässe, bevor sie im Produktivbetrieb auftreten. Informieren Sie sich auch über PostgreSQL-LTS-Optionen für langfristig stabile Betriebsumgebungen.

Konfigurationsparameter an die Hardware anpassen

Passen Sie nach der Hardware-Planung die PostgreSQL-Konfiguration gezielt an Ihre Ressourcen an. Die Standardwerte in postgresql.conf sind bewusst konservativ gewählt und für Produktionssysteme in der Regel ungeeignet.

Setzen Sie max_connections auf einen realistischen Wert. Mehr Verbindungen bedeuten mehr Speicherverbrauch und mehr CPU-Last durch Prozessverwaltung. Nutzen Sie einen Connection Pooler, um die tatsächliche Verbindungszahl niedrig zu halten.
Konfigurieren Sie checkpoint_completion_target auf 0.9, damit Checkpoints gleichmäßiger über die Zeit verteilt werden und keine I/O-Spitzen entstehen.
Passen Sie wal_buffers an, typischerweise auf 16 MB für schreibintensive Systeme.
Stellen Sie random_page_cost auf 1.1 ein, wenn Sie SSDs verwenden. Der Standardwert von 4.0 ist für mechanische Festplatten ausgelegt und führt auf SSDs zu suboptimalen Query-Plänen.
Aktivieren Sie autovacuum und passen Sie dessen Parameter an Ihre Schreiblast an. Ein zu seltenes VACUUM führt zu Tabellenblähung und Performance-Degradation.

Nutzen Sie nach der initialen Konfiguration Werkzeuge wie pgtune als Ausgangspunkt für Ihre Parameterwahl. Diese Tools generieren auf Basis von RAM, CPU-Anzahl und Workload-Typ eine solide Ausgangskonfiguration, die Sie anschließend gezielt verfeinern. Einen guten Überblick über unterstützte PostgreSQL-Dienstleistungen finden Sie in unserem Kompetenz-Center.

Performance nach dem Aufsetzen validieren und iterieren

Die Dimensionierung eines PostgreSQL-Servers endet nicht mit dem initialen Aufsetzen. Validieren Sie die Performance unter realistischer Last und passen Sie die Konfiguration iterativ an. Kein Sizing-Plan überlebt den ersten Kontakt mit dem echten Workload unverändert.

Führen Sie Lasttests mit einem realistischen Datensatz und typischen Abfragen durch. Werkzeuge wie pgbench ermöglichen reproduzierbare Benchmarks für OLTP-Szenarien.
Aktivieren Sie pg_stat_statements und analysieren Sie nach dem Lasttest, welche Abfragen die meiste Zeit beanspruchen. Konzentrieren Sie Optimierungsmaßnahmen auf die teuersten Abfragen.
Prüfen Sie Systemressourcen während des Lasttests mit top, iostat und vmstat. Identifizieren Sie, ob CPU, RAM oder I/O der limitierende Faktor ist.
Überprüfen Sie das PostgreSQL-Logfile auf langsame Abfragen. Aktivieren Sie dazu log_min_duration_statement und setzen Sie einen Schwellenwert, der zu Ihrem Workload passt.
Wiederholen Sie den Validierungszyklus nach jeder signifikanten Konfigurationsänderung, um Verbesserungen messbar zu machen.

Planen Sie außerdem regelmäßige Reviews der Performance-Kennzahlen im laufenden Betrieb ein. Datenbankgröße, Abfragemuster und Verbindungsanzahl verändern sich über die Zeit. Was heute gut dimensioniert ist, kann in sechs Monaten bereits an Grenzen stoßen. Ein strukturiertes Monitoring, das Trends frühzeitig sichtbar macht, ist daher kein optionales Extra, sondern ein fester Bestandteil des Datenbankbetriebs.

Wie credativ® beim PostgreSQL Server Sizing hilft

Die Dimensionierung eines produktiven PostgreSQL-Servers erfordert tiefes technisches Know-how, Erfahrung mit realen Workloads und ein gutes Gespür für die Wechselwirkungen zwischen Hardware, Betriebssystem und Datenbankparametern. Genau hier setzen wir an. Als PostgreSQL® Competence Center begleiten wir Unternehmen durch den gesamten Lebenszyklus ihrer PostgreSQL-Umgebungen.

Unser Leistungsangebot im Bereich PostgreSQL Server Sizing und Betrieb umfasst:

Workload-Analyse und Sizing-Beratung: Wir analysieren Ihre bestehenden oder geplanten Workloads und leiten daraus konkrete Hardware- und Konfigurationsempfehlungen ab.
Tuning und Optimierung: Unsere Spezialisten identifizieren Performance-Engpässe und optimieren Konfigurationsparameter, Indexstrukturen und Abfragepläne.
High Availability und Replikation: Wir planen und implementieren Hochverfügbarkeitslösungen, die zu Ihren Verfügbarkeitsanforderungen passen.
Maßgeschneidertes Monitoring: Wir richten Monitoring-Umgebungen ein, die Ihnen frühzeitig Hinweise auf Performance-Probleme und Kapazitätsengpässe geben.
Workshops und Schulungen: Wir vermitteln Ihrem Team das Wissen, um PostgreSQL-Umgebungen eigenständig zu betreiben und weiterzuentwickeln.

Ob Sie einen Neuaufbau planen, eine bestehende Umgebung optimieren oder eine Migration durchführen möchten: Wir stehen Ihnen mit unserem Support-Angebot zur Seite. Kontaktieren Sie uns und sprechen Sie mit unseren PostgreSQL-Spezialisten über Ihr Vorhaben.

PostgreSQL® ist eine Marke der PostgreSQL Community Association of Canada. credativ® ist Competence Center für PostgreSQL®. Die Nennung dient ausschließlich der sachlichen Beschreibung von Dienstleistungen von credativ®. Es besteht keine geschäftliche Verbindung zu den genannten Markeninhabern.

Wie dimensioniert man einen PostgreSQL-Server für produktive Workloads?