OpenStack SQL Connection Calculator

Estimate how many database connections a service deployment (API via Apache mod_wsgi + RPC workers, e.g. neutron with ML2/OVS, nova, …) can open, to size the database's max_connections. Agents never talk to SQL directly and are not counted.

API service (Apache mod_wsgi, 1 thread per process)

Number of API pods mod_wsgi processes per pod (WSGIDaemonProcess processes=)

RPC worker service

Number of RPC worker pods rpc_workers per pod (default: half the API processes) rpc_state_report_workers per pod

[database] pool options (per process)

max_pool_size (oslo.db default: 5) max_overflow (oslo.db default: 50) executor_thread_pool_size (oslo.messaging default: 64, bounds RPC workers)

Result — 0 DB-connected processes

process type	pods	procs/pod	peak/proc	peak
reachable peak				0

steady state

reachable peak

hard cap

suggested max_connections budget (peak +20%)

What these numbers mean

Steady state (0) = processes × max_pool_size

The pool is lazy but keeps up to max_pool_size (5) connections idle per process for reuse; overflow connections are closed on return. A service under normal load converges to this — it is what SHOW PROCESSLIST shows on an ordinary day (a plateau it grows toward, not a guarantee).

Reachable peak (0) = Σ processes × min(threads, pool cap)

The worst case that can actually happen: a connection is only held while a thread runs a query, so a process never holds more than its thread count. A 1-thread mod_wsgi process holds at most 1; an RPC worker with 64 executor threads is bound by the pool cap (55) when threads exceed it. Size max_connections for this, plus ~20% headroom and room for the other services sharing the database server.

Hard cap (0) = processes × (max_pool_size + max_overflow)

Pure configuration ceiling: every process is allowed 55 connections, even single-threaded ones that can never use them. Only becomes real if thread counts grow to meet it. Nothing can ever exceed this, but it is too pessimistic for sizing.

Model: every process owns its own SQLAlchemy engine/pool, hard-capped at max_pool_size + max_overflow; the reachable peak per process is min(threads, pool cap). One RPC parent (master) process per RPC pod is counted (it only connects at startup, but the cap applies).