Cómo saber si una cuenta de hosting alcanzó sus límites de recursos

Los límites de recursos del hosting aíslan las cuentas de un servidor compartido para que el consumo de un sitio no afecte a los demás. Si una página se vuelve lenta, responde de forma intermitente o muestra errores, el panel de CloudLinux permite comprobar si la cuenta alcanzó alguno de esos límites.

Un evento de límite no indica por sí solo que el plan sea insuficiente. Puede deberse a un pico legítimo, un robot, una tarea programada, una consulta lenta, un plugin defectuoso o malware. La clave es relacionar la hora del evento con lo que estaba ocurriendo en el sitio.

Cómo abrir Uso de recursos

  1. Ingresá a cPanel.
  2. Buscá Resource Usage, Uso de recursos o CPU and Concurrent Connection Usage.
  3. Abrí el resumen para comprobar si se registraron límites en las últimas horas.
  4. Ingresá a los detalles y seleccioná el período que incluye la falla.
  5. Compará las columnas o gráficos de uso, límite y fallas.

La función sólo aparece en servidores con CloudLinux cuando el proveedor la habilita. Los nombres y recursos visibles pueden cambiar según la versión y la configuración del plan.

Uso, límite y fallas

  • Usage: consumo observado durante el intervalo.
  • Limit: máximo asignado a la cuenta para ese recurso.
  • Fault: cantidad de veces que el consumo intentó superar el límite.

En este contexto, una falla no significa una vulnerabilidad de seguridad. Indica que CloudLinux aplicó el límite correspondiente. Observá el período completo: un pico aislado de pocos segundos no tiene el mismo impacto que fallas repetidas durante todo el día.

CPU o SPEED

Representa la capacidad de procesamiento disponible para la cuenta. Al alcanzar el límite, las solicitudes pueden ejecutarse más lentamente hasta que baje la carga.

Las causas frecuentes incluyen muchas visitas simultáneas, procesos PHP costosos, consultas de base de datos, tareas cron, generación de imágenes, backups y escaneos. Revisá qué proceso coincidió con el pico antes de desactivar funciones.

Memoria física o PMEM

Mide la memoria utilizada por los procesos de la cuenta. Si no hay suficiente memoria, una aplicación puede finalizar, responder con error o quedar intermitente.

Buscá plugins o extensiones con consumo elevado, importaciones, scripts que procesan grandes conjuntos de datos y demasiados procesos simultáneos. Aumentar el límite de memoria de PHP no aumenta necesariamente la memoria total asignada por el hosting.

I/O e IOPS

  • I/O: velocidad de lectura y escritura en disco.
  • IOPS: cantidad de operaciones de entrada y salida por segundo.

Un límite de I/O puede hacer que el sitio se sienta lento aunque la CPU no esté saturada. Backups, compresión de archivos, importaciones, cachés, escaneos y consultas con mucho acceso a disco son causas habituales.

NPROC y Entry Processes

  • NPROC: cantidad de procesos que puede ejecutar la cuenta.
  • Entry Processes (EP): solicitudes concurrentes que ingresan al entorno de la cuenta, por ejemplo procesos web dinámicos.

Al alcanzar estos límites, algunas solicitudes pueden esperar o ser rechazadas. Dependiendo de la configuración del servidor y la aplicación, el visitante puede ver un error temporal, incluso un mensaje del tipo “Resource Limit Is Reached”. Confirmá siempre el recurso señalado en el panel en lugar de atribuir el error sólo por su texto.

Inodos o cantidad de archivos

Algunos paneles también muestran el límite de inodos. Este valor cuenta archivos y directorios, no su tamaño. Cachés, sesiones, miniaturas y correo pueden acumular grandes cantidades de archivos pequeños.

Para distinguir este problema de una cuota en bytes, consultá cómo revisar el uso de disco en cPanel.

Síntomas orientativos

  • Lentitud sin error permanente: puede coincidir con CPU o I/O limitados.
  • Errores intermitentes durante picos: revisá EP, procesos y memoria.
  • Backups o importaciones muy lentos: compará CPU, I/O e IOPS.
  • No se pueden crear archivos: comprobá cuota de disco e inodos.
  • Fallas sólo en una tarea: revisá sus logs y requisitos específicos.

Estos síntomas no son un diagnóstico definitivo. Un error de aplicación, red, DNS, base de datos o firewall puede producir una experiencia similar.

Procedimiento para encontrar la causa

  1. Anotá la hora exacta, la URL y el mensaje observado.
  2. Seleccioná en Resource Usage un período que incluya varios minutos antes y después.
  3. Identificá qué recurso acumuló fallas, no sólo cuál mostró uso alto.
  4. Compará la hora con las estadísticas de visitas de cPanel.
  5. Revisá logs de errores, accesos, tareas cron y cambios recientes.
  6. Buscá procesos programados: backups, escaneos, importaciones o sincronizaciones.
  7. Aplicá una modificación por vez y observá el período siguiente.

Causas frecuentes y acciones

Tráfico legítimo

Activá caché correctamente, optimizá consultas y archivos, y evaluá un CDN. Si el consumo se mantiene aun después de optimizar, compará el plan con la demanda real.

Bots o ataques

Identificá rutas, agentes y frecuencia en los registros. Aplicá reglas específicas, límites de solicitudes o protección en el proxy. No bloquees rangos amplios sin verificar su propietario e impacto.

Plugins, temas o código

Revisá actualizaciones y errores. En un entorno de prueba, desactivá de forma controlada el componente sospechoso y medí nuevamente. No hagas pruebas destructivas directamente sobre el sitio productivo.

Tareas programadas y backups

Distribuí las tareas pesadas en horarios diferentes, evitá ejecuciones duplicadas y no conserves copias completas dentro de la misma cuenta más tiempo del necesario.

Base de datos

Buscá consultas lentas, tablas de registros demasiado grandes, sesiones vencidas y procesos repetitivos. Generá un respaldo antes de optimizar o eliminar datos.

Qué puede y qué no puede resolver un CDN

Un CDN puede reducir solicitudes y transferencia que llegan al servidor cuando sirve contenido desde su caché. No elimina por sí solo el consumo producido por el administrador, tareas cron, correo, consultas de base de datos o páginas dinámicas que no se almacenan en caché.

Cuándo optimizar y cuándo ampliar el plan

Primero corregí errores, malware, tareas duplicadas y configuraciones ineficientes. Luego medí durante un período representativo. Si el sitio optimizado alcanza límites con tráfico legítimo y recurrente, ampliar recursos puede ser la decisión adecuada.

No conviene aumentar recursos sin diagnóstico: si la causa es un proceso defectuoso, el cambio puede posponer el problema y permitir que consuma todavía más. Para comprender el aislamiento y funcionamiento general, consultá qué es CloudLinux en un hosting compartido.

Qué información enviar a soporte

  • Dominio y URL afectada.
  • Fecha, hora y zona horaria.
  • Captura del gráfico y recurso con fallas.
  • Mensaje o código de error completo.
  • Cambios realizados antes del incidente.
  • Pasos para reproducirlo.

Estos datos permiten distinguir un límite real de un problema de aplicación o infraestructura y reducen el tiempo de diagnóstico.

Documentación oficial