An intermittent database error during traffic is often a capacity relationship, not a bad password. PHP workers, background jobs, monitoring, and other applications may all compete for the same MySQL connection ceiling.
The reliable route is not the longest checklist; establish the failing boundary, keep one clean reproduction, and change one layer at a time until the evidence lets you find connection pressure, slow queries, leaked connections, and worker mismatches before raising MySQL max_connections.
Read the failure at the right layer
- Concurrent PHP workers can collectively open more database sessions than MySQL permits.
- Slow or blocked queries hold connections long enough for new requests to pile up.
- A deployment, crawler burst, or job runner sharply increases simultaneous work.
The branches are ordered to protect the strongest evidence around this possibility: concurrent PHP workers can collectively open more database sessions than MySQL permits. The observed scope and logs—not a familiar-looking error screen—decide which one applies.
Database symptoms should be divided into reachability, authentication, capacity, integrity, and query behavior; repair tools address integrity; they do not correct a full disk, an exhausted connection pool, or an unreachable host; in this guide, the practical goal is to find connection pressure, slow queries, leaked connections, and worker mismatches before raising MySQL max_connections.
Build a clean diagnostic record
- Capture
Threads_connected,Threads_running,max_connections, andSHOW PROCESSLISTthrough an administrator connection. - Compare PHP-FPM worker limits and job concurrency with the database ceiling.
- Identify long-running or repeated queries rather than counting plugins.
- Check whether another site or service shares the same database server.
The sequence moves from observation toward intervention. Preserve the result of the final check—check whether another site or service shares the same database server—because it provides a useful comparison after the repair.
Take a connection-pressure snapshot
Run this from an administrative database session during or immediately after the event. It measures pressure before any limit is raised.
SHOW GLOBAL STATUS LIKE 'Threads_connected';
SHOW GLOBAL STATUS LIKE 'Threads_running';
SHOW GLOBAL VARIABLES LIKE 'max_connections';
SHOW FULL PROCESSLIST;Interpretation and safety: Redact hostnames, users, query text, and tenant data before sharing the process list. Long-running repeated queries are usually more useful than the raw number of installed plugins.
One practical branch through the failure
Treat “Concurrent PHP workers can collectively open more database sessions than MySQL permits” as a working hypothesis, not a conclusion. Establish a baseline first: capture Threads_connected, Threads_running, max_connections, and SHOW PROCESSLIST through an administrator connection. Record both the result you expected and the result you actually saw.
A supporting result justifies a staging test of the narrowest repair: stop the runaway job or request source and correct the slow operation. A result that contradicts “Concurrent PHP workers can collectively open more database sessions than MySQL permits” is useful too: it rules out one layer without disturbing production and gives the next operator a clean starting point.
Repair the cause—not the message
- Stop the runaway job or request source and correct the slow operation.
- Align application concurrency with database and memory capacity.
- Raise max_connections only with memory headroom and a reserved administrative path; the MySQL manual documents the extra administrative connection.
Before applying “Stop the runaway job or request source and correct the slow operation,” name its rollback point and the evidence that will count as success. Afterward, repeat the original request and specifically check whether you can load test at a controlled rate below production risk; a changed symptom at that point is new evidence, not permission to make several more changes at once.
Verification checklist
- Load test at a controlled rate below production risk.
- Watch connected and running threads return to baseline after the burst.
- Confirm ordinary and administrative connections remain available.
One successful refresh is not closure. Keep the incident open until you can also watch connected and running threads return to baseline after the burst, adjacent paths have not regressed, temporary diagnostics are gone, and another operator can explain what changed.
Prepare a useful escalation if the boundary is outside your control
Before a database-changing repair, record table sizes and status, create a restorable dump, and know which file backup belongs to it; give a host the error timestamp, database endpoint, anonymized error code, connection metrics, and whether failures are constant or load-dependent; include the result of this first observation: capture Threads_connected, Threads_running, max_connections, and SHOW PROCESSLIST through an administrator connection.
State what was tested, including the result of “Capture `Threads_connected`, `Threads_running`, `max_connections`, and `SHOW PROCESSLIST` through an administrator connection,” and what changed between attempts; evidence tied to that observation is safer and more actionable than granting broad access or sending an unnecessary full database export.
Tempting moves to avoid
- A larger connection ceiling is not a substitute for finding blocked queries.
- Do not kill every database session indiscriminately; writes may be interrupted.
Incident handoff
Primary references
- MySQL too many connections — official reference consulted for this guide.
- WordPress performance — official reference consulted for this guide.
Editorial note: The scenario above illustrates how to approach “Stop the runaway job or request source and correct the slow operation”; it is a documented example, not a claim about a reader’s server, so verify the cited documentation, take the appropriate backup, and follow the real environment’s access and change-control rules.