Postgres max_connections ohne Pooler

Postgres verwendet für seine Verbindungen keinen Lightweight-Thread-Pool. Jede Client-Verbindung löst einen vollwertigen Systemprozess aus.

Der postmaster-Prozess erstellt für jeden Verbindungsversuch einen neuen („Fork“), der dieser einzelnen Sitzung gewidmet ist, bis sie geschlossen wird. Die offizielle Projektdokumentation beschreibt genau diesen Mechanismus in ihrem Kapitel über Architekturgrundlagen (postgresql.org/docs/current/connect-estab.html, Abschnitt „Verbindungssemantik“, abgerufen am 24. August 2026).

Diese Wahl hat einen echten Vorteil: Ein Absturz einer Verbindung hat keine Auswirkungen auf die anderen, da jeder Prozess vom Rest des Servers isoliert ist. Es verursacht auch direkte Kosten: Jede zusätzliche Verbindung fügt einen gesamten Betriebssystemprozess zur Planung hinzu, mit eigenem Speicherplatz und eigenem Kontextwechsel-Overhead für den Kernel.

Zwei unterschiedliche Mechanismen wirken sich auf das Gedächtnis aus und ihre Verwechslung führt fast immer zu einer Fehldiagnose.

Das erste ist behoben. Beim Start reserviert Postgres gemeinsam genutzte Speicherstrukturen (Sperren, Prozesstabelle), deren Größe dem Wert von max_connections entspricht, unabhängig davon, ob diese Verbindungen anschließend geöffnet werden oder nicht. In der offiziellen Dokumentation der Einstellung wird ausdrücklich darauf hingewiesen, dass eine Erhöhung möglicherweise mehr gemeinsam genutzten Systemspeicher erfordert, als die Standardkonfiguration Ihres Betriebssystems zulässt (postgresql.org/docs/current/runtime-config-connection.html, abgerufen am 24. August 2026).

Die zweite Möglichkeit ist variabel und im Maßstab viel gefährlicher: work_mem wird nicht einmal pro Verbindung zugewiesen, sondern einmal pro Sortier- oder Hashing-Vorgang im Abfrageplan. Die offizielle Dokumentation ist in diesem Punkt explizit: Eine komplexe Abfrage kann mehrere dieser Vorgänge parallel starten, und mehrere Sitzungen können dasselbe gleichzeitig tun, sodass der tatsächlich verwendete Speicher ein Mehrfaches von work_mem wert sein kann (postgresql.org/docs/current/runtime-config-resource.html, abgerufen am 24. August 2026).

Das offizielle PostgreSQL-Projekt-Wiki dokumentiert eine Benchmark-Formel zur Berechnung, wie viele aktive -Verbindungen Ihre Hardware effizient parallel verarbeiten kann, und nicht, wie viele Verbindungen insgesamt geöffnet sind (wiki.postgresql.org/wiki/Number_Of_Database_Connections, abgerufen am 24. August 2026).

Auf einem Server mit 8 physischen Kernen und SSD-Speicher ergibt die Formel (8 × 2) + 1 = 17 aktive Verbindungen, bevor der Durchsatz nachzulassen beginnt. Diese Zahl ist oft überraschend: Im Vergleich zu den Hunderten von Verbindungen, die eine Anwendung in der Praxis öffnet, erscheint sie winzig. Genau darum geht es im folgenden Absatz.

Die durch die Formel berechnete Zahl misst die Parallelität, die die CPU und die Festplatte aufnehmen können, und nicht die Anzahl der Clientverbindungen, die Ihre Anwendung öffnen muss. Eine Flotte von 20 Anwendungsprozessen, von denen jeder über einen eigenen Pool von 10 Verbindungen verfügt, öffnet 200 gleichzeitige Verbindungen zu Postgres, auch wenn jeweils nur 17 davon aktiv arbeiten. Ohne Pooler muss max_connections die 200 abdecken, nicht die 17. Es ist diese Lücke, die die meisten Architekturen dazu drängt, einen -Pooler im Transaktionsmodushinzuzufügen, auch wenn das bedeutet, dass man sich für einen entscheiden muss (siehe unseren -Vergleich PgBouncer, Supavisor und PgCat).

max_connections wird nicht im laufenden Betrieb ausgetauscht. Dies ist ein postmaster-Kontextparameter: Postgres liest ihn einmal beim Start, um die Größe seines gemeinsam genutzten Speichers zu bestimmen. Ein Neuladen der Konfiguration (pg_reload_conf() oder SIGHUP) reicht nicht aus, Sie müssen den Server neu starten.

Überprüfen Sie zunächst den aktuellen Wert und seinen Kontext, um sicherzustellen, dass ein Neustart erforderlich ist:

SHOW max_connections;

SELECT name, setting, context
FROM pg_settings
WHERE name = 'max_connections';

-- context='postmaster' bestätigt, dass ein Neustart erforderlich ist

Wenden Sie dann den neuen Wert an und starten Sie neu:

ALTER SYSTEM SET max_connections = '300';

-- Geschrieben in postgresql.auto.conf.
-- Keine Auswirkung, bis Postgres neu gestartet wird.

# Mit systemd
sudo systemctl restart postgresql

# Ohne systemd, direkt mit pg_ctl
pg_ctl restart -D $PGDATA -m fast

Die Dimensionierung von max_connections ist nicht nur eine theoretische Übung. So budgetiert Aurabase seine verwalteten Postgres-Cluster:

Dedizierte Cluster: ein Postgres-Cluster pro Projekt

Auf dieser Ebene (siehe unseren Vergleich dediziert vs. gemeinsam genutzte Basis) erhält jedes Projekt seinen eigenen CloudNativePG-Cluster und sein eigenes max_connections-Budget, dessen Größe sich an der Größe der Instanz orientiert:

Gemeinsame Cluster: mehrere Projekte einer Organisation, ein gemeinsames Budget

Auf diesem zweiten Pfad verbinden sich alle Projekte derselben Organisation über einen CNPG-Pooler (PgBouncer, transaction-Modus) vor einem gemeinsam genutzten Primärserver:

Alle Projekte in einer Organisation sind über eine gemeinsame Anwendungsrolle miteinander verbunden. Daher begrenzt allein max_user_connections die Gesamtzahl der Serververbindungen, die diese Rolle im gesamten Cluster öffnen kann: Dies ist der eigentliche Cluster-globale Schutz, nicht max_client_conn, der nur Clientverbindungen zum Pooler selbst begrenzt.

Dieser Pooler bedient jedoch nur den SDK-Anwendungsverkehr. PostgREST bleibt seinerseits direkt mit dem primären Dienst (-rw) verbunden: Das Pooling im Transaktionsmodus würde seinen Schema-Neulademechanismus zerstören, der auf einen dedizierten LISTEN-Kanal namens pgrstlauscht. Seine eigenen Verbindungen (2 pro Replikat auf der gemeinsam genutzten Ebene, 10 pro Replikat auf der dedizierten Ebene) zählen daher direkt im max_connections-Budget des Primärservers, außerhalb jedes Poolers, genau die Art von „vergessener“ Verbindung, die Schritt 1 des folgenden Verfahrens umfassen muss.

Dieses Verfahren ist nicht von einem bestimmten Tool abhängig: Es gilt für jeden verwalteten oder selbst gehosteten Postgres-Server.

1. Zählen Sie Ihre tatsächlichen Clientverbindungen. Anzahl der Anwendungsprozesse multipliziert mit der Größe ihres internen Pools, plus Verwaltungstools, Replikation und Überwachung. Es ist diese Zahl, nicht die Formel, die die Untergrenze für max_connections festlegt.
2. Berechnen Sie die ideale Parallelität Ihrer Hardware mit der Formel aus dem PostgreSQL-Wiki: (physische Kerne × 2) + effiziente Festplatten. Diese Zahl gibt an, wie viele dieser Verbindungen tatsächlich parallel arbeiten können, ohne dass der Durchsatz beeinträchtigt wird.
3. Legen Sie „max_connections“ über dem tatsächlichen Bedarf für Schritt 1 fest, mit Spielraum für superuser_reserved_connections und für alle Admin-Tools, die ihre eigenen Verbindungen außerhalb der Anwendung öffnen.
4. Übernehmen Sie die Änderung mit ALTER SYSTEM SET und starten Sie dann den Server neu. Dies ist ein Postmaster-Parameter: Ein einfaches Neuladen reicht nicht aus, wie oben beschrieben.
5. Überwachen Sie pg_stat_activity im Laufe der Zeit. Wenn die Anzahl der inaktiven Verbindungen die Anzahl der aktiven Verbindungen bei weitem übersteigt, handelt es sich nicht um ein max_connections-Problem: Es ist das Signal, dass Sie einen Pooler vor dem Server benötigen, nicht eine höhere Zahl.

Die Überwachungsanfrage aus Schritt 5, direkt nutzbar:

SELECT state, count(*)
FROM pg_stat_activity
GROUP BY state
ORDER BY count(*) DESC;

Drei Signale kehren systematisch zurück, wenn max_connections allein nicht mehr ausreicht, unabhängig von ihrem Wert.

1. Der Fehler FATAL: sorry, too many clients already tritt während der Spitzenlast auf, während sich die meisten von pg_stat_activity angezeigten Verbindungen im Ruhezustand befinden.
2. Die Anwendung läuft in einer serverlosen Umgebung oder mit kurzlebigen Workern (Edge-Funktionen, kurze Jobs), die Verbindungen viel schneller öffnen und schließen, als das Prozess-pro-Verbindung-Modell von Postgres dafür ausgelegt ist.
3. Die obige Formel und das obige Verfahren wurden bereits angewendet, und der tatsächliche Bedarf an Clientverbindungen übersteigt weiterhin den verfügbaren Speicher, der zugewiesen werden kann, ohne work_mem oder shared_buffers zu gefährden.

In diesen drei Fällen ist die richtige Antwort fast immer ein Pooler zwischen der Anwendung und Postgres und kein höherer max_connections. Unser -Vergleich PgBouncer, Supavisor und PgCat beschreibt die drei Optionen im Detail, und unser -Leitfaden zum Transaktionsmodus erklärt den häufigsten Kompromiss, sobald der Pooler vorhanden ist. Informationen zu allen Postgres-Tunings, die über Verbindungen hinausgehen, finden Sie in unserer Produktions-Postgres-Tuning-Checkliste.