Distinguishing connection pool exhaustion from thread pool queuing in MariaDB

Answer first

When a client receives 1040 Too many connections, the server has hit max_connections. If the same load produces latency spikes but no 1040, the bottleneck is the thread pool queue.

Confirmed facts

• max_connections is a hard ceiling on authenticated sessions (including SLEEP ones). Reaching it triggers ER_CON_COUNT_ERROR (1040) and increments Connection_errors_max_connections.
• The thread pool plugin (thread_handling=pool-of-threads) only limits concurrent query execution. When all workers are busy, new requests queue inside the pool; the connection remains established and still counts toward max_connections.
• Thread‑pool queuing raises Thread_pool_queued_threads and may cause client‑side timeouts, but it never produces a 1040 error.

Likely explanation for mimicked exhaustion

A small thread_pool_size under heavy concurrency can fill max_connections with idle or queued sessions. The application then sees refused connections that look like exhaustion, while the server is actually thread‑starved.

Reliable server indicators

• Connection_errors_max_connections > 0 and immediate 1040 on connect = max_connections hit.
• Thread_pool_queued_threads > 0, Threads_running ≈ thread_pool_size, and no 1040 = thread‑pool queuing.
• High Threads_connected with low Threads_running points to a buildup of SLEEP connections.
• Inspect Thread_pool_active_threads, Thread_pool_idle_threads, and Thread_pool_stall_count for worker saturation.

Interaction between thread_pool_size and max_connections

Changing thread_pool_size does not alter the max_connections ceiling. However, a too‑small pool can cause many connections to sit in the queue, filling the max_connections limit and making exhaustion appear as a side effect of queuing.

wait_timeout vs application pool lifetime

Compare server‑side session age (SHOW PROCESSLIST) with wait_timeout (or interactive_timeout for interactive clients). If a SLEEP connection’s Time exceeds the timeout, the server has already closed it, but the client pool may still hold the socket. Client pool lifetimes can be inferred from pool metrics (eviction timestamps, idle counts) and aligned with server timestamps for a generic comparison.

Minimal verification steps for this case

SHOW GLOBAL VARIABLES LIKE 'thread_handling';
SHOW GLOBAL VARIABLES LIKE 'max_connections';
SHOW GLOBAL VARIABLES LIKE 'thread_pool_size';
SHOW GLOBAL STATUS LIKE 'Thread_pool_%';
SHOW GLOBAL STATUS LIKE 'Connection_errors_max_connections';
SHOW GLOBAL STATUS LIKE 'Threads_connected';
SHOW GLOBAL STATUS LIKE 'Threads_running';

Run the above queries under load that is below max_connections but above thread_pool_size; you should see Thread_pool_queued_threads rise while Connection_errors_max_connections stays zero. If Connection_errors_max_connections increments, the problem is true connection exhaustion.

One missing diagnostic detail that changes the recommendation: is thread_handling set to pool-of-threads on the target server? If not, Thread_pool_% variables are absent and queuing occurs at the OS/network layer, requiring a different set of metrics.