Connection Pool Saturation %, MySQL

​

At a glance

Connection Pool Saturation % is the share of the instance’s connection ceiling that is currently in use: Threads_connected / max_connections. It answers a single operational question for the on-call DBA: how close is this server to refusing new connections? At 100% MySQL returns ERROR 1040 (HY000): Too many connections and every new client (application worker, cron job, read replica health check) is rejected until a slot frees up. That failure mode is abrupt, not gradual, so this card is treated as a Hero capacity signal and watched in real time.

​

Calculation

Connection Pool Saturation % = (Threads_connected / max_connections) * 100

• Threads_connected is a global status counter (SHOW GLOBAL STATUS LIKE 'Threads_connected'). It includes connections that are actively running a query and connections that are idle in the Sleep command state. It does NOT include the small number of internal background threads (purge, IO, page cleaner), so it maps cleanly onto application-facing capacity.
• max_connections is a server variable (SHOW GLOBAL VARIABLES LIKE 'max_connections'). On a managed service such as Amazon RDS or Aurora it is frequently set by a formula in the parameter group (for example LEAST({DBInstanceClassMemory/12582880}, 5000)), so the effective ceiling moves with the instance class.

​

Worked example

Breakdown at 19:42 (1,844 connections):
  - 1,420 in 'Sleep' state (idle, held open by the app connection pool)
  - 310 actively running queries
  - 114 in 'Sending data' on a single un-indexed report query

1. Reclaim idle connections. wait_timeout is set to the default 28,800 seconds (8 hours), so idle pool connections never get reaped. Lowering it to 600 seconds and lowering the application pool’s max-idle setting frees hundreds of slots without touching live traffic.
2. Kill the offending query, not the pool. The 114 connections stacked on the un-indexed report query are the immediate accelerant. Identify it via Top 10 Slowest Queries (digest), KILL the runaway, and route the report to a read replica.
3. Raise the ceiling only as a last resort. SET GLOBAL max_connections = 2500 buys headroom instantly, but each connection costs memory (per-thread buffers), so raising it on a memory-constrained instance trades a connection error for an out-of-memory kill. Check Memory Usage % before turning this dial.

Why 90% is the line, not 100%:
  - At 92% there are 156 free slots.
  - The app pool can open a 200-connection burst on a single deploy or a retry storm.
  - 156 < 200, so a routine event would tip the instance into ERROR 1040.
  - 90% gives the team a minute or two to act before rejections start.

1. Saturation is about headroom, not load. A server at 92% saturation with 1,420 idle connections is not busy, it is leaking slots. Read this card alongside Connections In Use and SHOW PROCESSLIST to separate “working hard” from “holding slots”.
2. The cure is usually the application pool, not the database. Most saturation events trace back to an oversized or mis-tuned client-side pool (HikariCP, PgBouncer-style proxies, PHP persistent connections) rather than genuine demand.
3. Raising max_connections is a sedative, not a fix. It removes the symptom and adds memory pressure. Treat it as a bridge while you fix the real cause.

​

Sibling cards

​

Reconciling against the source

SHOW GLOBAL STATUS LIKE 'Threads_connected'; for the live numerator. SHOW GLOBAL VARIABLES LIKE 'max_connections'; for the denominator. SHOW STATUS LIKE 'Max_used_connections'; for the high-water mark since the last restart, which tells you the worst saturation the instance has seen. SELECT * FROM performance_schema.threads; or SHOW PROCESSLIST; to see what each connection is actually doing.

SELECT
  ROUND(
    (SELECT VARIABLE_VALUE FROM performance_schema.global_status
       WHERE VARIABLE_NAME = 'Threads_connected')
    /
    (SELECT VARIABLE_VALUE FROM performance_schema.global_variables
       WHERE VARIABLE_NAME = 'max_connections') * 100, 1
  ) AS connection_pool_saturation_pct;

​

Known limitations / FAQs

​

Tracked live in Vortex IQ Nerve Centre