PostgreSQL Config Tuner
PostgreSQL-Produktionsleistungs-Engine

PostgreSQL (postgresql.conf) Hardware Tuner & Builder

Berechnen und generieren Sie optimierte postgresql.conf-Einstellungen basierend auf Hardwarespezifikationen (shared_buffers, work_mem, effective_cache_size, max_connections).

Zero-Telemetrie-Clientausführung
Voreinstellungen:
Eingabe
Total System RAM (Memory)
GB RAM
Physical / Virtual CPU Cores
Kerne
Verbindungen
Clients
~41MB work_mem/Verb.
RAM: 32GB•CPU: 8 Kerne•Workload: web•Storage: nvme
# ----------------------------------------------------------------------
# PostgreSQL 17 Hardware-Tuned Configuration
# Target Profile: WEB | RAM: 32GB | CPU: 8 Cores | Storage: NVME
# Generated: 2026-01-01T00:00:00.000Z via ToolsAA Client-Side Tuner
# ----------------------------------------------------------------------

# CONNECTIONS & NETWORKING
max_connections = 200
# Note: Transaction pooler (PgBouncer) is assumed in front of PostgreSQL.

# MEMORY ALLOCATION
shared_buffers = 8GB
effective_cache_size = 24GB
maintenance_work_mem = 1.6GB
work_mem = 41MB
wal_buffers = 16MB
huge_pages = try

# CHECKPOINT & WAL ENGINE
checkpoint_completion_target = 0.9
checkpoint_timeout = 15min
min_wal_size = 2GB
max_wal_size = 16GB
wal_compression = zstd
synchronous_commit = on

# QUERY PLANNER & DISK I/O TUNING
random_page_cost = 1.05
effective_io_concurrency = 300
default_statistics_target = 100
jit = off

# PARALLEL QUERY WORKERS
max_worker_processes = 8
max_parallel_workers_per_gather = 4
max_parallel_workers = 8
max_parallel_maintenance_workers = 4

# TELEMETRY & DIAGNOSTICS
track_io_timing = on
track_functions = pl
log_min_duration_statement = 1000   # Log queries exceeding 1000ms
log_checkpoints = on
log_connections = on
log_disconnections = on
log_lock_waits = on
shared_buffers: 8GB•work_mem: 41MB•effective_cache: 24GB
Shared Buffers Allocation
8GB

PostgreSQL-Kernspeichercache (~25% des physischen Gesamtspeichers).

Effective Cache Size
24GB

Geschätzter verfügbarer OS-Festplattencache für Indexscans (~75% RAM).

Parallel Query Pool
8 Worker

4 parallele Worker pro Gather-Knoten über 8 Kerne

Zero-Knowledge Lokale Ausführung

Alle Datenverarbeitungen, Parsen und Generierungen laufen streng im lokalen Browserspeicher ab. Keine externen Server-Uploads.

Sub-Millisekunden AST-Engine

All data payloads remain strictly local with zero external server communication.

Production Ready Export

Clean, optimized output formats ready for immediate deployment.

Technische Referenz & Architektur-Leitfaden

PostgreSQL (postgresql.conf) Hardware-Tuning & Builder Entwickler-Handbuch — Referenz-Leitfaden

Berechnen und generieren Sie optimierte postgresql.conf-Einstellungen basierend auf Hardwarespezifikationen (shared_buffers, work_mem, effective_cache_size, max_connections).

Wichtige Parameter & Steuerelemente

shared_buffersstring (memory_size)

Dedizierter PostgreSQL-Hauptspeicherpuffer zum Zwischenspeichern von Tabellen- und Indexseiten.

Standard: 25 % des gesamten Arbeitsspeichers (z. B. 4 GB bei 16 GB RAM)
work_memstring (memory_size)

Speicher für interne Sortieroperationen und Hash-Tabellen pro Abfrageknoten vor dem Auslagern auf temporäre Festplattendateien.

Standard: ((Gesamt-RAM - shared_buffers) / (max_connections * 3)) ~ 16 MB - 64 MB
effective_cache_sizestring (memory_size)

Schätzwert des Query-Planners für den für Festplattencaching verfügbaren Speicher (PostgreSQL + OS-Page-Cache).

Standard: 50 % - 75 % des gesamten Arbeitsspeichers (z. B. 12 GB bei 16 GB RAM)
maintenance_work_memstring (memory_size)

Maximaler Speicher für Wartungsoperationen wie VACUUM, CREATE INDEX und ALTER TABLE ADD FOREIGN KEY.

Standard: 5 % - 10 % des gesamten Arbeitsspeichers (bis zu 2 GB)
max_connectionsinteger

Maximale Anzahl gleichzeitiger Client-Verbindungen zur PostgreSQL-Datenbankinstanz.

Standard: 100 (Standard) / 20-50 hinter PgBouncer

Profi-Tipps & Best Practices

Vermeiden Sie es

Vermeiden Sie es, max_connections direkt in der postgresql.conf zu hoch einzustellen (> 200). Nutzen Sie einen Verbindungspooler wie PgBouncer im Transaktionsmodus, um die aktiven Verbindungen niedrig zu halten und deutlich mehr work_mem sicher zuzuweisen.

Setzen Sie auf modernen SSDs/NVMes

Setzen Sie auf modernen SSDs/NVMes random_page_cost vom Standardwert 4.0 auf 1.1 herab und erhöhen Sie effective_io_concurrency auf 200. Dadurch weiß der Abfrage-Planer, dass wahlfreie Zugriffe nahezu so schnell wie sequentielle Lesezugriffe sind.

Setzen Sie

Setzen Sie checkpoint_completion_target = 0.9 und erhöhen Sie max_wal_size auf 16 GB - 32 GB, um Schreibvorgänge gleichmäßig über das Checkpoint-Intervall zu verteilen und Durchsatzeinbrüche zu verhindern.

Wenn shared_buffers auf 8 GB oder

Wenn shared_buffers auf 8 GB oder höher gesetzt ist, aktivieren Sie Linux Huge Pages (vm.nr_hugepages) und konfigurieren Sie huge_pages = try in der postgresql.conf, um TLB-Fehlzugriffe und Kernel-Overhead zu minimieren.

Häufige Fallstricke & Fehlerbehebung

Der Linux OOM-Killer beendet abrupt PostgreSQL-Hintergrundprozesse

Reduzieren Sie work_mem oder verringern Sie max_connections. Beachten Sie, dass work_mem pro Sortier- oder Hash-Knoten innerhalb einer Abfrage allokiert wird und komplexe Abfragen diesen Wert mehrfach beanspruchen können.

FATAL: could not create shared memory segment: Cannot allocate memory

Überprüfen Sie die Kernel-Parameter (sysctl vm.max_map_count) und den freien Arbeitsspeicher des Systems. Stellen Sie sicher, dass shared_buffers die physikalischen Speichergrenzen oder Container-Limits nicht überschreitet.

Datenbank-Logs melden häufige Checkpoints (checkpoints are occurring too frequently)

Vergrößern Sie max_wal_size (z. B. von 1 GB auf 16 GB) und verlängern Sie checkpoint_timeout (z. B. von 5 min auf 15 min), um ein vorzeitiges Auslösen durch volle WAL-Segmente zu verhindern.

Häufig gestellte Fragen (FAQ)

Warum ist shared_buffers unter Linux typischerweise auf 25 % bis 40 % des RAM begrenzt?▼

PostgreSQL nutzt eine duale Caching-Architektur, bei der shared_buffers eng mit dem Linux-Kernel-Page-Cache zusammenarbeitet. Höhere Werte als 40 % führen oft zu doppelter Datenhaltung im RAM, beeinträchtigen das OS-Caching und verstärken I/O-Spitzen bei Checkpoints.

Belegt effective_cache_size tatsächlich physischen Arbeitsspeicher?▼

Nein. effective_cache_size ist ein rein informativer Richtwert für den Abfrageoptimierer (Planner). Er hilft abzuschätzen, ob Indexseiten voraussichtlich bereits im Betriebssystem-Cache liegen, ohne physischen Speicher zu reservieren.

Wie unterscheidet sich work_mem von maintenance_work_mem?▼

work_mem wird dynamisch für Sortier- und Hash-Vorgänge bei regulären Benutzerabfragen reserviert. maintenance_work_mem wird hingegen ausschließlich für administrative Operationen wie VACUUM, CREATE INDEX oder REINDEX verwendet und kann deutlich höher angesetzt werden, da selten mehrere solcher Aufgaben parallel laufen.

Wie unterscheiden sich die Konfigurationen für OLTP- und OLAP-Workloads?▼

OLTP-Systeme mit hoher Parallelität erfordern ein moderates work_mem und strikte Verbindungslimits für minimale Latenzen. OLAP-/Data-Warehouse-Systeme mit wenigen gleichzeitigen Abfragen profitieren von deutlich höherem work_mem (z. B. 256 MB - 1 GB) und höherem max_parallel_workers_per_gather für rechenintensive Aggregationen.

Verwandte Werkzeuge & Dienstprogramme

Alle Werkzeuge →
Tägliche Off-Peak-DatenbanksicherungEntwickler

Erstellen Sie produktionsreife systemd-Timer-Units und zugehörige Oneshot-Services mit OnCalendar-Planung, OnBootSec-Intervallen, Persistent-Ausführung und zufälligen Verzögerungen.

Werkzeug öffnen→
TypeScript (tsconfig.json) Konfigurations-Generator Entwickler-HandbuchEntwickler

Erstellen Sie moderne, robuste tsconfig.json-Konfigurationen für Next.js, Node.js, Vite oder Bibliotheken mit Strict Mode, Pfad-Aliasen und optimaler Modulauflösung.

Werkzeug öffnen→
Entwicklerhandbuch für den JSON zu ClickHouse CREATE TABLE DDL GeneratorEntwickler

Konvertieren Sie JSON-Dokumente in ClickHouse SQL DDL mit MergeTree-Engine, UInt/Int/Float/String/DateTime-Typen sowie Array/Nested-Spaltenzuordnungen.

Werkzeug öffnen→
JSON zu Google BigQuery Tabellenschema GeneratorEntwickler

Analysieren und konvertieren Sie JSON-Objekte in Google Cloud BigQuery-Tabellenschema-JSON mit RECORD-Modus, STRING-, INTEGER-, NUMERIC- und TIMESTAMP-Feldern.

Werkzeug öffnen→
Entwicklerhandbuch: JSON zu Snowflake CREATE TABLE DDL GeneratorEntwickler

Konvertieren Sie JSON-Nutzdaten und -Schemas in produktionsreife Snowflake SQL CREATE TABLE-Anweisungen mit optimierten Datentypen wie VARIANT, VARCHAR, NUMBER, BOOLEAN und TIMESTAMP_NTZ.

Werkzeug öffnen→
JSON / YAML zu Terraform HCL Variablen & Locals GeneratorEntwickler

Konvertieren Sie JSON- und YAML-Payloads in Terraform HCL-Typbeschränkungen (type = object({...})), Standardwerte, locals-Blöcke und terraform.tfvars-Definitionen.

Werkzeug öffnen→