En el hosting compartido, WordPress puede ser rápido la mayor parte del día y detenerse cuando la cuenta alcanza los límites de CPU, memoria, E/S o procesos concurrentes. Una notificación de límite demuestra una restricción en un momento; no identifica la actividad de WordPress que consumió el recurso.
Correlacione la evidencia de cPanel con las solicitudes y trabajos antes de actualizar el plan o eliminar plugins.
Lea el historial de límites, no solo el uso actual
Abra el área de uso de recursos de cPanel y revise el historial de fallas. Dependiendo de la pila de hosting, puede mostrar CPU, memoria física, entrada/salida, IOPS, procesos de entrada y recuentos de procesos.
Registre las marcas de tiempo exactas, la duración y el límite alcanzado. Los gráficos actuales pueden parecer normales después de un breve incidente.
La terminología de hosting varía. Utilice la documentación del proveedor para comprender si una "falla" significa limitación, trabajo rechazado o simplemente alcanzar una asignación.
Relaciona el recurso con los síntomas probables
La limitación de la CPU puede alargar el trabajo de PHP y de la base de datos. El agotamiento de la memoria física puede poner fin a los procesos. Los límites de E/S pueden ralentizar las copias de seguridad, los análisis de malware y las escrituras de caché de gran tamaño. Los límites del proceso de entrada pueden poner en cola solicitudes web simultáneas.
Estas son hipótesis, no diagnósticos. Compare los registros de errores web/PHP y los tiempos de respuesta de los visitantes al mismo tiempo.
Una respuesta 508 o 503 puede ser evidencia útil. Captúrelo sin pedirles a los clientes que reproduzcan un pago fallido.
Encuentra lo que se ejecutó durante el evento
Revise los registros de acceso agrupados por URL, estado y volumen de solicitudes. Verifique el cron de WordPress, el Programador de acciones, las copias de seguridad y los registros de seguridad. Busque:
- ráfagas a
wp-login.phpo XML-RPC; - URL costosas de búsqueda o filtrado;
- muchas solicitudes AJAX sin caché;
- procesamiento o importación de imágenes;
- copias de seguridad y escaneos completos;
- tráfico de bots con cadenas de consulta únicas.
No bloquee un punto final únicamente porque aparece con frecuencia. Confirme si el tráfico es legítimo y si los controles de tarifas afectan las integraciones.
Verificar caché y comportamiento de PHP
Si las páginas públicas normalmente usan caché de página completa, una purga amplia puede enviar tráfico repentinamente a través de PHP. Inspeccione el estado de la caché durante la falla cuando los registros lo permitan.
Revise la versión de PHP, el límite de memoria y los registros de errores. Un memory_limit alto no reserva memoria, pero varios procesos grandes pueden exceder la asignación física de la cuenta.
Evite configurar la memoria PHP al límite total de la cuenta. WordPress, las tareas del servidor web y los trabajadores simultáneos necesitan un espacio compartido.
Reducir la demanda de recursos específicos
Haga coincidir la reparación con la falla:
- optimizar o almacenar en caché rutas lentas de PHP/base de datos para la CPU;
- reprogramar copias de seguridad y exploraciones de E/S;
- importaciones por lotes y procesamiento de imágenes;
- evitar corredores cron duplicados;
- páginas públicas seguras en caché;
- limitar el tráfico abusivo en la capa apropiada.
No aplique un cambio genérico de "deshabilitar todos los plugins" en producción. Utilice comparaciones por etapas o controladas para identificar la propiedad.
Cloudflare puede absorber el tráfico almacenable en caché y el abuso básico, pero no soluciona el proceso de pago lento de PHP ni una copia de seguridad local que consume E/S de disco.
Decida si el plan es realmente insuficiente
Después de eliminar el trabajo evitable, compare la demanda máxima normal con la asignación de hosting. Una tienda WooCommerce ocupada necesita capacidad PHP sin caché que un plan compartido pequeño puede no proporcionar.
Pregúntele al anfitrión qué recursos garantizan, trabajadores PHP y restricciones de la base de datos para cambios de plan superiores. Más almacenamiento por sí solo no resolverá la limitación de la CPU.
Conserve los gráficos de incidentes para que la decisión de actualización se base en la demanda repetida en lugar de en una colisión de respaldo.
Verificar hasta el próximo pico
Supervise las mismas métricas de cPanel, tiempos de respuesta de WordPress y acciones comerciales. Confirme que las fallas se detengan o se reduzcan materialmente y que las copias de seguridad, los formularios y los trabajos programados aún se completen.
Solicite una evaluación cuando se repitan eventos de límite, los registros sean difíciles de correlacionar o el proceso de pago se vea afectado. Comparta primero marcas de tiempo, capturas de pantalla y resúmenes de registros desinfectados; Las credenciales de hosting deben utilizar un canal seguro una vez acordado el alcance.