Devora Cloud · Blog
¿Tu sitio va lento? Cómo saber si falta procesador, memoria o es el código
Aprende a leer los gráficos de CPU y memoria, los reinicios y los logs (out of memory, Killed) para decidir entre añadir réplicas, subir de plan o corregir el código.
Un sitio lento es una de las quejas más comunes, y una de las más caras cuando la respuesta es a ojo. Mucha gente contrata un servidor más grande y descubre una semana después que el problema era una consulta sin índice. Otros pasan días optimizando código cuando a la aplicación simplemente le faltaba memoria.
La buena noticia: las señales suelen ser claras si sabes dónde mirar. En esta guía te mostramos cómo leer CPU, memoria, reinicios y logs para llegar a un diagnóstico, y cuándo la respuesta es escalar, subir de plan o tocar el código.
Primero, entiende qué miden los gráficos
En el panel de Devora Cloud, los gráficos de CPU y memoria muestran el porcentaje de la cuota de tu aplicación, no del servidor entero. En el plan Hobby, con 0,5 vCPU y 512 MB, un 100% de CPU significa que esos 0,5 vCPU están ocupados; en Pro, que lo están los 2 vCPU.
Mira siempre un periodo largo, como las últimas 24 horas. Un pico de unos segundos durante un despliegue es normal. Lo que importa es el patrón: uso alto durante mucho tiempo, crecimiento continuo o caídas bruscas seguidas de un reinicio.
El panel también avisa cuando la CPU o la memoria se mantienen por encima del 85% durante al menos tres minutos: un buen punto de partida para investigar.
Señal 1: falta procesador
Síntomas: la CPU se mantiene por encima del 80% durante largos periodos y las páginas se vuelven lentas justo en las horas de más tráfico. La memoria puede estar tranquila.
Qué hacer:
- En Hobby (0,5 vCPU): plantéate Pro (2 vCPU) o Enterprise (4 vCPU).
- En Pro o Enterprise: activa el autoescalado o añade una réplica de escala para repartir el tráfico entre copias.
- Antes de pagar más, comprueba si se hace trabajo pesado en cada petición, como generar informes, redimensionar imágenes o procesar archivos grandes.
Señal 2: falta memoria
Síntomas: la memoria supera el 90%, el contador de reinicios crece y los logs muestran mensajes como estos:
- Killed: el sistema terminó el proceso porque superó el límite de memoria.
- out of memory o JavaScript heap out of memory: el proceso (a menudo Node.js) llegó a su límite.
- El sitio se cae unos segundos y vuelve solo, varias veces al día.
Las réplicas no solucionan la falta de memoria: cada copia tiene el mismo límite que el plan. La salida suele ser el siguiente plan (Hobby 512 MB → Pro 1 GB → Enterprise 8 GB). Si la memoria sube sin parar hasta que el proceso muere, busca también fugas: cachés en memoria sin límite, listas que solo crecen, archivos enteros cargados de golpe.
Señal 3: el problema es el código o la base de datos
Síntomas: CPU y memoria bajas, sin reinicios, y aun así las páginas tardan. Aquí más servidor no ayuda: la aplicación está esperando algo.
- Consultas lentas: falta de índices, consultas dentro de bucles (el clásico N+1), tablas enteras cargadas para mostrar diez filas.
- APIs externas lentas: pagos, envíos o correo llamados durante la petición, sin tiempo límite.
- Archivos grandes servidos por la propia aplicación en lugar de URL firmadas de S3.
- Timeouts y errores 5xx en los logs, que muestran exactamente qué ruta sufre.
La solución está en el código: crear el índice, agrupar consultas, mover las tareas pesadas a segundo plano, añadir caché en Redis.
Tabla de diagnóstico rápido
| Lo que ves | Causa probable | Qué hacer |
|---|---|---|
| CPU alta durante horas, memoria normal | Falta procesador | Autoescalado o réplica (Pro/Enterprise), o un plan con más vCPU |
| Memoria por encima del 90%, reinicios, “Killed” | Falta memoria | Siguiente plan; buscar fugas |
| CPU y memoria bajas, páginas lentas | Código o base de datos | Índices, menos consultas, caché, tiempo límite en APIs |
| Subidas que fallan con QuotaExceeded | S3 lleno | Borrar archivos, paquete extra o plan mayor |
| Lento solo para quien está lejos | Distancia al servidor | Las apps corren en EE. UU.; en Brasil, la caché CDN de Devora acelera la entrega |
Deja que tu IA haga el análisis
Si usas el token de IA de Devora Cloud, no tienes que hacer esta lectura tú solo. Pregúntale a la IA que publicó tu sistema “¿por qué mi sitio va lento?”. Consulta las métricas de CPU y memoria de las últimas 24 horas, el número de reinicios de cada réplica, los logs de la aplicación y el uso de S3.
La respuesta llega con números, no con suposiciones —por ejemplo, “la memoria estuvo por encima del 90% y hubo reinicios con Killed en los logs”— y con una recomendación clara. La IA no cambia tu plan ni compra recursos por ti: esa decisión sigue en el panel.
Preguntas frecuentes
¿Añadir réplicas soluciona la falta de memoria?
No. Cada réplica tiene el mismo límite de memoria que el plan; si el proceso se queda sin memoria, le pasa en todas las copias. La solución es un plan con más RAM o reducir el consumo del código.
¿Qué significa “Killed” en los logs?
Que el proceso se terminó por usar más memoria que su límite. Suele aparecer junto con reinicios y una memoria cercana al 100% en el gráfico.
¿Un 100% de CPU en el panel significa que el servidor está saturado?
No necesariamente. El porcentaje es de la cuota de tu aplicación: 100% indica que usa toda la CPU de tu plan, no que la máquina entera esté llena.
¿La IA puede cambiar mi plan?
No. Analiza métricas y logs y recomienda. Los planes, las réplicas de pago y los paquetes de almacenamiento los contratas tú en el panel.