WordPress
MySQL connection limits: diagnose too many connections safely
MySQL connection limits protect the database from unbounded sessions, but hitting the limit is usually a concurrency or lifecycle problem. Raising max_connections without checking per-connection memory, query latency, and application pooling can turn a clean “too many connections” error into memory pressure or a slower database.
Measure active versus sleeping connections
Inspect current sessions, connection rate, Threads_connected/Threads_running equivalents, long-running queries, sleeping duration, and connection errors. Hundreds of idle persistent sessions are a different problem from hundreds of active queries.
Map sessions to applications/users/hosts so one pool can be identified.
Calculate concurrency from request behavior
Web applications often open database connections per worker/request. More PHP workers can therefore increase database concurrency. Queue workers, cron, admin jobs, and monitoring also contribute.
Fix slow queries because shorter query time returns connections to the pool faster.
Use application pooling and sane timeouts
Persistent connections can help or hurt depending on runtime and pool design. Configure pool maximums below the database ceiling with room for administration and maintenance.
Avoid extremely long idle timeouts when clients do not need persistent sessions.
Raise the server ceiling only with memory headroom
Estimate connection-specific buffers plus global database memory and observe real process RSS. Increase max_connections only when legitimate concurrency requires it and the server can handle the memory/CPU/query load.
- Separate active from sleeping.
- Map sessions to workloads.
- Bound application pools.
- Protect memory before raising max_connections.