Entrevista de Linux: ¿Cómo diagnosticarías un iowait alto?

Enunciado y contexto

Un host Linux reporta que %iowait aumenta del 3% al 38%, mientras que la latencia p99 de la aplicación se duplica y la utilización total de CPU permanece en 30%. Explica cómo distinguirías entre un dispositivo de bloques local, NFS u otro almacenamiento remoto, memory reclaim, hypervisor steal y una discrepancia entre las mediciones del host y del servicio.

Comienza con el significado y los límites de iowait en /proc/stat. Luego construye evidencia con vmstat, iostat, pidstat, PSI, estados de tareas, métricas de cgroup y registros del kernel. Los números son datos prácticos ficticios, no umbrales de alerta universales.

Qué está evaluando el entrevistador

Límite de contabilización (accounting boundary)

El candidato debe saber que iowait es un campo de contabilización de la CPU, no la utilización del dispositivo ni el tiempo total que todas las tareas pasan esperando. La programación multinúcleo hace que la atribución sea imperfecta.

Capas de evidencia

Una respuesta sólida avanza desde los promedios del host hacia evidencia por CPU, hilo, cgroup, dispositivo y latencia de cola del negocio (business tail latency), explicando qué cambia cada observación.

Rutas de espera

La respuesta debe separar E/S de bloques local, NFS/FUSE, RPC de base de datos, memory reclaim y hypervisor steal. Cada ruta tiene diferente evidencia y mitigación.

Cierre seguro

El candidato preserva la evidencia, elige una mitigación de bajo riesgo vinculada a la hipótesis y verifica la recuperación en lugar de reiniciar o aumentar la concurrencia por defecto.

Preguntas para aclarar primero

• ¿El iowait proviene del host o de un contenedor? /proc/stat del host y las métricas de cgroup del servicio pueden cubrir poblaciones diferentes.
• ¿Está alta cada CPU, o solo una? Los promedios ocultan la afinidad, NUMA y la saturación local inducida por cuotas.
• ¿La solicitud está esperando en un archivo, un dispositivo de bloques o un RPC de red? Las esperas de NFS, bases de datos y HTTP tienen diferentes evidencias.
• ¿Comparten p99 y las señales de E/S exactamente la misma ventana de tiempo? Alinea el muestreo, despliegues, copias de seguridad y cambios de tráfico.
• ¿Están aumentando el swap, los major faults, el PSI de memoria o el steal time?
• ¿Puedes leer las pilas (stacks) de los hilos y los archivos de cgroup? Utiliza el principio de menor privilegio durante la investigación en producción.

Una respuesta de 30 segundos

“Un treinta y ocho por ciento de iowait es una pista, no una prueba de falla de disco. Alinearía las ventanas del host, del servicio y de p99, y luego inspeccionaría por CPU mpstat, vmstat r/b, PSI de CPU/E/S/memoria, cuota de cgroup y steal time.

Si las colas de dispositivos, la latencia, las lecturas/escrituras de procesos y los errores del kernel son anormales en conjunto, investigaría el almacenamiento de bloques. Si los hilos esperan en rutas de NFS o del sistema de archivos mientras los dispositivos locales están sanos, inspeccionaría los montajes, la red y el servidor. Si el PSI de memoria, el swapping y los major faults aumentan, investigaría el working set; si el steal aumenta, investigaría el hipervisor. Verificaría la latencia de cola del negocio, los hilos en espera, el PSI y el recurso después de la mitigación.”

Respuesta detallada paso a paso

Paso 1: Definir el límite de iowait

El iowait de /proc/stat es la contabilización del tiempo de CPU asociado con la espera de la finalización de E/S. Otra tarea puede ejecutarse mientras una tarea espera, y la contabilización multinúcleo no siempre puede atribuir la espera con precisión. Un iowait bajo no descarta esperas en almacenamiento remoto o en el kernel; un iowait alto no prueba una falla de disco.

Paso 2: Verificar datos por CPU y colas

mpstat -P ALL 1 10
vmstat 1 10
cat /proc/loadavg

Un r sostenido con CPUs ocupadas respalda el encolamiento de CPU; un b sostenido apunta a esperas ininterrumpibles. Los datos por CPU, la afinidad, la cuota de cgroup y el throttling pueden revelar '30% global, saturado localmente'.

Paso 3: Medir el tiempo estancado con PSI

for r in cpu io memory; do echo "[$r]"; cat /proc/pressure/$r; done

El PSI some mide el tiempo en que al menos parte del trabajo está estancado; full mide el tiempo en que todo el trabajo que no está inactivo está estancado. avg10/60/300 muestran tendencias. Lee los archivos de presión del cgroup objetivo para separar la presión del servicio del ruido del host.

Paso 4: Localizar hilos y puntos de espera

ps -eLo state,pid,tid,wchan:32,comm --sort=state
pidstat -d -p ALL 1 10

Agrupa por estado R/D, comando, cgroup y wchan. Si está permitido, inspecciona /proc/PID/stack para hilos representativos. Un wchan es solo una ubicación de suspensión actual; exige correlación temporal, PSI y latencia del negocio antes de catalogarlo como la causa.

Paso 5: Entrar en el subsistema relevante

iostat -xz 1 10
dmesg -T | tail -200
cat /proc/meminfo | egrep 'Swap|Dirty|Major'

Para dispositivos de bloques, inspecciona await, profundidad de cola, throughput y errores. Para NFS/FUSE, inspecciona montajes, retransmisiones, red y salud del servidor. Para memoria, correlaciona el PSI de memoria, swap y major faults. Las esperas por RPC de base de datos o HTTP requieren trazado (tracing) y métricas de pools; iostat no puede verlas por sí solo.

Paso 6: Mitigar y verificar

Captura instantáneas de hilos, PSI, dispositivos y registros, luego aplica rate-limit, pausa el trabajo por lotes, cambia a una réplica sana o repara un montaje de acuerdo con la evidencia. No envíes repetidamente kill -9 a tareas en estado D; normalmente necesitan salir de la espera ininterrumpible antes de procesar la señal. Verifica conjuntamente p99, errores, conteos de R/D, PSI, latencia del recurso y backlog.

Respuesta modelo

“Un treinta y ocho por ciento de iowait es una pista, no una conclusión. Es una contabilización de CPU afectada por la programación multinúcleo, por lo que no lo calificaría de inmediato como una falla de disco. Alinearía el alcance y las ventanas de tiempo, luego inspeccionaría por CPU mpstat, vmstat r/b, PSI de CPU/E/S/memoria, cuota de cgroup y steal time.

Si los hilos en estado D y el PSI de E/S aumentan, wchan apunta a E/S de bloques y iostat muestra mayor latencia y colas, inspeccionaría el dispositivo, el sistema de archivos y los errores del kernel. Si los dispositivos locales están sanos pero los hilos se agrupan en esperas de NFS, inspeccionaría montajes, retransmisiones, la red y el servidor. Si el PSI de memoria, el swap o los major faults aumentan, controlaría el working set; si el steal aumenta, investigaría el hipervisor.

Pausaría el trabajo por lotes que amplifique la E/S, aplicaría rate-limit o cambiaría a una réplica sana mientras preservo la evidencia. La recuperación significa que el p99 del negocio y los errores, los procesos en espera R/D, el PSI, la latencia del recurso y el backlog regresan hacia la línea base, no simplemente que iowait caiga.”

Errores comunes

• Tratar iowait como utilización de disco; correlaciónalo con iostat y una línea base del dispositivo.
• Añadir CPU tan pronto como iowait sube; comprueba primero los datos por CPU, los estados R/D y el PSI.
• Descartar E/S porque iowait es bajo; inspecciona estados D, almacenamiento remoto y PSI de E/S.
• Llamar a cada estado D un problema de disco local; NFS, los sistemas de archivos y los controladores también pueden bloquearse.
• Mirar solo las métricas del host; el cgroup del servicio puede tener límites y presiones diferentes.
• Tomar una sola muestra; utiliza muestras continuas con marca de tiempo alineadas con la curva de solicitudes.
• Reiniciar o matar procesos de inmediato; preserva la evidencia y evalúa la seguridad de los datos.
• Esperar únicamente a que disminuya el iowait; verifica la latencia del usuario y las colas de recursos.

Preguntas de seguimiento

Pregunta de seguimiento 1: ¿Por qué puede ser alto el iowait mientras la utilización del disco es baja?

La espera puede estar en NFS, FUSE, una base de datos o un RPC de red, o el mapeo de dispositivos y las ventanas pueden diferir. Sigue el punto de espera del hilo, el trazado, el PSI de E/S, las señales de montaje y de red.

Pregunta de seguimiento 2: ¿Por qué puede ser bajo el iowait mientras las solicitudes están atascadas?

Las tareas pueden estar esperando en bloqueos (locks), pools, cuota de CPU, memory reclaim o RPC remoto. Compara estados R/D, pilas, PSI de CPU/memoria y latencia de dependencias; la contabilización de CPU no clasifica cada espera como iowait.

Pregunta de seguimiento 3: ¿Cómo saber si un contenedor tiene su propia presión de E/S?

Lee el io.pressure del cgroup objetivo, las estadísticas de E/S y los eventos de throttling, luego compáralos con el /proc/pressure/io del host y el p99 del servicio. Una alta presión en el host con baja presión en el servicio no implica que escalar el servicio vaya a ayudar.

Pregunta de seguimiento 4: ¿Se puede matar un hilo en estado D?

Puedes enviar una señal, pero normalmente no se puede procesar hasta que la espera ininterrumpible retorne. Captura la pila y el punto de espera, repara el dispositivo, montaje o controlador, y considera un reinicio solo después de que se confirmen la redundancia y la seguridad de los datos.

Pregunta de seguimiento 5: ¿Cómo configurarías alertas para iowait?

Evita un porcentaje universal. Combina iowait con PSI de E/S, latencia de almacenamiento local o remoto, recuentos de estados D, el SLO del negocio y la duración, calibrados con la línea base de la carga de trabajo.