Plesk informa un alto uso de PHP, pero el gráfico no revela si los visitantes, los bots, el cron, el administrador AJAX o una tarea de plugin ocuparon el grupo. Aumentar el recuento de procesos sin identificar la duración de la solicitud puede aumentar la presión sobre la memoria y la base de datos.
Utilice marcas de tiempo para conectar la métrica del panel a una URL y una pila PHP.
Definir la suscripción y el controlador afectados
Confirme el dominio, la suscripción, la versión de PHP y el controlador que se muestran en Plesk. Varios sitios pueden ejecutar diferentes grupos o compartir recursos del servidor.
Registre cuándo aumenta el uso y si el síntoma es CPU, memoria, procesos recursos o solicitudes en cola. Revise la vista del estado del hosting o del servidor en una ventana que contiene el incidente.
No cambie la configuración global de PHP cuando solo una suscripción se vea afectada.
Comparar registros de acceso y errores
Utilice los registros de dominio de Plesk durante el mismo período. Agrupe URL y códigos de estado frecuentes o de apariencia lenta. Los objetivos comunes de WordPress incluyen:
wp-cron.php;admin-ajax.php;- Rutas API REST;
wp-login.php;- Llamadas de carrito/checkout de WooCommerce;
- búsqueda y parámetros de archivo filtrados.
El recuento de solicitudes por sí solo está incompleto. Una llamada de importación larga puede consumir a un trabajador más que cientos de visitas a páginas almacenadas en caché.
Proteger los datos personales al exportar registros; Las cadenas de consulta pueden contener correos electrónicos o tokens.
Habilite el registro lento de PHP-FPM deliberadamente
Cuando el acceso al servidor y la política lo permiten, PHP-FPM puede registrar seguimientos de pila para solicitudes que exceden un umbral. Configúrelo para el grupo específico utilizando directivas compatibles con Plesk o la asistencia del proveedor.
Elija un umbral que capture el trabajo anormal sin registrar cada solicitud. Almacene registros fuera del acceso web público, restrinja permisos y desactive el diagnóstico después de recopilar suficiente evidencia.
No reinicie las piscinas casualmente en una tienda ocupada. Siga el proceso de solicitud/recarga admitido por la plataforma y planifique una reversión.
Correlacionar con la actividad de WordPress
Compare pilas lentas con rutas de temas/plugins de WordPress, programaciones cron y Programador de acciones. Una copia de seguridad, un análisis de malware o una importación de productos pueden explicar un estancamiento habitual.
Verifique el estado de acceso al caché de la página. Si una implementación o una actualización de stock purga el caché, el tráfico normal puede convertirse repentinamente en tráfico PHP.
Inspeccione las llamadas HTTP externas en pilas lentas. Un servidor de licencias o una conexión SMTP pueden retener un proceso incluso cuando la CPU local parece moderada.
Revisar la configuración del grupo con evidencia de memoria
Plesk puede permitir configuraciones como el modo de administrador de procesos, el número máximo de niños y los tiempos de espera de inactividad. Antes de aumentarlos, mida la memoria de proceso aproximada y el espacio libre total del servidor.
Más niños permiten más trabajo PHP concurrente pero pueden agotar la RAM, aumentar el intercambio y abrumar a MySQL. Muy pocos pueden poner en cola solicitudes legítimas incluso cuando la CPU sigue disponible.
Ajuste solo el grupo afectado y documente los valores anteriores. Los límites de hosting administrado pueden anular la configuración de suscripción.
Reducir la entrada PHP innecesaria
Ofrezca páginas públicas seguras desde la caché de páginas o CDN, excluyendo la cuenta, el carrito y el proceso de pago. Limite el tráfico de búsqueda o inicio de sesión abusivo mediante controles de seguridad adecuados.
Reemplace WP-Cron activado por visitantes con una tarea programada solo después de que se verifique el comando cron de Plesk. Escalone las copias de seguridad y los análisis lejos de los picos de tráfico.
No bloquee admin-ajax.php globalmente; Los formularios públicos, carritos y plugins pueden depender de acciones específicas.
Compare el tráfico público con la administración autenticada por separado. Una edición masiva de productos, un guardado de un constructor visual o una regeneración de medios pueden utilizar legítimamente una cantidad considerable de PHP durante un período corto. Si el sitio público se mantiene saludable, programe ese trabajo editorial en lugar de aplicar una restricción inicial que no lo afectará.
Verificar con el siguiente período comparable
Después de reparar la solicitud identificada o ajustar un límite de grupo medido, compare los procesos recursos, las colas, el tiempo de respuesta y la tasa de error. Confirme que los formularios, los trabajos programados y los flujos de pago autorizados aún funcionan.
Mantenga un breve registro de incidentes que vincule las marcas de tiempo, la solicitud, el propietario, el cambio y la evidencia. Esto hace que una recurrencia sea mucho más rápida de diagnosticar.
Solicite una evaluación cuando el registro lento no esté disponible, varios sitios compartan el cuello de botella o los cambios en el grupo pongan en riesgo el tráfico de comercio electrónico. Comience con gráficos de Plesk y extractos de registros desinfectados en lugar de credenciales.