Latencia de E/S de disco con iostat -x: r_await, w_await, aqu-sz y por qué %util engaña en SSD y RAID

Qué es

iostat -x (sysstat) añade columnas extendidas por dispositivo a la vista básica de rendimiento de lectura y escritura. Su manual define los campos más útiles para analizar la latencia: r_await y w_await son el tiempo medio, en milisegundos, que tardan en atenderse las peticiones de lectura y de escritura, incluido el tiempo en cola y el tiempo de servicio; aqu-sz es la longitud media de la cola de peticiones emitidas al dispositivo; %util es el porcentaje del tiempo transcurrido durante el cual se emitieron peticiones de E/S al dispositivo.

Los nombres de las columnas dependen de la versión de sysstat. Las versiones antiguas (por ejemplo, sysstat 10.x en RHEL 7) muestran avgqu-sz, avgrq-sz (en sectores) y svctm, un campo en el que su propio manual ya advertía de que no se debía confiar; las versiones actuales los llaman aqu-sz y areq-sz/rareq-sz/wareq-sz (en kilobytes) y ya no documentan svctm. Que aparezca o no una columna combinada await junto a r_await/w_await en la salida de -x también varía según la versión, así que los scripts deben identificar los campos por el nombre de la cabecera y no por la posición de la columna.

Por qué importa

Separar await en lectura y escritura es importante porque ambas pueden diferir enormemente en el mismo dispositivo (por ejemplo, escrituras secuenciales pero lecturas aleatorias en un disco giratorio), y un único promedio combinado lo oculta. aqu-sz cuenta las peticiones pendientes en el dispositivo, incluidas las que se están atendiendo. En un dispositivo que atiende una sola petición a la vez, un valor que se mantiene por encima de aproximadamente uno significa que las peticiones se están encolando; los SSD, NVMe y conjuntos RAID atienden muchas peticiones en paralelo, por lo que allí un aqu-sz más alto es normal y solo importa cuando sube junto con await. %util era una señal fiable de saturación en un dispositivo que solo puede atender una petición a la vez; el manual afirma claramente que la saturación del dispositivo se da cuando está cerca del 100 % en dispositivos que atienden peticiones en serie, pero que en dispositivos que las atienden en paralelo (los arreglos RAID y los SSD modernos son sus propios ejemplos) este valor no refleja sus límites de rendimiento, ya que un dispositivo así puede estar al 100 % (sin estar nunca inactivo) y encontrarse muy lejos de su techo real de rendimiento o de latencia.

Cómo aplicarlo

• Consulta primero r_await/w_await para ver la latencia que percibe el usuario, valorándola según el rango esperado del propio almacenamiento y no con un único número para dispositivos distintos.
• Observa si la tendencia de aqu-sz sube a lo largo de muestras consecutivas junto con un await creciente, valorándolo según lo que sea normal para ese dispositivo.
• En SSD, NVMe y RAID, trata %util como un indicador de actividad, no como un porcentaje de saturación; un dispositivo rápido al 100 % con un await bajo no es el cuello de botella.
• Toma muestras repetidas (iostat -xz 1 10) en lugar de una sola; el primer informe abarca el tiempo transcurrido desde el arranque, no el intervalo de muestreo (-y lo omite).
• Limítate a un solo dispositivo (iostat -x <device> 1) cuando de la lista completa surja un candidato.

Trampas

• Alertar solo con %util en almacenamiento moderno y pasar por alto un encolamiento real que aqu-sz habría mostrado.
• Comparar await entre dispositivos distintos (almacenamiento en red, NVMe local, un RAID en plena reconstrucción) como si un mismo umbral valiera para todos.
• Olvidar que la primera fila tras iniciar iostat es un promedio desde el arranque, no el estado actual.