Qué importa primero: WordPress abre conexiones de base de datos a través de peticiones PHP. Demasiadas conexiones pueden resultar del tráfico, trabajadores atascados, consultas lentas, bots, una fuga de conexión o varios sitios que comparten una base de datos de tamaño inferior.
Qué indica realmente este síntoma
Un valor max_connections más alto puede posponer el error mientras aumenta la presión de memoria. La lista de procesos activos y la condición de petición muestran si la capacidad o el trabajo ineficiente es la verdadera restricción.
Recopila pruebas antes de cambiar nada
- Registrar el tiempo de error y los sitios afectados en el mismo servidor de base de datos.
- Inspecciona conexiones activas y para dormir, usuarios, servidors y duración de la consulta.
- Compara el conteo de trabajadores PHP-FPM con la capacidad de conexión de la base de datos.
- Comprueba consultas lentas logs, picos de tráfico, cron y trabajos de copia de seguridad.
Causas más habituales
- Tráfico o sobrecarga de bot: Muchas PHP concurrentes solicitan conexiones legítimamente abiertas.
- Consultas lentas: Las conexiones permanecen ocupadas porque el trabajo de la base de datos toma demasiado tiempo.
- Piscina PHP de gran tamaño: Más trabajadores pueden llegar a la base de datos de lo que puede servir de forma segura.
- Presión de los equipos compartidos: Otro sitio o tarea consume el presupuesto de conexión común.
Secuencia segura de diagnóstico y reparación
- Reducir o bloquear el tráfico abusivo y pausar el trabajo por lotes no esencial.
- Encuentre y optimice las consultas con conexiones más largas.
- Alinea los límites del trabajador PHP, la memoria de la base de datos y las conexiones max_ como un modelo de capacidad.
- Agregue la monitorización para el uso de la conexión y los intentos rechazados antes de volver a la carga normal.
Cómo distinguir entre las causas probables
No trates Tráfico o sobrecarga de bot y Consultas lentas como causas equivalentes. Muchas PHP concurrentes solicitan conexiones legítimamente abiertas. En cambio, las conexiones permanecen ocupadas porque el trabajo de la base de datos toma demasiado tiempo. Para distinguirlas, usa estas dos comprobaciones: Registrar el tiempo de error y los sitios afectados en el mismo servidor de base de datos; y inspecciona conexiones activas y para dormir, usuarios, servidors y duración de la consulta. Con esos datos podrás decidir si conviene aplicar la primera acción controlada —Reducir o bloquear el tráfico abusivo y pausar el trabajo por lotes no esencial— o si debes conservar el estado actual y ampliar la investigación.
En un sitio de WordPress en producción, repite la petición que falla mientras compruebas una página que funciona correctamente y el área de administración. Un fallo aislado en una ruta requiere un rollback más acotado que un problema que afecta a PHP, la base de datos o todas las peticiones. Documenta la fecha y hora exactas, la URL o transacción afectada, el último estado correcto conocido y cada cambio realizado durante el diagnóstico. Ese registro permite distinguir una reparación reproducible de una desaparición temporal del síntoma.
Qué no debes hacer
No reinicie repetidamente la base de datos como la única solución. Limpia la evidencia y puede interrumpir las escrituras mientras la misma carga se reconstruye inmediatamente.
Cómo verificar la reparación
- El uso de la conexión máxima se mantiene por debajo de un umbral de seguridad documentado.
- Representative uncachéd peticiones completas sin errores de conexión.
- Las consultas lentas y el tráfico abusivo se controlan o eliminan.
Que el síntoma visible desaparezca no es suficiente. Cierra la incidencia solo cuando la acción original que fallaba, el recorrido de negocio relacionado y los registros relevantes confirmen que el problema ha desaparecido.