0Pricing
PostgreSQL Performance & Query Optimization · Lektion

Pools an die Anzahl der Kerne anpassen

Leiten Sie Grenzwerte für Pools und max_connections aus CPU und Workload ab, um Thrashing zu vermeiden.

Pools an die Anzahl der Kerne anpassen ist eine kostenlose PostgreSQL Performance & Query Optimization-Lektion auf CoddyKit. Dies ist Lektion 3 von 4. Du kannst die komplette Lektion unten kostenlos lesen – dann übst du sie direkt im Browser mit einem integrierten Code-Editor und einem KI-Tutor rund um die Uhr. Sie ist Teil des PostgreSQL Performance & Query Optimization-Lernpfads, und dein Fortschritt wird über Web und CoddyKit-App synchronisiert. Der PostgreSQL Performance & Query Optimization-Kurs umfasst insgesamt 4 Lektionen.

Teile dieser Lektion wurden noch nicht übersetzt und werden auf Englisch angezeigt.

Why Pool Size Is Not Connection Count

A common mistake is treating the connection pool as a buffer you can grow freely. With PgBouncer in front of PostgreSQL, you actually run two limits: how many clients can talk to PgBouncer, and how many server connections PgBouncer keeps open to PostgreSQL.

  • max_client_conn can be large (thousands) — these are cheap proxied sockets.
  • default_pool_size (and PostgreSQL max_connections) is the expensive number — each one is a real backend process.

This lesson is about choosing that expensive number from your CPU core count and workload, so the database does real work instead of thrashing between too many backends.

One Backend = One Process

Each PostgreSQL connection is backed by a dedicated OS process. When you have more active backends than CPU cores, the kernel time-slices them. Past a point, adding connections does not add throughput — it adds context switches, lock contention, and memory pressure.

You can see how many backends exist right now and how many are actually running queries:

SELECT state, count(*)
FROM pg_stat_activity
WHERE backend_type = 'client backend'
GROUP BY state
ORDER BY count(*) DESC;

The Starting Formula

The widely cited baseline for a CPU-bound, mostly-active workload is:

  • connections = (core_count * 2) + effective_spindle_count

The * 2 accounts for backends that briefly stall on I/O or locks while others use the CPU. The effective_spindle_count approximates how many concurrent I/O operations your storage can absorb (think 0 for a fully cached working set, higher for many-disk arrays).

For an 8-core server on SSD with a mostly-cached dataset, this lands around 16-20 server connections — not 200.

Computing It In SQL

You don't have to do the arithmetic by hand. PostgreSQL exposes detected core counts, so you can compute a starting pool size directly. The query below is self-contained and runs anywhere:

WITH params AS (
  SELECT 8::int  AS core_count,
         0::int  AS effective_spindles
)
SELECT core_count,
       effective_spindles,
       (core_count * 2) + effective_spindles AS suggested_connections
FROM params;

Active vs Idle Backends

The formula sizes for active work. Pools fail in practice because of backends parked in idle in transaction — they hold a slot (and often locks) without doing anything. These eat your budget just as much as busy queries.

Audit them before you size up the pool:

SELECT pid,
       state,
       now() - state_change AS idle_for,
       wait_event_type,
       left(query, 60) AS query
FROM pg_stat_activity
WHERE state = 'idle in transaction'
ORDER BY idle_for DESC;

Pool Mode Changes Everything

How aggressively PgBouncer reuses server connections depends on pool_mode:

  • session: a server connection is tied to a client for its whole session. You need roughly as many server connections as concurrent clients — pooling buys little.
  • transaction: a server connection is returned after each transaction. A small pool can serve many clients. This is what lets (cores*2)-sized pools handle thousands of clients.
  • statement: returned after each statement; most aggressive, but forbids multi-statement transactions.

Sizing against core count assumes transaction mode for OLTP workloads.

A Realistic PgBouncer Block

Putting the numbers together for an 8-core OLTP database, a typical pgbouncer.ini looks like this. Note how max_client_conn is huge while default_pool_size stays near the formula's output:

-- pgbouncer.ini (excerpt)
-- pool_mode = transaction
-- max_client_conn = 2000
-- default_pool_size = 20
-- reserve_pool_size = 5
-- reserve_pool_timeout = 3
-- For an 8-core box: (8 * 2) + 0 = 16, rounded to 20.

max_connections Must Cover Every Pool

PostgreSQL's max_connections is a hard ceiling across all PgBouncer pools plus reserved superuser slots. If you run several databases/users, each gets its own pool of up to default_pool_size, and they all draw from the same backend budget.

Rule of thumb: max_connections ≥ sum of all pool sizes + reserve_pool_size + superuser_reserved_connections + a margin for maintenance and replication.

SHOW max_connections;

SELECT current_setting('max_connections')::int            AS max_conn,
       current_setting('superuser_reserved_connections')::int AS reserved,
       current_setting('max_connections')::int
         - current_setting('superuser_reserved_connections')::int AS usable;

Memory Is The Other Budget

Cores cap useful concurrency, but RAM caps how high max_connections can safely go. Each backend can allocate up to work_mem per sort/hash node, and a single query may use it several times over.

  • Worst case ≈ max_connections * work_mem * (nodes per query).
  • Set work_mem with the real connection ceiling in mind — a small pool lets you afford a larger work_mem.

This is a strong argument for pooling: fewer backends means more memory per query.

SELECT current_setting('work_mem')                       AS work_mem,
       current_setting('max_connections')::int           AS max_conn,
       pg_size_pretty(
         current_setting('work_mem')::bigint
         * current_setting('max_connections')::int
       ) AS naive_worst_case;

Validate Against Real Saturation

The formula is a starting point, not gospel. After deploying, watch whether backends are CPU-bound (good — cores are the limit) or stuck on LWLock/Lock waits (a sign the pool is too large and contention is rising).

Sample the wait events under load:

SELECT coalesce(wait_event_type, 'Running') AS wait_type,
       coalesce(wait_event, 'on_cpu')       AS wait_event,
       count(*)
FROM pg_stat_activity
WHERE state = 'active'
  AND backend_type = 'client backend'
GROUP BY 1, 2
ORDER BY count(*) DESC;

Tuning Loop In Practice

Use a tight feedback loop instead of guessing:

  • Start at (cores * 2) for default_pool_size.
  • Load test. If throughput is flat and latency rises while CPUs are saturated, the pool is already big enough — shrink it.
  • If CPUs sit idle while clients queue at PgBouncer (rising cl_waiting), the pool may be too small or queries are I/O-bound — raise effective_spindle_count and retest.

Check PgBouncer's own view of pressure with the admin console:

-- Connect to the special 'pgbouncer' admin database, then:
SHOW POOLS;
-- Watch cl_active, cl_waiting, sv_active, sv_idle.
-- Persistent cl_waiting > 0 with idle CPUs => pool too small.

Quick Check

You have a 16-core PostgreSQL server, NVMe storage, and a working set that fits entirely in RAM (effectively zero spindles). The app currently opens 800 direct connections and CPUs are pegged with rising lock waits. Using the standard sizing approach with PgBouncer in transaction mode, what is the best starting default_pool_size?

Recap

Key takeaways for sizing pools against core count:

  • Separate the cheap limit (max_client_conn) from the expensive one (default_pool_size / max_connections).
  • Start from (cores * 2) + effective_spindle_count — usually tens of connections, not hundreds.
  • The formula assumes transaction pool mode; session mode needs far more server connections.
  • Ensure max_connections covers the sum of all pools plus reserved slots, and budget RAM via work_mem * max_connections.
  • Hunt down idle in transaction backends and validate with real wait-event and SHOW POOLS data — shrink when CPU-bound, only grow when CPUs idle and clients queue.

Häufig gestellte Fragen

Ist die Lektion „Pools an die Anzahl der Kerne anpassen“ kostenlos?

Ja — der vollständige Text von „Pools an die Anzahl der Kerne anpassen“ ist hier im Web kostenlos zu lesen. Um sie interaktiv zu üben (integrierter Code-Editor und 24/7 KI-Tutor) und den Rest des PostgreSQL Performance & Query Optimization-Kurses freizuschalten, upgrade auf CoddyKit PRO. Der PostgreSQL Performance & Query Optimization-Kurs umfasst insgesamt 4 Lektionen.

Was lerne ich in „Pools an die Anzahl der Kerne anpassen“?

Leiten Sie Grenzwerte für Pools und max_connections aus CPU und Workload ab, um Thrashing zu vermeiden. Du übst PostgreSQL Performance & Query Optimization mit praktischem Code, den du direkt im Browser ausführst, und ein 24/7 KI-Tutor beantwortet deine Fragen während du die Lektion bearbeitest.

Brauche ich Erfahrung, um PostgreSQL Performance & Query Optimization zu starten?

Keine Vorkenntnisse erforderlich. PostgreSQL Performance & Query Optimization auf CoddyKit ist für Anfänger bis fortgeschrittene Lernende strukturiert, sodass du hier starten oder von Anfang an beginnen und in deinem eigenen Tempo voranschreiten kannst. Dies ist Lektion 3 von 4.

Wie lange dauert die Lektion „Pools an die Anzahl der Kerne anpassen“?

Die meisten CoddyKit-Lektionen dauern etwa 5–10 Minuten. Jede ist kompakt und interaktiv, sodass du stetig Fortschritte machst und genau dort weitermachst, wo du aufgehört hast – im Web und in der App.

Kann ich in dieser PostgreSQL Performance & Query Optimization-Lektion Code schreiben und ausführen?

Ja. Jede PostgreSQL Performance & Query Optimization-Lektion enthält einen integrierten Code-Editor, sodass du echten Code direkt in deinem Browser schreibst und ausführst und sofort KI-Feedback erhältst — ohne lokale Einrichtung erforderlich.

Alle Lektionen in diesem Kurs

  1. Warum Verbindungen in PostgreSQL teuer sind
  2. Pooling-Modi für Transaktionen und Sessions
  3. Pools an die Anzahl der Kerne anpassen
  4. Pool-Sättigung und Warteschlangen diagnostizieren
← Zurück zu PostgreSQL Performance & Query Optimization