Cuando un sistema va lento, el error más común es ir directamente a matar procesos o reiniciar servicios sin entender qué recurso está bajo presión. La metodología correcta es otra: primero identificas en qué dimensión está el cuello de botella —CPU, memoria, I/O de disco, red— y solo entonces bajas al detalle. Las herramientas que vamos a ver aquí son exactamente ese segundo nivel: después de que top o el load average te señalan que algo va mal, free, vmstat e iostat te dicen por qué.
Estas herramientas leen de /proc —/proc/meminfo, /proc/vmstat, /proc/diskstats— que es el sistema de archivos virtual donde el kernel expone su estado interno en tiempo real. No hay agente de monitoreo de por medio, no hay overhead significativo: son ventanas directas al contador del kernel.
¿Cuándo usarlas? Cuando tienes síntomas difusos: el sistema responde lento, la aplicación tiene latencia alta intermitente, los usuarios se quejan pero top no muestra un proceso claramente culpable. También son indispensables para establecer una línea base en un sistema sano, antes de que haya problemas.
Lo que se rompe si las interpretas mal es tu diagnóstico. El ejemplo clásico: ves free mostrar casi 0 bytes libres en la columna free y concluyes que el sistema se está quedando sin memoria. Eso es casi siempre incorrecto, y tomar decisiones basadas en esa lectura —agregar swap, matar procesos, escalar la máquina— es un error caro. La columna que importa es available, no free.
# Instalar sysstat (iostat, mpstat) si no está presente apt install sysstat # ── 1. MEMORIA ───────────────────────────────────────────────────────── free -h # La columna "free" casi siempre es pequeña: el kernel usa la RAM libre # como caché de páginas (page cache). Eso es correcto y deseable. # "available" es lo que realmente puede asignarse a nuevos procesos # sin necesidad de hacer swap: incluye la caché que el kernel puede # liberar si hace falta. # Para verlo en acción con una actualización periódica: watch -n 2 free -h # ── 2. VISIÓN GLOBAL EN TIEMPO REAL: vmstat ───────────────────────────── # El argumento '1' indica intervalo de 1 segundo. # La primera línea es el promedio desde el arranque — ignórala. vmstat 1 10 # Columnas clave: # r → procesos en cola esperando CPU (si > nº de CPUs, hay presión) # b → procesos bloqueados esperando I/O # swpd → memoria en swap (si sube mientras corres vmstat, hay problema) # wa → % de tiempo de CPU en I/O wait; >20% sostenido = cuello de botella en disco # us → CPU en userspace (tus procesos) # sy → CPU en kernelspace (syscalls, drivers) # id → CPU ociosa # st → CPU "robada" por el hipervisor (relevante en VMs) # ── 3. I/O POR DISPOSITIVO: iostat ───────────────────────────────────── # -x activa estadísticas extendidas; 1 es el intervalo en segundos iostat -x 1 5 # Columnas clave en la salida extendida: # %util → porcentaje del tiempo que el disco tiene trabajo pendiente; # cerca de 100% = disco saturado (no necesariamente cuello de # botella en SSDs con colas paralelas, pero sí en HDDs) # await → latencia media de las peticiones en ms (tiempo en cola + servicio) # r/s → lecturas por segundo # w/s → escrituras por segundo # rkB/s → throughput de lectura en kB/s # wkB/s → throughput de escritura en kB/s # ── 4. QUÉ PROCESO CONSUME EL I/O: iotop ────────────────────────────── # Requiere root; muestra consumo de I/O por proceso, como htop para disco apt install iotop iotop -o # -o (--only) filtra y muestra solo procesos con I/O activo en ese momento # ── 5. FLUJO DE DIAGNÓSTICO COMBINADO ────────────────────────────────── # Escenario: el sistema va lento, wa en vmstat está al 40% # Paso 1 — confirmar con vmstat que wa es sostenido: vmstat 1 5 # Paso 2 — identificar el disco bajo presión: iostat -x 1 5 # Si ves sda con %util=98 y await=120ms, ese es el disco. # Paso 3 — identificar el proceso responsable: iotop -o # Si ves 'postgres' escribiendo 80 MB/s, ya tienes el culpable. # Paso 4 — correlacionar con memoria (¿es falta de page cache?): free -h # Si "available" es bajo (<10% del total), el sistema no tiene # suficiente page cache para absorber las lecturas y va directo a disco.
Lo que está pasando en cada paso
free -h muestra tres filas: Mem, Swap y una línea de totales. La columna buff/cache agrupa el page cache (contenido de archivos leídos del disco, mantenidos en RAM para evitar releerlos) y los buffers del kernel. El kernel libera esa memoria automáticamente cuando un proceso la necesita: por eso available es siempre mayor que free. En el ejemplo, si available muestra 6G en un sistema con 8G de RAM, estás bien aunque free marque solo 200M.
vmstat 1 10 toma 10 muestras con intervalo de un segundo. El patrón que buscas es sostenido, no picos aislados. Un wa del 40% durante 5 segundos consecutivos es diagnóstico; un pico de 80% en una sola muestra puede ser ruido. La columna b (procesos bloqueados) y wa suben juntas cuando el cuello de botella está en I/O. Si r (procesos en cola de CPU) es alto pero wa es bajo, el problema está en CPU, no en disco, y iostat no te va a decir nada útil.
iostat -x 1 5 desagrega por dispositivo lo que vmstat muestra en aggregate. La métrica await es más informativa que %util en discos modernos: un SSD NVMe puede tener %util al 100% con latencia de 0.2ms y eso es perfectamente normal; un HDD con await de 200ms está saturado aunque %util no llegue al 100%. Fíjate también en la relación entre r/s+w/s y await: si las operaciones por segundo son moderadas pero la latencia es alta, el problema puede ser fragmentación o contención en el controlador, no throughput.
iotop -o cierra el círculo: una vez que sabes que el disco sda está saturado, necesitas saber quién lo está saturando. El flag -o es indispensable en producción porque sin él la pantalla está llena de procesos con I/O cero y es imposible leer. Si el proceso culpable es jbd2 (el journal de ext4), el problema no es una aplicación sino el propio sistema de archivos gestionando transacciones, lo que apunta a patrones de escritura muy pequeños y síncronos.
La secuencia vmstat → iostat → iotop no es arbitraria: vas de lo global a lo específico, y cada herramienta confirma o descarta la hipótesis que generó la anterior.
[Ubuntu]: iotop en Ubuntu 23.10+ puede requerir ajustar permisos de /proc si el kernel tiene hidepid; en Debian Bookworm el comportamiento por defecto no tiene esa restricción.
N° 91