Database connection exhaustion in PHP often appears as intermittent errors: some requests fail, others remain waiting, and the problem gets worse during periods of high load. Raising the connection limit may provide relief, but it can also shift the saturation to the database server. The solution starts with identifying which resource is running out and what is keeping the connections busy.
Recognize the symptoms and narrow down the failure
Look for errors such as “too many connections,” failures to open a connection, timeouts, or requests that exceed the maximum execution time. Compare how often they occur with traffic and other indicators: application latency, CPU and memory usage, database errors, and request duration.
The difference between high and low load offers an initial clue. If errors appear during peaks and disappear as traffic drops, there may be a concurrency limit. If they persist with few requests, investigate connections being held, blocked processes, long-running queries, or an inaccessible database. Also confirm whether other services share the same limit: PHP may not be the only consumer.
Distinguish exhausted connections from slow queries and locks
These problems are related, but not equivalent. Connection exhaustion occurs when there is no available slot to open another connection. A slow query occupies a connection for longer and can cause exhaustion as queries accumulate. A lock leaves a query waiting for another transaction to release resources. Unavailability means the database cannot accept or serve connections for a broader reason.
Examine the error message and the point of failure. If the request fails before running a query, check connection creation and whether the limit has been reached. If it connects and then takes a long time, inspect in-flight queries, their durations, waits, and open transactions. Don’t conclude that you “need more connections” just because the application is slow to respond: increasing the limit won’t fix an expensive query or a lock.
Relate PHP concurrency to the database limit
In the common PHP model where processes handle requests, each process may need a connection while performing database work. Potential demand depends on how many processes can operate simultaneously, how many connections each one opens, and how long they keep them. Connections used by background jobs, command-line processes, and other services must also be counted.
Make a conservative worst-case estimate: multiply the maximum effective concurrency of each process group by the number of simultaneous connections each process can use, then add the consumers that share the database. Compare the result with the configured limit and leave headroom for administrative operations and load variations. Don’t assume that each request always corresponds to one connection: the lifecycle depends on the database client, configuration, and usage pattern.
Also review how load is distributed. Multiple PHP instances may each stay within their local limits and still collectively exceed the database’s connection allowance. Horizontal scaling increases potential concurrency; it is not a safe mitigation unless the total number of connections is recalculated.
Measure from both ends
Correlate application and database metrics using timestamps. In PHP, record request duration, connection errors, timeouts, and the number of busy processes. In the database, review active and peak connections, rejections, running queries, session age, and wait events reported by the database engine.
Avoid logging credentials, complete connection strings, or sensitive query data. If the database engine allows you to identify sessions and their states, use that information to distinguish an idle connection from an active query or a pending transaction. Compare logs from both sides: a connection spike occurring alongside busy PHP processes points to concurrency; many old sessions or idle processes suggest connections are being held; a few long-running queries may explain why the connection allowance is gradually consumed.
Instrumentation should let you answer three questions: how many connections are in use, how long they last, and what work is keeping them busy. Without that timeline, changing limits or enabling persistent connections introduces more variables and makes it harder to find the cause.
Evaluate persistent and long-lived connections
A persistent connection can reduce the cost of repeatedly opening connections, especially when the environment keeps processes alive between requests. However, a connection that remains associated with a process can also hold a slot even when it is not running queries. If there are many processes or multiple instances, the total number of held connections can reach the database limit.
Check the actual process and driver lifecycle before enabling or disabling them. Verify how the session is reused and whether the application restores the expected state between requests, such as transactions, session variables, or connection-specific settings. Persistent connections are not a universal pool and do not guarantee lower consumption; test them under representative load and monitor peak connections, latency, and residual state.
Mitigate in order and based on evidence
- Limit concurrency. Adjust PHP processes or worker parallelism so simultaneous demand fits within the shared allowance. This reduces pressure, although it may increase queueing and latency if capacity falls below sustained demand.
- Release resources when they are no longer needed. Explicitly close connections if the library and execution pattern allow it, and avoid holding them during work unrelated to the database. Keep in mind that closing a persistent connection does not necessarily release the server’s physical connection: the result depends on the driver and process lifecycle. Check for transactions that remain open and error paths that do not complete cleanup.
- Reduce the time connections are occupied. Analyze slow queries, indexes, result volume, and transactions. Optimizing an operation that holds a connection for a long time can reduce simultaneous demand without raising the limit.
- Adjust limits only after measuring. Raising the maximum may be reasonable if the database has CPU and memory capacity available and the new worst case is sustainable. Otherwise, it allows more work to accumulate and worsens saturation.
Apply one change at a time, record the previous state, and define a rollback condition. If the system is already affected, temporarily reducing concurrency may be safer than restarting all processes at once, which could create a new connection spike.
When to consider a connection pool or proxy
A pool or proxy can reuse physical connections and control how many reach the database engine, which is useful when there are many application processes with short-lived connections. It does not eliminate simultaneous work or make queries faster; it introduces another layer with its own capacity, queues, limits, and operating modes.
Before adopting one, check compatibility with the database engine, PHP driver, authentication, transaction usage, and session state. Review how it handles long-lived connections, reconnections, and proxy failures, and define metrics and procedures for operating it. Validate it with tests that represent real concurrency: a configuration that works in development may behave differently under pressure.
Prepare for recovery and prevent recurrence
Set alerts for connections approaching the limit, rejections, query duration, and PHP process saturation. Add a representative load test that includes instances, background jobs, and other consumers; check the worst case, not just the average. Maintain an operational procedure that specifies what to measure, how to limit concurrency, who can change the connection allowance, and when to roll back.
After service is restored, review the sequence of events preceding the incident: traffic changes, deployments, new queries, process growth, or cleanup failures. The goal is to link cause and effect using data. If metrics show connections being held, fix their lifecycle; if query duration is the main factor, optimize the queries; if legitimate concurrency exceeds capacity, size and limit it using an explicit connection budget.
