WordPress wpdb Persistent Connection Limits and PHP‑FPM Child Process Mismatch

Direct Answer

Yes — if mysqli.allow_persistent is enabled, PHP-FPM child processes can hold MySQL links open across requests. When the number of active children approaches or exceeds the effective connection budget on MySQL, traffic spikes produce "Too many connections." This is a likely explanation, not yet a confirmed fact, until you correlate FPM worker count with Threads_connected.

1. Verifying the Causal Link

Sample MySQL and PHP-FPM at the same moment during a spike.

• Check current MySQL connection usage:
  mysqladmin -u <user> -p extended-status | grep -E 'Threads_connected|Max_used_connections'
• Check the server-side limits that apply to the WordPress user:
  mysql -u <user> -p -e "SHOW VARIABLES LIKE 'max_connections'; SHOW VARIABLES LIKE 'max_user_connections';"
• Check active FPM workers for your pool:
  ps -eo pid,args | grep 'php-fpm: pool' | grep -v grep | wc -l

If Threads_connected climbs toward max_connections while the worker count is also high, and error timestamps align with child spawn events, the correlation is strong. Remember that max_user_connections can cap the WordPress DB user independently of the global limit.

2. Latency Impact of Disabling Persistence

Setting mysqli.allow_persistent=0 forces a fresh TCP connection and MySQL auth handshake for every request. For local Unix-socket or low-latency network deployments, the added overhead is typically small and often in the low-millisecond range, but you should measure it in your own environment. If WordPress connects over SSL or to a remote database host, the handshake cost rises and may become noticeable. In most standard WordPress deployments the trade-off is acceptable because it prevents connection accumulation and stabilizes Threads_connected.

3. Programmatic Idle Connection Closing

WordPress does not expose a documented hook to close idle wpdb connections before script termination. The wpdb object closes its link in __destruct(), but persistent mysqli links are managed by PHP-FPM and are not returned to a pool that WordPress can drain. You can register a shutdown action, but calling mysqli::close() on a persistent link does not release the underlying MySQL thread in a way that prevents reuse by the same child process. The reliable control point is the PHP-FPM pool configuration and the mysqli.allow_persistent setting, not a WordPress hook.

Recommended Change

Apply the setting in the FPM pool, not in wp-config.php:

php_value[mysqli.allow_persistent] = 0

Reload FPM and monitor Threads_connected under load.

One diagnostic detail that changes the recommendation: Is your pool using pm = dynamic, static, or ondemand? Under dynamic, children are recycled and persistent links can accumulate quickly; under ondemand, the worker count stays low and the same exhaustion may not occur even with persistence enabled.