Aplicación lenta en el servidor: CPU steal, memoria e I/O

"El servidor está lento" no es un diagnóstico, es un síntoma. Detrás hay un recurso saturado (CPU, memoria, disco, red) o un límite impuesto desde fuera (CPU compartida con vecinos, cuota del contenedor). Y a veces no es el servidor: es una consulta sin índice o un bucle que bloquea el proceso.

Cambiar de plan sin medir es el error más caro en este escenario. La investigación de abajo va de lo más barato a lo más difícil, con los comandos que separan cada causa.

¿Cómo saber si es CPU, memoria, disco o red?#

Empieza por lo que la máquina dice de sí misma. En un servidor Linux, tres comandos responden casi todo:

top            # línea "%Cpu(s)": us, sy, wa (I/O) y st (steal)
vmstat 1 5     # r (cola de CPU), si/so (swap), wa, st, una línea por segundo
free -m        # memoria disponible y uso de swap

Léelo así:

• us/sy altos y cola r mayor que el número de núcleos: CPU saturada.
• si/so distintos de cero: el sistema está usando swap, es decir, falta memoria.
• wa alto: procesos esperando al disco.
• st alto: CPU robada por el hipervisor (siguiente sección).
• Todo bajo y la aplicación lenta: el tiempo se va esperando algo externo (base de datos, API, red) o dentro de código que no usa mucha CPU.

¿Qué es el CPU steal y qué es el overselling?#

En un VPS, tu "servidor" es una máquina virtual, y varias VM comparten los mismos núcleos físicos. El campo steal de Linux es, según la página proc_stat del manual, el tiempo dedicado a otros sistemas operativos cuando se ejecuta en un entorno virtualizado: tu VM tenía trabajo que hacer y el hipervisor le dio el núcleo a otra.

El overselling (u overcommit) ocurre cuando el proveedor asigna a los clientes más vCPU que núcleos físicos tiene, apostando a que no todos los usan al mismo tiempo. Es una práctica común en planes baratos, pero cuando los vecinos usan CPU a la vez, tu steal sube. Algunos tipos de instancia también son explícitamente "burstable": AWS describe las instancias T como una CPU base con capacidad de ráfagas por encima de ella, no como CPU completa todo el tiempo.

Cómo diagnosticarlo:

1. Ejecuta vmstat 1 60 durante la lentitud y mira la columna st.
2. Si st se mantiene alto de forma repetida mientras tu CPU de usuario (us) es baja, el cuello de botella no es tu código.
3. Repite en horarios distintos. Un steal que desaparece de madrugada y vuelve por la noche apunta a un vecino ruidoso.

La corrección no está en tu aplicación: es cambiar de tipo de instancia (CPU dedicada), de región o de proveedor. Antes, abre un ticket con los números, que es la prueba que pide el soporte.

¿Qué es el throttling de CPU en un contenedor?#

En contenedores hay otra causa que parece steal pero no lo es. El contenedor recibe una cuota de CPU: en cgroup v2, el archivo cpu.max define cuánto tiempo de CPU puede usar el grupo por período (el valor por defecto es max 100000, sin límite). Al pasar la cuota, el kernel pausa los procesos hasta el siguiente período, y eso se ve como picos de latencia.

Dentro del contenedor, revisa:

cat /sys/fs/cgroup/cpu.max    # ej.: "50000 100000" = medio núcleo
cat /sys/fs/cgroup/cpu.stat   # nr_throttled y throttled_usec creciendo = throttling

Si nr_throttled crece mientras la aplicación está lenta, el límite de CPU del contenedor es el cuello de botella. Sube el límite o reduce el trabajo por petición. A diferencia del steal, aquí la solución está en tus manos.

¿La aplicación se queda sin memoria?#

La falta de memoria suele manifestarse de dos formas. La primera es lentitud por swap: el sistema mueve páginas al disco y todo se ralentiza, y vmstat muestra si/so activos. La segunda es que el proceso muere: el kernel termina procesos que superan el límite del contenedor y el contador oom_kill de memory.events sube.

cat /sys/fs/cgroup/memory.events   # oom_kill > 0: algo se terminó por falta de memoria

Una señal clásica es que la aplicación se vuelve más lenta con el paso de las horas y vuelve a la normalidad tras un reinicio: eso es una fuga de memoria o una caché sin límite. Aprende a medir el pico y dimensionar con margen en ¿Cuánta RAM y CPU necesita mi aplicación?.

¿Y si la CPU y la memoria tienen margen?#

Entonces el tiempo se va esperando. Los sospechosos, por orden de frecuencia:

1. Base de datos: consulta sin índice, N+1 (una consulta por cada elemento de una lista) o una conexión abierta en cada petición. Activa el log de consultas lentas de tu base de datos y mide el tiempo de cada una.
2. API externa: una llamada lenta a un tercero dentro del camino de la petición. Ponle timeout y, cuando puedas, sácala del camino crítico.
3. Disco: wa alto en vmstat, o iostat -x 1 (paquete sysstat) con el disco saturado. Los logs excesivos, los archivos temporales grandes y las bases de datos en discos lentos son los culpables típicos. La página del manual advierte que el valor de iowait es poco fiable, así que úsalo como pista, no como prueba.
4. Distancia: latencia de red entre la aplicación y la base de datos, o entre el servidor y el usuario. La aplicación y la base de datos deben estar en el mismo datacenter, y el contenido estático gana mucho con un CDN.

¿Cómo encontrar el cuello de botella dentro del código?#

En Node.js, el síntoma típico es el event loop bloqueado: un bucle pesado o una operación síncrona impide que el proceso atienda cualquier otra petición. El módulo perf_hooks mide ese retraso directamente:

// event-loop.js: imprime el retraso del event loop cada 5 segundos
const { monitorEventLoopDelay } = require("node:perf_hooks");

const h = monitorEventLoopDelay({ resolution: 20 });
h.enable();

setInterval(() => {
  const ms = (ns) => (ns / 1e6).toFixed(1);
  console.log(
    `event loop: media=${ms(h.mean)} ms p99=${ms(h.percentile(99))} ms máx=${ms(h.max)} ms`,
  );
  h.reset();
}, 5000);

Los valores vienen en nanosegundos, por eso la división entre 1e6. Con la CPU libre, un p99 de cientos de milisegundos indica código que bloquea el loop. En Python, el equivalente es un profiler como cProfile ejecutándose unos minutos bajo carga. El patrón es el mismo: mide a dónde va el tiempo antes de cambiar una sola línea.

Registra también la duración de cada petición en los logs. Con la duración y la ruta en cada línea, el cuello de botella suele aparecer solo, y leer los logs de la aplicación es el siguiente paso cuando los números por sí solos no lo explican.

¿Cuál es el orden correcto para investigar?#

1. Confirma el síntoma con un número: tiempo de respuesta por ruta, no "parece lento".
2. top/vmstat: CPU, steal, swap, iowait.
3. Cgroup (cpu.stat, memory.events) si estás en un contenedor.
4. Base de datos y APIs externas: consultas lentas y timeouts.
5. Profiler en el código.
6. Solo entonces cambia de plan o de servidor, y vuelve a medir para confirmar que mejoró.

Si el steal es la causa, la elección entre VPS y plataforma cambia: consulta VPS o nube: qué conviene a tu proyecto para comparar lo que aísla cada modelo.

Cómo hacerlo en Square Cloud#

En Square Cloud, las aplicaciones se ejecutan en contenedores aislados, siempre encendidos, sin cold start ni modo de suspensión, en un datacenter Tier 3 en Nueva York con procesadores Intel Dual Xeon de 3 GHz o más y almacenamiento NVMe. Sigues los logs en tiempo real en el panel, la CLI, VS Code y la app móvil, y las métricas de CPU, RAM y red se registran cada 5 minutos y se guardan durante 24 horas.

Si la falta de memoria es la causa, cambias la RAM de cada aplicación en la configuración o por la API. La RAM del plan es un pool compartido entre tus aplicaciones, con un mínimo de 256 MB por aplicación en segundo plano y 512 MB por aplicación web. El vCPU del plan es el techo por entorno, calculado a partir de la RAM asignada.

El hosting de bases de datos (desde el plan Standard) está en el mismo datacenter que las aplicaciones, con alrededor de 1 ms de latencia media, lo que saca la distancia entre aplicación y base de datos de la lista de sospechosos. En los planes Pro y Enterprise, la analítica muestra la latencia en p50, p95 y p99, además de los logs HTTP, para que encuentres las rutas lentas.

No hay autoscaling: tú decides cuándo subir la RAM o repartir la carga con load balancing, poniendo el mismo dominio personalizado en varias aplicaciones (desde el plan Standard). Mira los recursos de logs, métricas y escalado.