Monitorear recursos en Linux: top, htop, free y vmstat

Monitorear recursos en Linux no consiste solo en abrir una herramienta y mirar números. El valor real está en entender qué recurso se está agotando, qué proceso lo provoca, si el problema es puntual o sostenido, y qué síntomas aparecen antes de que el sistema empiece a fallar.

Un servidor puede ir lento por muchas razones: CPU saturada, memoria insuficiente, swap excesivo, disco lleno, I/O bloqueante, red saturada, demasiados procesos en espera o una combinación de varias. Por eso conviene monitorear recursos en Linux de forma proactiva, analizar el sistema por capas y no quedarse con una única métrica.

Este artículo se centra en monitorear recursos en Linux, desde un punto de vista práctico: cómo interpretar CPU, RAM, swap, disco, red, procesos y carga del sistema para detectar cuellos de botella reales.

Si quieres aprender más sobre Linux, revisa nuestra Guía completa de comandos Linux y nuestro Curso de Linux gratis , te ayudarán a dominar la terminal y a sacar el máximo provecho de este artículo.

Qué significa monitorear recursos en Linux

Los recursos principales de un sistema Linux son:

• CPU: capacidad de ejecutar trabajo.
• Memoria RAM: espacio rápido para procesos, caché y buffers.
• Swap: memoria de respaldo en disco cuando la RAM no alcanza.
• Disco: espacio disponible y velocidad de lectura/escritura.
• Red: tráfico entrante, saliente, errores y saturación.
• Procesos: unidades que consumen CPU, memoria, I/O o sockets.

El monitorear recursos en Linux no debería responder solo cuánto se está usando, sino preguntas más útiles:

• Qué recurso está limitando el sistema ahora mismo.
• Qué proceso o servicio está generando la presión.
• Desde cuándo ocurre.
• Si el consumo es normal para la carga actual.
• Si el problema requiere limpiar, limitar, reiniciar, escalar o investigar más.

Una lectura aislada puede engañar. Un 90% de RAM usada no siempre es un problema en Linux, porque el kernel usa memoria libre como caché. En cambio, un uso moderado de CPU junto con mucha espera de I/O puede explicar una aplicación lenta aunque el procesador parezca libre.

CPU: uso, saturación y espera

La CPU indica cuánto trabajo está ejecutando el sistema. Pero no basta con mirar un porcentaje total. Hay que distinguir varios tipos de tiempo:

• user: tiempo ejecutando código de aplicaciones.
• system: tiempo ejecutando código del kernel.
• idle: tiempo sin trabajo.
• iowait: tiempo esperando operaciones de disco o almacenamiento.
• steal: tiempo robado por el hipervisor en máquinas virtuales.

Un sistema con CPU alta en user suele tener aplicaciones haciendo cálculos, compresión, cifrado, compilaciones o tareas intensivas. Si el valor alto está en system, puede haber muchas llamadas al kernel, red, contenedores, filesystem, drivers o procesos generando demasiada actividad interna.

El caso más interesante es iowait. Si la CPU aparece poco usada pero el sistema se siente lento y el iowait es alto, el cuello de botella probablemente no es el procesador: es el disco, el almacenamiento remoto o una operación de entrada/salida bloqueante.

Para una vista rápida:

top

top

En la cabecera de top, la línea de CPU muestra estos porcentajes. Si necesitas una lectura más cómoda por núcleo:

htop

htop

Para una lectura puntual con estadísticas acumuladas:

mpstat 1

mpstat 1

Si mpstat no está instalado, normalmente pertenece al paquete sysstat.

Cómo interpretar síntomas de CPU

CPU alta sostenida no siempre es mala. Puede ser normal durante backups, builds, compresión de logs, tareas cron pesadas o procesamiento por lotes. El problema aparece cuando coincide con latencia, timeouts, colas crecientes o procesos críticos sin capacidad de responder.

Señales habituales de saturación de CPU:

• La carga media sube por encima del número de núcleos disponibles.
• Las aplicaciones responden lento aunque no haya errores visibles.
• Hay procesos al 100% durante largos periodos.
• La cola de ejecución crece.
• En máquinas virtuales, aparece mucho tiempo steal.

Una forma práctica de buscar consumidores:

ps aux --sort=-%cpu | head

ps aux --sort=-%cpu | head

Esto muestra los procesos que más CPU consumen en ese momento. Para investigar un proceso concreto:

pidstat -p PID 1

pidstat -p PID 1

La idea no es matar procesos de inmediato, sino entender si ese consumo corresponde a una tarea esperada o a un comportamiento anómalo.

Load average: la carga no es solo CPU

El load average suele verse con:

uptime

uptime

También aparece en top. Muestra tres valores: carga media durante 1, 5 y 15 minutos.

Una regla sencilla:

• En un sistema de 1 CPU, una carga de 1 significa que la CPU está ocupada de forma continua.
• En un sistema de 4 CPUs, una carga de 4 puede ser razonable.
• Si la carga supera mucho el número de CPUs durante varios minutos, hay procesos esperando.

Pero hay una trampa importante: en Linux, la carga media no incluye solo procesos esperando CPU. También puede incluir procesos en espera no interrumpible, normalmente relacionados con I/O de disco o almacenamiento.

Por eso, una carga alta con CPU baja suele apuntar a:

• Disco saturado.
• NFS o almacenamiento remoto lento.
• Procesos esperando lectura/escritura.
• Problemas con dispositivos de bloque.
• Backups, escaneos o tareas masivas de filesystem.

Para confirmar, hay que cruzar load average con CPU, iowait, I/O de disco y estado de procesos.

RAM: memoria usada no significa memoria perdida

En Linux, ver mucha RAM usada es normal. El kernel aprovecha memoria disponible para caché de disco y buffers. Esa memoria se puede liberar cuando una aplicación la necesita.

La herramienta básica para interpretar memoria es:

free -h

free -h

La columna más importante para una lectura rápida suele ser available, no free.

• free: memoria totalmente libre, sin uso.
• buff/cache: memoria usada para caché y buffers.
• available: memoria que el sistema puede entregar a aplicaciones sin entrar en problemas serios.

Un servidor con poca memoria free pero bastante available normalmente está sano. Un servidor con poca memoria available, swap creciendo y procesos lentos necesita atención.

Para ver procesos ordenados por memoria:

ps aux --sort=-%mem | head

ps aux --sort=-%mem | head

Para una vista interactiva:

top

top

Luego puedes ordenar por memoria dentro de top con la tecla M.

Síntomas de presión de memoria

La presión real de memoria suele verse en combinación:

• available muy bajo.
• Swap en uso creciente.
• Procesos que tardan en responder.
• OOM killer terminando procesos.
• Muchas pausas o latencia irregular.
• Alto uso de memoria por uno o varios servicios.

Para revisar si el kernel ha matado procesos por falta de memoria:

dmesg -T | grep -i -E 'out of memory|oom|killed process'

dmesg -T | grep -i -E 'out of memory|oom|killed process'

También puede revisarse con journalctl:

journalctl -k | grep -i -E 'out of memory|oom|killed process'

journalctl -k | grep -i -E 'out of memory|oom|killed process'

Si aparece el OOM killer, el sistema ya ha llegado a una situación crítica: no es solo RAM alta, sino falta real de memoria disponible.

Swap: útil como red de seguridad, mala como estado permanente

La swap permite mover páginas de memoria al disco. Es útil para evitar fallos puntuales, pero si el sistema depende constantemente de swap, el rendimiento puede caer mucho.

Puedes verla con:

free -h

free -h

También con:

swapon --show

swapon --show

El dato importante no es solo cuánta swap está usada, sino si aumenta durante la carga normal y si coincide con lentitud.

Un poco de swap usada no siempre es grave. Linux puede dejar páginas antiguas en swap aunque luego haya memoria disponible. Lo preocupante es un uso activo y sostenido: entradas y salidas constantes hacia swap, aplicaciones congeladas, alta latencia y disco trabajando sin parar.

Para observar actividad de swap e I/O:

vmstat 1

vmstat 1

En vmstat, las columnas si y so indican swap in y swap out. Si se mantienen por encima de cero durante mucho tiempo, el sistema está intercambiando memoria con el disco de forma activa.

Qué hacer si la swap se dispara

Antes de actuar, identifica el origen:

ps aux --sort=-%mem | head -20

ps aux --sort=-%mem | head -20

Después decide:

• Si hay una fuga de memoria, reiniciar el servicio puede ser una medida temporal.
• Si la carga creció de forma legítima, puede hacer falta más RAM.
• Si hay demasiados servicios en el mismo host, conviene separar o limitar.
• Si son contenedores, revisa límites de memoria y políticas de reinicio.

Vaciar la caché o desactivar swap sin entender la causa puede empeorar el problema.

Espacio en disco: no esperes al 100%

El espacio en disco afecta directamente a servicios, logs, bases de datos, gestores de paquetes y aplicaciones. Un filesystem lleno puede provocar errores de escritura, caídas de servicios y corrupción si ocurre en el peor momento.

Para ver uso de filesystems:

df -h

df -h

Presta atención a:

• /: raíz del sistema.
• /var: logs, caches, colas, bases de datos en muchas instalaciones.
• /home: datos de usuarios.
• /tmp: temporales.
• Particiones dedicadas a bases de datos, backups o contenedores.

No conviene esperar al 100%. En servidores, un 85-90% ya merece revisión, sobre todo si el crecimiento es rápido.

Para encontrar directorios grandes:

du -h --max-depth=1 /var | sort -h

du -h --max-depth=1 /var | sort -h

Para analizar de forma interactiva:

ncdu /

ncdu /

Si ncdu no está instalado, merece la pena tenerlo en servidores donde se investigan crecimientos de disco con frecuencia.

Inodos: el disco puede fallar aunque haya espacio

Un filesystem también puede quedarse sin inodos. Esto pasa cuando hay muchísimos archivos pequeños, por ejemplo sesiones, caches, colas o temporales.

Revisa inodos con:

df -i

df -i

Si los inodos están al 100%, el sistema no podrá crear archivos nuevos aunque df -h muestre espacio disponible.

I/O de disco: performance de almacenamiento

El I/O de disco mide lecturas, escrituras, esperas y saturación del almacenamiento. Es uno de los cuellos de botella más comunes y también uno de los más confundidos con problemas de CPU.

Para observar actividad general:

iostat -xz 1

iostat -xz 1

Parámetros útiles:

• %util: cuánto tiempo está ocupado el dispositivo.
• await: tiempo medio de espera de operaciones.
• r/s y w/s: lecturas y escrituras por segundo.
• rkB/s y wkB/s: volumen leído y escrito.

Un %util alto con await alto indica que las operaciones tardan. Si además hay iowait alto y carga elevada, el almacenamiento puede ser el cuello de botella.

Para ver qué procesos generan I/O:

iotop

iotop

O con herramientas de pidstat:

pidstat -d 1

pidstat -d 1

Síntomas de cuello de botella de disco

Algunos síntomas frecuentes:

• El sistema se congela por segundos.
• SSH entra, pero los comandos tardan.
• La CPU no está al máximo, pero la carga es alta.
• Bases de datos responden lento.
• Backups o rotaciones de logs coinciden con caídas de rendimiento.
• iowait sube de forma clara.

En estos casos, matar el proceso que más CPU consume puede no resolver nada. Hay que mirar quién está leyendo o escribiendo, contra qué disco, y si el patrón es normal.

Red: tráfico, errores y saturación

El monitoreo de red no es solo ver si hay conexión. En servidores, interesa saber si hay demasiado tráfico, retransmisiones, errores, conexiones acumuladas o un servicio escuchando donde no debería.

Para ver interfaces y contadores:

ip -s link

ip -s link

Para ver tráfico en tiempo real por interfaz:

sar -n DEV 1

sar -n DEV 1

Para una vista interactiva sencilla:

iftop

iftop

O:

nload

nload

Para sockets y servicios escuchando:

ss -tulpn

ss -tulpn

Para conexiones establecidas:

ss -tunap

ss -tunap

Cómo interpretar problemas de red

Un problema de red puede aparecer como lentitud de aplicación, timeouts o errores intermitentes. Antes de culpar al servicio, revisa:

• Si la interfaz está cerca de su límite.
• Si hay muchos errores o drops.
• Si hay demasiadas conexiones abiertas.
• Si el tráfico saliente es anormal.
• Si una IP o proceso concentra la actividad.

Los drops y errores se ven con:

ip -s link show INTERFAZ

ip -s link show INTERFAZ

Sustituye INTERFAZ por el nombre real, por ejemplo eth0, ens18 o enp0s3.

Si hay tráfico inesperado, conviene cruzar iftop, ss y los logs del servicio afectado.

Procesos que consumen recursos

Cuando un recurso está saturado, el siguiente paso es encontrar qué proceso lo provoca.

Para CPU:

ps aux --sort=-%cpu | head -20

ps aux --sort=-%cpu | head -20

Para memoria:

ps aux --sort=-%mem | head -20

ps aux --sort=-%mem | head -20

Para árbol de procesos:

pstree -ap

pstree -ap

Para ver detalles de un proceso:

ps -fp PID

ps -fp PID

Para archivos abiertos:

lsof -p PID

lsof -p PID

Para saber si un proceso está bloqueado o en qué estado se encuentra:

ps -o pid,ppid,stat,comm,wchan -p PID

ps -o pid,ppid,stat,comm,wchan -p PID

El campo STAT ayuda a interpretar:

• R: ejecutándose o listo para ejecutarse.
• S: durmiendo de forma interrumpible.
• D: espera no interrumpible, normalmente I/O.
• Z: proceso zombie.

Muchos procesos en estado D suelen apuntar a problemas de disco, filesystem, NFS o almacenamiento.

Pressure Stall Information: señales modernas de presión

En sistemas Linux recientes, Pressure Stall Information, o PSI, ayuda a ver si los procesos están perdiendo tiempo por falta de CPU, memoria o I/O.

Los archivos suelen estar en:

/proc/pressure/cpu
/proc/pressure/memory
/proc/pressure/io

/proc/pressure/cpu
/proc/pressure/memory
/proc/pressure/io

Puedes consultarlos así:

cat /proc/pressure/cpu
cat /proc/pressure/memory
cat /proc/pressure/io

cat /proc/pressure/cpu
cat /proc/pressure/memory
cat /proc/pressure/io

La información muestra porcentajes de tiempo en los que algunas tareas, o todas, estuvieron esperando por ese recurso.

Conceptos útiles:

• some: al menos una tarea estuvo bloqueada por ese recurso.
• full: todas las tareas no ociosas estuvieron bloqueadas.

PSI es especialmente útil en servidores con contenedores, workloads mixtos o problemas intermitentes. Puede mostrar presión aunque los promedios clásicos no parezcan dramáticos.

Por ejemplo, si /proc/pressure/io muestra valores altos, probablemente hay tareas esperando I/O aunque la CPU no esté saturada.

Método práctico para diagnosticar lentitud

Cuando un sistema Linux va lento, conviene seguir un orden. No empieces matando procesos ni limpiando archivos sin mirar.

1. Mira la carga general

uptime

uptime

Compara load average con el número de CPUs:

nproc

nproc

Si la carga es alta, todavía no sabes la causa. Solo sabes que hay procesos esperando.

2. Distingue CPU, memoria e I/O

top
free -h
vmstat 1

top
free -h
vmstat 1

Observa:

• CPU user/system/iowait.
• Memoria available.
• Swap activa.
• Procesos bloqueados.

3. Revisa disco

df -h
df -i
iostat -xz 1

df -h
df -i
iostat -xz 1

Esto responde si falta espacio, faltan inodos o el almacenamiento está lento.

4. Busca el proceso responsable

ps aux --sort=-%cpu | head
ps aux --sort=-%mem | head
pidstat 1

ps aux --sort=-%cpu | head
ps aux --sort=-%mem | head
pidstat 1

Si sospechas de I/O:

pidstat -d 1

pidstat -d 1

5. Revisa red si el problema afecta servicios externos

ss -tulpn
ip -s link

ss -tulpn
ip -s link

Si necesitas ver tráfico en vivo:

iftop

iftop

Casos comunes y cómo leerlos

CPU alta, memoria normal y disco normal

Probablemente hay una tarea intensiva de cálculo o muchos procesos compitiendo por CPU.

Revisa:

ps aux --sort=-%cpu | head -20

ps aux --sort=-%cpu | head -20

Si es un proceso esperado, puede requerir optimización, limitación, escalado o mover la tarea a otro horario. Si no es esperado, revisa logs, cron, despliegues recientes o posibles bucles.

Carga alta, CPU baja e iowait alto

Este patrón suele indicar cuello de botella de disco o almacenamiento.

Comprueba:

iostat -xz 1
pidstat -d 1

iostat -xz 1
pidstat -d 1

Busca backups, bases de datos, rotación de logs, sincronizaciones, antivirus, escaneos o procesos leyendo muchos archivos.

RAM available baja y swap activa

Hay presión de memoria. Revisa procesos grandes:

ps aux --sort=-%mem | head -20

ps aux --sort=-%mem | head -20

Y actividad de swap:

vmstat 1

vmstat 1

Si si y so se mantienen activos, el sistema está usando el disco como memoria de forma constante.

Disco con espacio libre, pero aplicaciones no pueden escribir

Revisa inodos:

df -i

df -i

Si los inodos están agotados, busca directorios con muchísimos archivos pequeños:

find /var -xdev -type f | cut -d/ -f2-4 | sort | uniq -c | sort -n | tail

find /var -xdev -type f | cut -d/ -f2-4 | sort | uniq -c | sort -n | tail

Usa este tipo de búsqueda con cuidado en sistemas grandes, porque puede ser costosa.

Red lenta solo para una aplicación

No asumas saturación general. Puede ser DNS, firewall, rutas, servicio remoto, demasiadas conexiones o límites de la aplicación.

Empieza por:

ss -tunap
ip -s link

ss -tunap
ip -s link

Si hay errores en la interfaz o muchas conexiones en estados raros, investiga por ahí. Si la red está limpia, revisa logs de aplicación y dependencias externas.

Herramientas útiles según el recurso

Para CPU:

top
htop
mpstat 1
pidstat 1

top
htop
mpstat 1
pidstat 1

Para memoria:

free -h
vmstat 1
ps aux --sort=-%mem

free -h
vmstat 1
ps aux --sort=-%mem

Para disco:

df -h
df -i
du -h --max-depth=1
ncdu

df -h
df -i
du -h --max-depth=1
ncdu

Para I/O:

iostat -xz 1
iotop
pidstat -d 1

iostat -xz 1
iotop
pidstat -d 1

Para red:

ip -s link
ss -tulpn
iftop
nload
sar -n DEV 1

ip -s link
ss -tulpn
iftop
nload
sar -n DEV 1

Para presión del sistema:

cat /proc/pressure/cpu
cat /proc/pressure/memory
cat /proc/pressure/io

cat /proc/pressure/cpu
cat /proc/pressure/memory
cat /proc/pressure/io

Conclusión

Para monitorear recursos en Linux, es necesario interpretar CPU, memoria, swap, disco, red, procesos y carga como partes de la misma historia. Un número aislado puede ser normal o crítico según el contexto.

La clave para monitorear recursos en Linux , es empezar por síntomas, cruzar métricas y localizar el recurso que está limitando el sistema. CPU alta, memoria llena, swap activa, disco saturado, red con errores o procesos bloqueados tienen soluciones distintas. Entender esa diferencia evita acciones impulsivas y ayuda a resolver incidencias con más precisión.

Si el sistema va lento, monitorear recursos en Linux es tu solución. La pregunta importante es: qué recurso está bajo presión, quién lo está consumiendo y desde cuándo.