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

WordPress relies on the wpdb class to open a MySQL connection for each request. By default it does not maintain an application‑level pool, but persistent connections can be enabled via mysqli.allow_persistent. When PHP‑FPM spawns more child processes than the database permits, the server can emit "Too many connections" errors during traffic spikes.

The core uncertainty lies in whether the current pm.max_children setting is too high for the configured max_connections on the MySQL server, and whether disabling persistent connections would alleviate the intermittent exhaustion without introducing unacceptable latency.

1. How can we verify that the current PHP‑FPM pm.max_children setting is directly causing the "Too many connections" errors?
2. What is the impact on request latency if we disable mysqli.allow_persistent in the WordPress environment?
3. Are there documented WordPress hooks or configuration options that allow programmatic closing of idle wpdb connections before script termination?