El servidor se me congeló de golpe. No era un kernel panic, ni un OOM killer, ni un servicio caído. Era algo más sutil y más molesto: el CPU estaba ocioso, pero el sistema se sentía lentísimo.

Lo descubrí cuando ejecuté top y vi algo que no esperaba: 77.1% id (CPU idle / ocioso) y un Load Average disparado en 6.8. Si el CPU está libre, ¿por qué el sistema está saturado?

Acá va lo que aprendí sobre el estado D (Uninterruptible Sleep), el Load Average y el comportamiento del kernel cuando el almacenamiento colapsa.

El Problema

Todo empezó con fstrim, el comando que le dice al disco qué bloques ya no se usan para que los SSD puedan gestionarlos mejor.

En Linux, los procesos normalmente están en dos estados:

• R — Running: ejecutándose activamente.
• S — Interruptible Sleep: durmiendo, esperando un evento (tecla, red, señal).

Pero cuando un proceso solicita una lectura o escritura directa al almacenamiento, entra en estado D: Uninterruptible Sleep.

Qué significa: el proceso le entregó el control al driver del disco y al hardware. El sistema operativo no puede interrumpirlo bajo ninguna circunstancia, ni siquiera con kill -9.

El impacto: el proceso queda congelado en RAM, sosteniendo recursos y archivos abiertos, hasta que el disco responda con un “completado”.

Diagnóstico

El síntoma era confuso:

top
Load Average: 6.8
%Cpu(s):  2.3 us,  0.2 sy,  0.0 ni, 77.1 id, 22.6 wa,  0.0 si,  0.0 st

Si el CPU está al 77% ocioso, ¿por qué el Load Average está en 6.8?

Resulta que el Load Average no mide solo procesos usando CPU. Mide el número de tareas en la cola de ejecución del planificador. Y Linux mete ahí tanto a los procesos en R como a los atrapados en D.

Cuando el almacenamiento colapsa:

• Las solicitudes de lectura/escritura se acumulan en la cola del controlador del disco.
• Decenas de hilos de distintas aplicaciones entran en D esperando su turno.
• El planificador del kernel ve una fila enorme de procesos “en espera” y dispara el Load Average a 4, 6 o más de 10.

Mientras tanto, el CPU no tiene instrucciones que procesar porque todas están bloqueadas esperando datos. Se va a descansar. Eso explica el 77.1% id.

La Solución

No hubo una línea de comando mágica. La solución fue identificar la causa raíz: fstrim había saturado el bus de datos.

Para diagnosticarlo, usé herramientas que miden el I/O directamente, sin depender de malinterpretar el Load Average:

# Ver qué proceso está bloqueado en estado D
ps aux | awk '$8 ~ /D/ {print $0}'
Ver el uso de I/O por proceso
iotop -oP
Ver la saturación de la cola del disco
iostat -xm 1 5

Una vez confirmado que el disco estaba al límite, la solución dependió del caso:

• Si era un comando pesado (fstrim, rsync, dd): programarlo en ventanas de bajo tráfico.
• Si era un fallo de disco (IOPS bajos, alta latencia): reevaluar el almacenamiento.
• Si era saturación de aplicaciones: agregar colas, cache o limitar concurrencia.

En mi caso, bastó con mover el fstrim a un horario de mantenimiento.

Lecciones Aprendidas

El Load Average alto con CPU ocioso no es un misterio; es una señal clara de blocked I/O. Aprendí a leerlo bien:

• No confundir Load Average con utilización de CPU. Son métricas distintas.
• El estado D es ininterrumpible por diseño. No lo intentes matar; esperá o resolvé el origen del bloqueo.
• wa (I/O Wait) es la métrica oculta. Es el tiempo que el CPU estuvo limpio pero no pudo hacer nada porque dependía del almacenamiento.
• Todo almacenamiento tiene un límite. IOPS y ancho de banda no son infinitos; cuando se llenan, la cola se estira y el kernel empieza a retener procesos.

Anatomía del colapso del disco

Un diagrama ayuda:

flowchart LR
    A[Aplicaciones] --> B[Peticiones R/W]
    B --> C[Cola del Kernel]
    C -->|¡Cuello de botella!| D[Disco Saturado]
    D --> E[Latencia alta]
    E --> F[Procesos en estado D]
    F --> G[Load Average alto + CPU idle]

Esto no es teoría; lo viví con fstrim. Un comando de mantenimiento rutinario saturado en un VPS con disco de bajo IOPS generó un bloqueo en cascada.

Cierre

Un Load Average alto con CPU libre no es un bug de Linux. Es el sistema operativo diciéndote: “Tengo muchos procesos vivos, pero todos están esperando algo que no llega”. En este caso, el almacenamiento.