iostat e iotop: diagnóstico de cuellos de botella en el almacenamiento de Linux

Cuando un servidor Linux parece lento, el almacenamiento es uno de los primeros lugares donde hay que mirar. iostat te muestra si el disco está sobrecargado; iotop te muestra qué proceso está causando la carga. Usados juntos, responden a las dos preguntas que importan: ¿es el disco realmente el cuello de botella y, de ser así, qué lo está saturando? Esta entrada trata sobre la instalación, cómo interpretar los resultados (incluido dónde se encuentra la métrica de iostat %util se encuentra en el hardware moderno), y un flujo de trabajo para pasar del síntoma a la solución.

Instalación de iostat e iotop

iostat viene incluido en el paquete sysstat; iotop se distribuye por separado. Instale ambos:

# Debian/Ubuntu
sudo apt install sysstat iotop
 
# RHEL, AlmaLinux, Rocky, CentOS Stream
sudo dnf install sysstat iotop
 
# Arch
sudo pacman -S sysstat iotop

En Ubuntu, sysstat viene desactivado. Para recopilar datos en segundo plano para su posterior análisis con sar, edita /etc/default/sysstat, establezca ENABLED="true"y reinicie el servicio:

sudo systemctl restart sysstat

iotop debe ejecutarse como root. En RHEL 9 y versiones posteriores, el recuento de retrasos está desactivado por defecto, lo que deja el IO y SWAPIN . Actívalo con:

echo 1 | sudo tee /proc/sys/kernel/task_delayacct

Añade kernel.task_delayacct = 1 a /etc/sysctl.conf para que se mantenga tras los reinicios.

Lectura de la salida de iostat

Ejecute iostat con estadísticas ampliadas e ignore la primera muestra, que solo muestra promedios desde el arranque:

iostat -xz 2

La -x añade estadísticas ampliadas, -z oculta los dispositivos inactivos y la 2 actualiza cada dos segundos. Las columnas que importan:

• await: tiempo medio en milisegundos que tarda en completarse una solicitud de E/S, incluido el tiempo de cola. El dato más importante cuando los usuarios se quejan de lentitud.
• r/s y w/s: IOPS de lectura y escritura. En combinación con rkB/s y wkB/s , estos datos indican si la carga de trabajo es aleatoria (alto número de IOPS, bajo rendimiento) o secuencial (bajo número de IOPS, alto rendimiento).
• aqu-sz: profundidad media de la cola. En el caso de los discos duros (HDD), cualquier valor sostenido por encima de 1 significa que el disco no puede seguir el ritmo.
• %util: porcentaje de tiempo en el que el dispositivo tuvo al menos una E/S en curso. Útil en discos duros, engañoso en NVMe (véase más abajo).

Una referencia rápida de umbrales:

El %util

%util es la métrica a la que la mayoría de la gente recurre en primer lugar, y en NVMe resulta muy engañosa. El kernel cuenta %util como «cualquier E/S en curso en cualquier momento», lo cual está bien para un disco giratorio que procesa una solicitud a la vez, pero no tiene sentido para los dispositivos NVMe que gestionan miles de solicitudes en paralelo a través de colas de hardware. Una unidad NVMe puede estar al 100 % %util mientras funciona al 5 % de su capacidad real.

En NVMe, confía r_await, w_await, y aqu-sz en su lugar. Si r_await se mantiene por debajo de 1 ms y la profundidad de la cola está cómodamente por debajo de la profundidad de la cola de hardware del dispositivo (a menudo 1024 o más), la unidad no está realmente saturada, independientemente de lo que %util diga.

Para una visualización rápida de NVMe en MB/s en lugar de kB/s:

iostat -xm 1

Para una recopilación a largo plazo, puedes correlacionar los datos con los registros de la aplicación más tarde:

iostat -x -t 5 720 > /var/log/iostat.log

Eso toma muestras cada 5 segundos durante una hora. sar El mismo paquete sysstat te proporciona datos equivalentes con almacenamiento histórico persistente y es la mejor opción para la monitorización continua.

Confirmación con CPU iowait

Si iostat muestra estrés en el almacenamiento, compruébalo con la %iowait columna del resumen de la CPU en la parte superior de la misma salida. Un valor sostenido %iowait por encima del 15-20 % junto con un alto await confirma que el cuello de botella es el almacenamiento. Si %iowait es alto pero await parece normal, ejecuta vmstat 1 y comprueba el si y so . Una actividad de intercambio distinta de cero significa que tienes un límite de memoria y que el tráfico del disco es de paginación, no de E/S de la aplicación.

Interpretación de los resultados de iotop

Una vez que iostat confirma un cuello de botella en el almacenamiento, iotop te indica qué proceso es el responsable. Empieza con:

sudo iotop -o

La -o oculta los procesos inactivos, dejando solo aquellos que realizan E/S de forma activa. Las columnas a tener en cuenta:

• DISK READ / DISK WRITE: rendimiento en tiempo real por proceso. Identifica a los grandes consumidores evidentes.
• E/S: porcentaje de tiempo que el proceso está bloqueado en E/S. Un proceso que escribe solo 50 kB/s puede mostrar un 99 % de E/S si está realizando pequeñas fsync() . Esta columna es más importante que el rendimiento bruto.
• SWAPIN: porcentaje de tiempo de espera en páginas de intercambio. Un valor distinto de cero aquí significa que el sistema está paginando y que tu «problema de almacenamiento» es en realidad un problema de memoria.

Para aplicaciones multihilo (MySQL, PostgreSQL, cargas de trabajo Java), agrupa los hilos de nuevo en procesos con -P, y suma -a para acumular los totales desde que se inició iotop:

sudo iotop -oPa

La -a es el truco para detectar cargas de trabajo intermitentes, como los trabajos de copia de seguridad, que solo se ejecutan durante unos segundos cada vez y que, de otro modo, serían difíciles de detectar en una vista en tiempo real.

Para el registro automático durante las ventanas nocturnas cuando nadie está mirando:

sudo iotop -botqq -d 10 > /var/log/iotop.log

Esto escribe una instantánea no interactiva cada 10 segundos. Combínalo con las marcas de tiempo de tus tareas de copia de seguridad o cron para encontrar al culpable a posteriori.

Un flujo de trabajo de diagnóstico

La mayoría de las investigaciones sobre E/S de disco siguen el mismo camino:

1. iostat -xz 2 confirmar que el disco es realmente el cuello de botella. Consulte await, aqu-szy %iowait. Si estos son normales, el problema no está en el almacenamiento y deberías buscar en otro lugar completamente distinto.
2. iotop -oPa para encontrar el proceso que genera la carga. Presta más atención a la columna de E/S que a la de rendimiento. Los principales culpables suelen ser los programas que realizan muchas escrituras síncronas pequeñas, no los que mueven más bytes.
3. lsof -p <pid> para ver qué archivos está manipulando ese proceso. Esto suele identificar el tipo de carga de trabajo de inmediato: un registro de escritura anticipada de la base de datos, un archivo de registro de la aplicación, un punto de montaje de copia de seguridad, un archivo temporal.

Dos patrones que conviene conocer.

Si ves subprocesos del kernel como jbd2/... (ext4 journal) o txg_sync (ZFS) en la parte superior de los escritores de iotop, estos están respondiendo a escrituras de otros procesos, no iniciándolas. El proceso del espacio de usuario que genera el tráfico del diario es la causa real; sigue investigando.

En un VPS, un await con bajo %util es la clásica señal de «vecino ruidoso». Otro inquilino está monopolizando el almacenamiento compartido y tu E/S se está acumulando en la cola del hipervisor, no en tu disco virtual. Puedes confirmarlo, pero no solucionarlo desde dentro del sistema invitado; la solución es bien escalar el problema al proveedor o bien cambiarte a un servidor con almacenamiento aislado.

Solución de cuellos de botella comunes de E/S

Una vez que se sabe qué está afectando al disco, las soluciones suelen ser sencillas.

Quita prioridad a la E/S no crítica. ionice Coloca un proceso en la clase de programación inactiva, donde solo utiliza el ancho de banda del disco cuando nada más lo necesita:

ionice -c 3 -p <pid>
sudo ionice -c 3 rsync -a /data /backup

La primera forma cambia un proceso en ejecución; la segunda inicia uno nuevo que ya está en la clase de inactividad. Dentro de iotop, puedes cambiar la prioridad de un proceso en ejecución de forma interactiva pulsando i.

Traslade las cargas de trabajo intensivas a un almacenamiento más rápido. Si iostat muestra un disco SATA sobrecargado por escrituras de la base de datos y hay un NVMe inactivo en el mismo equipo, reubique el directorio de datos de la base de datos. La diferencia de varios órdenes de magnitud en IOPS hace que esta sea la solución más eficaz disponible.

Configure el programador de E/S adecuado. Los kernels modernos tienen una configuración predeterminada razonable, pero vale la pena comprobarlo. Para NVMe y SSD, configure el programador en none. El dispositivo gestiona las colas en el hardware mejor que el núcleo:

echo none > /sys/block/nvme0n1/queue/scheduler

Para los discos duros que gestionan cargas de trabajo mixtas, mq-deadline es la opción habitual.

Monta con noatime. Cada lectura actualiza la marca de tiempo de último acceso del archivo por defecto, generando una escritura por cada lectura. En sistemas de archivos con mucha lectura, esto supone una E/S innecesaria. Añade noatime a las opciones de montaje en /etc/fstab:

UUID=... /data ext4 defaults,noatime 0 2

Ajusta el writeback para escrituras en ráfagas. En servidores con mucha RAM, los umbrales predeterminados de páginas sucias permiten que la caché de páginas acumule gigabytes de datos sin escribir, para luego vaciarlos en una sola operación de gran tamaño. Reduce los umbrales en /etc/sysctl.conf para suavizar esto:

vm.dirty_ratio = 10
vm.dirty_background_ratio = 5

El disco en sí no suele ser el problema. Cuando iostat muestra un alto número de IOPS y un bajo rendimiento, la carga de trabajo está realizando E/S aleatorias en datos que podrían ser secuenciales, o ejecutando muchas escrituras pequeñas que podrían agruparse. Analice la aplicación antes de culpar al hardware.

Si está ejecutando cargas de trabajo que consumen mucho almacenamiento en un servidor donde la red puede superar al disco, los servidores dedicados con tecnología NVMe de FDC le ofrecen el margen necesario para aplicar el ajuste anterior de forma productiva.