Cómo monitorear RAM, CPU y disco en VPS Linux en tiempo real
Aprende a monitorear RAM, CPU y disco de un VPS Linux en tiempo real desde la terminal usando top, htop, vmstat, iostat y herramientas auxiliares.
Cuando un VPS empieza a ponerse lento, la primera pregunta siempre es la misma: qué está consumiendo recursos. Sin un panel gráfico, la terminal sigue siendo el lugar más rápido y preciso para responderla. Las herramientas correctas muestran en segundos si el cuello de botella es CPU, memoria, disco o red — y qué lo está provocando.
Este tutorial está dirigido a sysadmins y desarrolladores que administran VPS Linux por SSH y quieren dominar las herramientas nativas de monitoreo en tiempo real. Cubrimos top, htop, free, vmstat, iostat, df y du, con foco en leer los números correctamente — porque la mayoría de los errores de diagnóstico vienen de interpretar mal la salida, no de la falta de herramienta.
Tiempo estimado de ejecución: de 20 a 30 minutos para ejecutar todos los comandos y entender la salida de cada uno.
Requisitos previos
Necesitas un VPS con Linux (Ubuntu 22.04 LTS, Debian 12 o Rocky 9 sirven), acceso SSH con usuario sudo y unos 30 MB libres para instalar paquetes auxiliares. La mayoría de las herramientas ya viene en el sistema base; solo htop, iotop y sysstat requieren instalación.
Ubuntu 22.04+ / Debian 12 / Rocky 9 SSH + sudo htop, iotop, sysstat Instalando las herramientas auxiliares
Antes de empezar, instala los paquetes que no vienen por defecto. htop es la versión interactiva y coloreada de top, iotop muestra la E/S por proceso y sysstat aporta iostat, pidstat y sar.
Actualiza el índice de paquetes:
sudo apt updateEn sistemas Rocky/AlmaLinux sustituye por sudo dnf check-update. El índice tiene que estar actualizado para instalar versiones recientes.
Instala htop, iotop y sysstat:
sudo apt install -y htop iotop sysstatEn Rocky/AlmaLinux: sudo dnf install -y htop iotop sysstat. El paquete sysstat necesita habilitarse para recolectar datos históricos: sudo systemctl enable --now sysstat.
Monitoreando la CPU en tiempo real
La CPU es el recurso más obvio de leer, pero lo que mucha gente olvida es separar uso de proceso, uso de sistema (kernel) y I/O wait. La saturación por I/O wait se manifiesta como lentitud sin ningún proceso aparente consumiendo CPU.
Ejecuta top para ver el resumen general:
topLa primera línea muestra el load average a 1, 5 y 15 minutos. La tercera línea (%Cpu(s)) detalla: us (userspace), sy (kernel), id (idle), wa (I/O wait), st (steal time — tiempo robado por el hipervisor). Presiona 1 para ver cada vCPU por separado, P para ordenar por CPU, M por memoria, q para salir.
Para una visión más legible e interactiva, usa htop:
htophtop muestra barras coloreadas por vCPU, lista todos los procesos en árbol de padres/hijos (F5) y permite matar procesos con F9. Diferencia práctica: los colores indican el tipo de uso — verde es userspace, rojo es kernel, azul es low-priority. Un dominante rojo casi siempre indica problema (driver, syscalls excesivas, contención).
En entornos virtualizados, la columna st (steal time) muestra la CPU que el hipervisor le quitó a tu máquina para atender a otros tenants. Un steal time consistentemente por encima del 5% indica un nodo sobreasignado — es momento de pedir migración o cambiar de proveedor.
Monitoreando la memoria RAM
La RAM en Linux es el recurso peor interpretado. El kernel usa toda la memoria libre como caché para acelerar la E/S, así que un free bajo es el estado normal. El número que importa es available, no free.
Mira el uso actual de memoria:
free -hSalida típica en un VPS de 4 GB:
total used free shared buff/cache available
Mem: 3.8Gi 1.2Gi 180Mi 50Mi 2.5Gi 2.4Gi
Swap: 2.0Gi 0B 2.0Giused 1.2 GB y available 2.4 GB significa que los procesos consumen 1.2 GB y el kernel puede liberar otros 2.4 GB de caché bajo demanda. Salud excelente. Preocúpate cuando available baje a menos del 10% del total o el swap empiece a crecer.
Para seguir cambios en vivo:
watch -n 2 free -hwatch -n 2 re-ejecuta el comando cada 2 segundos. Útil para observar el comportamiento durante un deploy, build o carga sintética.
Para granularidad por tiempo, usa vmstat:
vmstat 1La primera línea es la media desde el boot — ignórala. Las siguientes salen cada 1 segundo. Observa si (swap in) y so (swap out): cualquier valor consistente por encima de cero indica presión real de memoria. Una columna r (procesos runnable) mayor que el número de vCPUs durante más de unos pocos segundos indica saturación de CPU.
El swap ocasional durante picos es tolerable. El swap creciente y continuo (so > 0 sostenido) degrada el rendimiento dramáticamente porque el disco es órdenes de magnitud más lento que la RAM. Considera ampliar el plan o identificar un proceso con fuga de memoria.
Monitoreando el uso de disco
El disco tiene dos dimensiones: espacio ocupado (capacidad) y velocidad de E/S (throughput). Cada una tiene su herramienta dedicada.
Mira el espacio ocupado por filesystem:
df -hMuestra cada punto de montaje con total, usado, disponible y porcentaje. Presta atención a / (raíz) y /var (logs, bases de datos). Un filesystem por encima del 85% pide limpieza; por encima del 95% es emergencia — muchos servicios dejan de escribir para evitar corrupción.
Para encontrar quién está ocupando espacio, usa du:
sudo du -h --max-depth=1 /var | sort -hLista cada subdirectorio de /var con su tamaño total, ordenado de menor a mayor. Repite descendiendo en los mayores. Sustituye /var por el directorio de interés. La flag --max-depth=1 evita un escaneo recursivo completo.
Para E/S en vivo, usa iostat del paquete sysstat:
iostat -xz 1-x muestra estadísticas extendidas, -z omite dispositivos con actividad cero. Métricas clave:
%util— porcentaje de tiempo que el disco está ocupado. Por encima del 80% sostenido indica saturación.await— latencia media en ms. Un SSD saludable se queda por debajo de 10ms; un HDD por debajo de 20ms.r/syw/s— operaciones de lectura y escritura por segundo.
Para ver qué proceso está generando E/S:
sudo iotop -oP-o muestra solo procesos con E/S activa, -P agrupa por proceso (en lugar de por thread). Útil para identificar al culpable cuando iostat muestra el disco saturado pero no sabes quién está martillando.
Verificación
Para confirmar que todas las herramientas están operativas, ejecuta esta secuencia en una sola terminal:
free -h && uptime && df -h / && iostat -c 1 2 | tail -n 5Salida esperada: tres líneas de memoria, una línea de load average, una línea de disco raíz y dos muestras de CPU. Si algún comando reclama “command not found”, revisa la instalación de sysstat.
Para una prueba más robusta, abre htop en una ventana y en otra ejecuta:
yes > /dev/null &Deberías ver el proceso yes saturando una vCPU en htop. Mátalo con kill %1 en la misma terminal donde ejecutaste el yes.
Resolución de problemas
iotop falla con “Could not run iotop as non-root user”
Incluso con sudo, algunos entornos containerizados niegan el acceso al netlink taskstats. Usa pidstat -d 1 de sysstat como alternativa — muestra la E/S por proceso sin exigir capabilities especiales.
vmstat e iostat muestran contadores extraños en la primera línea
La primera línea siempre es la media desde el boot del sistema, no el estado actual. Ignórala y mira a partir de la segunda. Por eso es habitual ejecutar vmstat 1 5 (5 muestras) y descartar mentalmente la primera.
top muestra un proceso consumiendo 200% de CPU
No es un bug. top reporta el uso sumado entre cores, así que un proceso multithread en una máquina de 4 vCPU puede llegar al 400%. Presiona 1 para ver cada vCPU por separado y dimensionar correctamente.
kill -9 (SIGKILL) no permite que el proceso limpie archivos abiertos, libere locks o haga flush de buffers. Usa siempre kill <pid> (SIGTERM) primero y espera unos segundos. SIGKILL solo cuando SIGTERM falle — bases de datos y procesos con escritura en disco pueden corromper datos.
Próximos pasos
El monitoreo en tiempo real cubre el “ahora”, pero los problemas intermitentes exigen histórico. Algunas direcciones para profundizar:
- Configura
sar(desysstat) para retención de métricas — almacena datos de CPU, memoria y disco cada 10 minutos con 30 días de histórico por defecto. - Estudia
atopen modo daemon (atop -w archivo 60) — graba snapshots completos del sistema que puedes revisar después conatop -r archivo. - Aprende a leer
/proc/pressure/{cpu,memory,io}(PSI — Pressure Stall Information), que cuantifica cuánto está retrasando cada recurso a los procesos. - Para entornos mayores, considera un sistema de métricas con
node_exporterexportando a Grafana — da visualización gráfica y alertas.
Si vas a poner esto en producción, un VPS Hostini ya viene con vCPUs dedicadas (sin sobreasignación agresiva) y almacenamiento NVMe, lo que mantiene los números de %util y await saludables incluso bajo carga sostenida — facilitando el diagnóstico cuando algo realmente se sale del patrón.
Preguntas frecuentes
¿Cuál es la diferencia entre 'free' y 'available' en el comando free -h?
'free' es la memoria completamente ociosa — no está siendo utilizada por nada. 'available' es una estimación de cuánto puede entregar el kernel a procesos nuevos sin entrar en swap, contando la caché reclamable. En producción, mira 'available'; un 'free' bajo con 'available' alto es normal y saludable.
¿Por qué el load average aparece mayor que el número de CPUs?
El load average cuenta procesos en estado runnable o en I/O ininterrumpible, no solo CPU. Un load de 4.0 en una máquina con 2 vCPU puede ser 100% de CPU saturada o disco trabado. Cruza con 'top' (línea %CPU vs %wa) o 'vmstat 1' (columnas r y b) para distinguir.
iotop pide root incluso con sudo configurado, ¿por qué?
iotop usa taskstats del kernel, que exige CAP_NET_ADMIN. Incluso vía sudo, algunos entornos minimalistas (contenedores, ciertos kernels personalizados) lo bloquean. Alternativas: 'pidstat -d 1' del paquete sysstat o leer /proc/<pid>/io directamente.
¿Puedo dejar htop corriendo en segundo plano para registrar histórico?
No — htop es interactivo y no registra datos. Para histórico, usa 'sar' (de sysstat), 'atop' en modo daemon (-w archivo intervalo) o exporta métricas vía node_exporter. htop sirve para inspección en vivo, no para retención.
La caché de Linux está consumiendo toda mi RAM, ¿es un problema?
No. El kernel usa la RAM ociosa como caché de páginas y buffers para acelerar la E/S — ese espacio se devuelve instantáneamente cuando los procesos lo necesitan. Preocúpate solo si 'available' (no 'free') queda bajo y el swap empieza a crecer.
¿Por qué df -h muestra el disco lleno pero du no encuentra los archivos?
Probablemente sean archivos eliminados aún abiertos por procesos — el inode permanece asignado hasta que el proceso cierre el descriptor. Usa 'lsof +L1' para listar archivos con link count cero e identificar el proceso. Reiniciar el servicio dueño libera el espacio.