Solución de problemas de latencia alta de E/S de disco: Guía paso a paso para Linux

La latencia alta de E/S de disco tiene una sensación muy específica. SSH aún se conecta, la CPU no está al máximo, pero cada comando que toca archivos se cuelga por un momento. Una aplicación web se pausa mientras escribe sesiones. Una consulta de base de datos que normalmente regresa rápido comienza a esperar en el almacenamiento. La máquina parece viva, pero se siente como si estuviera caminando por el barro.

El truco es evitar adivinar. "El disco está lento" puede significar un dispositivo de bloques saturado, intercambio excesivo (swap), una unidad defectuosa, un trabajo de respaldo ruidoso, un volumen de red sobrecargado o una base de datos haciendo lecturas aleatorias porque falta un índice. El mismo síntoma puede provenir de causas muy diferentes.

Comprendiendo las métricas de E/S de disco

Antes de sumergirse en la solución de problemas, es vital comprender las métricas clave que indican un problema de E/S. La latencia alta es el síntoma principal, pero necesitamos puntos de datos de apoyo para confirmar la gravedad y el origen del problema.

Indicadores clave de contención de E/S

• Latencia alta (await): El tiempo promedio, en milisegundos, para que se completen las solicitudes de E/S. Esto incluye el tiempo de espera en la cola y el tiempo de servicio. Lo que se considera "alto" depende del almacenamiento y la carga de trabajo; compárelo con la línea base normal del sistema cuando sea posible.
• Utilización alta (%util): Cuando esta métrica se acerca al 100%, el dispositivo está saturado y no puede manejar más solicitudes de manera eficiente.
• Cola alta (avgqu-sz): Un tamaño de cola promedio grande significa que muchos procesos están esperando a que el disco se libere.

Paso 1: Verificación inicial de salud del sistema con iostat

La utilidad iostat (parte del paquete sysstat) es la piedra angular para monitorear la utilización del dispositivo y las estadísticas de rendimiento. Proporciona datos históricos y actuales sobre la CPU y la E/S del dispositivo.

Para obtener un recuento continuo del rendimiento de E/S, ejecute iostat con un intervalo (por ejemplo, cada 2 segundos):

sudo iostat -dxm 2

Analizando la salida de iostat -dxm

Concéntrese específicamente en las columnas de estadísticas del dispositivo (bandera x):

Columna	Descripción	Implicación de valor alto
r/s, w/s	Lecturas/Escrituras por segundo (IOPS)	Los valores altos indican una alta demanda de rendimiento.
rkB/s, wkB/s	Kilobytes leídos/escritos por segundo	Mide el volumen de rendimiento.
await	Tiempo de espera promedio (ms) para solicitudes de E/S (tiempo de servicio + tiempo de cola)	Indicador principal de latencia alta.
%util	Porcentaje de tiempo que el dispositivo estuvo ocupado atendiendo solicitudes	Cerca del 100% indica saturación.

Escenario de ejemplo: Si /dev/sda muestra un tiempo await de 150 ms y %util al 98%, ha confirmado un cuello de botella severo de E/S en ese disco.

Consejo: Use la bandera -x para estadísticas extendidas y -m para informar en megabytes, que a menudo es más claro que kilobytes (-k).

Paso 2: Identificando el proceso culpable con iotop

Una vez que iostat confirma latencia alta en un dispositivo específico (por ejemplo, /dev/sda), el siguiente paso crucial es determinar qué proceso está generando esa carga. La utilidad iotop, que refleja la funcionalidad del comando top pero se centra en la actividad de E/S, es esencial aquí.

Si iotop no está instalado, instálelo primero:

# Debian/Ubuntu
sudo apt update && sudo apt install iotop

# RHEL/CentOS/Fedora
sudo yum install iotop  # o dnf install iotop

Ejecute iotop con privilegios de root, mostrando solo los procesos que están haciendo E/S activamente:

sudo iotop -oP

• -o: Muestra solo procesos que están haciendo E/S activamente.
• -P: Muestra procesos, no hilos individuales.

Examine la salida, prestando atención a las columnas IO_READ e IO_WRITE. Los procesos listados en la parte superior están consumiendo el mayor ancho de banda del disco. Los culpables comunes incluyen servidores de bases de datos (MySQL, PostgreSQL), utilidades de respaldo, scripts de rotación de registros o sistemas que escriben agresivamente en el espacio de intercambio.

Interpretando la salida de iotop

iotop muestra el uso total de disco para cada proceso. Si ve una sola aplicación dominando la utilización del disco (por ejemplo, un script de respaldo ejecutándose a 50 MB/s mientras la latencia aumenta), ha encontrado la causa inmediata.

Paso 3: Inmersión profunda con pidstat

Mientras que iotop muestra la E/S agregada por proceso, pidstat puede proporcionar un contexto histórico detallado sobre las operaciones de E/S iniciadas por PIDs específicos, lo cual es útil para problemas intermitentes o de larga duración.

Para monitorear las estadísticas de E/S (lectura y escritura de bloques) para todos los procesos cada 5 segundos durante 5 iteraciones:

sudo pidstat -d 5 5

Las métricas clave en la salida -d incluyen:

• kB_rd/s: Cantidad de datos leídos del disco por segundo por la tarea.
• kB_wr/s: Cantidad de datos escritos en el disco por segundo por la tarea.
• kB_ccwr/s: Cantidad de datos escritos en el espacio de intercambio (c=escritura cancelada/confirmada).

Si las lecturas y escrituras aumentan para el mismo proceso cada vez que los usuarios reportan pausas, tiene una pista útil. pidstat es especialmente útil cuando iotop muestra un pico corto y luego se limpia antes de que pueda leerlo.

Paso 4: Diagnosticando la sobrecarga de memoria (uso de intercambio)

La actividad alta de intercambio a menudo se manifiesta como latencia alta de E/S de disco porque el sistema se ve obligado a usar el disco físico lento como RAM virtual. Use el comando free para verificar la presión de memoria:

free -h

Si la memoria usada está cerca de la memoria total, y el valor de intercambio usado está aumentando rápidamente, el sistema tiene falta de memoria, y la latencia de E/S es un síntoma secundario del intercambio.

Resolución para la sobrecarga:

1. Identifique los procesos que consumen mucha memoria usando top o htop.
2. Aumente la RAM del sistema si es posible.
3. Ajuste las aplicaciones para que usen menos memoria.

También verifique vmstat mientras ocurre el problema:

vmstat 1

Las columnas si y so muestran la actividad de entrada y salida de intercambio. Los valores distintos de cero ocasionales no son automáticamente una crisis. La actividad sostenida mientras el sistema está lento es una señal más fuerte. La columna de CPU wa también es útil: una espera de E/S alta significa que las tareas están pasando tiempo bloqueadas en el almacenamiento en lugar de ejecutarse en la CPU.

Paso 5: Empareje el dispositivo con el sistema de archivos

iostat reporta dispositivos de bloques: sda, nvme0n1, dm-0, md0, etc. Los registros de su aplicación generalmente mencionan rutas: /var/lib/mysql, /var/log, /home, /data. Antes de culpar al disco equivocado, mapee la ruta al dispositivo.

df -hT /var/lib/mysql
findmnt /var/lib/mysql
lsblk -f

Esto importa en hosts con LVM, RAID por software, volúmenes en la nube o puntos de montaje separados. Puede ver latencia alta en dm-0, pero el dispositivo de respaldo real podría ser un volumen EBS, una matriz mdraid o un dispositivo de mapeo cifrado. Si el sistema de archivos ocupado está en almacenamiento de red, las herramientas de disco local solo cuentan parte de la historia. También necesitará verificar NFS, iSCSI, métricas de volumen en la nube o el dispositivo de almacenamiento.

Paso 6: Busque pistas del kernel y hardware

Cuando la latencia es alta pero el rendimiento no, verifique si hay errores de almacenamiento. Un disco defectuoso o un controlador propenso a reinicios puede hacer que el sistema se arrastre incluso con E/S modesta.

dmesg -T | egrep -i 'error|reset|timeout|nvme|scsi|blk_update|i/o error'
journalctl -k --since "hace 30 minutos"

Para discos físicos, los datos SMART pueden ser útiles:

sudo smartctl -a /dev/sda

Para dispositivos NVMe:

sudo nvme smart-log /dev/nvme0

No sobreinterprete un campo SMART de forma aislada. Diferentes proveedores exponen diferentes contadores. Pero los sectores reasignados, los errores de medios, los tiempos de espera de comando repetidos o los errores de E/S del kernel merecen atención inmediata. Si el disco respalda una base de datos de producción, deje de tratarlo como un ejercicio de ajuste y muévase hacia redundancia, conmutación por error o reemplazo.

Paso 7: Separe los problemas de ancho de banda de los problemas de latencia

Dos incidentes pueden mostrar "disco lento" mientras necesitan diferentes correcciones.

Un respaldo secuencial podría empujar wkB/s alto y %util alto. Eso es un problema de ancho de banda. Limitar el respaldo, moverlo fuera de las horas pico, usar respaldos incrementales o escribir en un volumen diferente puede ayudar.

Una base de datos con índices faltantes podría mostrar un rendimiento modesto pero await doloroso, muchas lecturas pequeñas y retrasos de consulta visibles para el usuario. Eso es a menudo un problema de E/S aleatoria y forma de consulta. Arrojar más ancho de banda puede ayudar menos que agregar el índice correcto o reducir el conjunto de trabajo.

Use esta guía rápida:

• rkB/s o wkB/s altos, %util alto, trabajo grande obvio: busque lecturas/escrituras masivas.
• r/s o w/s altos, await alto, rendimiento más bajo: busque muchas operaciones aleatorias pequeñas.
• Actividad de intercambio alta, wa alto, memoria libre baja: trate la presión de memoria como la causa raíz.
• Latencia alta con errores del kernel: trate la salud del almacenamiento como la causa raíz.

Paso 8: Verifique el contexto a nivel de aplicación

Las herramientas del sistema le dicen quién está tocando el almacenamiento. No siempre le dicen por qué.

Para bases de datos, verifique los registros de consultas lentas y las métricas de búfer/caché. Un proceso de MySQL en la parte superior de iotop puede ser normal durante un respaldo, malo durante el tráfico pico o esperado después de un reinicio mientras el grupo de búfer está frío. PostgreSQL puede estar haciendo autovacío, escrituras de punto de control o una consulta que se derrama al disco. MongoDB puede estar compactando, construyendo índices o leyendo un conjunto de trabajo que ya no cabe en RAM.

Para servidores web y trabajadores de aplicaciones, busque tormentas de registros. Un registro de depuración dejado habilitado puede crear escrituras síncronas constantes. Una dependencia fallida también puede crear registros de error repetidos, que luego crean presión de disco, lo que luego empeora el incidente original.

Para contenedores, recuerde que el proceso ruidoso puede aparecer bajo containerd, dockerd o un sistema de archivos superpuesto. Use también herramientas a nivel de contenedor:

docker stats
docker ps --format 'table {{.ID}}\t{{.Names}}\t{{.Status}}'

En nodos de Kubernetes, compare la E/S a nivel de host con la ubicación del pod. Un solo pod escribiendo intensamente en un emptyDir, hostPath o volumen persistente local puede hacer que los pods no relacionados en el mismo nodo parezcan no saludables.

Causas comunes y estrategias de remediación

Una vez que se identifica la fuente, aplique la corrección adecuada:

1. Respaldo o trabajos de mantenimiento

Síntoma: Alta utilización de E/S coincidiendo con trabajos programados (por ejemplo, trabajos cron). Remediación: Reprograme los trabajos grandes de E/S, limítelos si la utilidad lo soporta, o mueva la salida temporal a un volumen diferente. Por ejemplo, rsync --bwlimit, ionice y los límites de respaldo nativos de la base de datos pueden reducir el radio de explosión.

2. Consultas de base de datos ineficientes

Síntoma: Los procesos de la base de datos (por ejemplo, mysqld) son los principales consumidores en iotop. Remediación: Optimice las consultas mal indexadas que fuerzan escaneos completos de tabla, lo que lleva a lecturas aleatorias masivas.

3. Registro excesivo

Síntoma: Los procesos de registro de aplicaciones o del sistema escriben grandes cantidades de datos. Remediación: Revise los niveles de registro de la aplicación. Considere almacenar en búfer los registros o usar una solución de registro remoto (como Syslog o el stack ELK) para reducir las escrituras locales en disco.

4. Falla o mala configuración del disco

Síntoma: Tiempos await extremadamente altos que no se correlacionan con un alto rendimiento, o patrones extraños de lectura/escritura. Esto puede indicar hardware defectuoso o configuración incorrecta de RAID. Remediación: Verifique los datos SMART (smartctl) para la salud del disco. Si usa RAID, verifique el estado de la matriz.

5. Sistema de archivos u opciones de montaje

Síntoma: La latencia aparece alrededor de cargas de trabajo intensivas en metadatos: crear muchos archivos pequeños, eliminar directorios, rotar registros o desempaquetar archivos.

Remediación: Verifique el tipo de sistema de archivos, las opciones de montaje, el uso de inodos y el comportamiento del diario. Un sistema de archivos lleno, inodos agotados o un volumen de aprovisionamiento delgado casi lleno pueden parecer un problema de latencia de E/S desde el lado de la aplicación.

df -h
df -ih
findmnt -o TARGET,SOURCE,FSTYPE,OPTIONS

Si el uso de inodos está al 100%, eliminar un archivo gigante no ayudará. Necesita eliminar muchos archivos pequeños o mover esa carga de trabajo a un diseño de sistema de archivos diseñado para ello.

Mejores prácticas para monitoreo proactivo

Prevenir los cuellos de botella de E/S es mejor que solucionarlos reactivamente. Implemente monitoreo continuo:

• Establezca alertas: Configure herramientas de monitoreo para alertar sobre cambios sostenidos en la latencia del disco, profundidad de cola, espera de E/S, llenura del sistema de archivos y contadores de errores. Use umbrales que coincidan con su clase de almacenamiento y carga de trabajo en lugar de copiar un número universal.
• Línea base de rendimiento: Sepa cómo se ve la latencia de E/S "normal" para su carga de trabajo específica. Esto hace que las anomalías sean más fáciles de detectar.
• Comprenda el tipo de carga de trabajo: Los patrones de E/S aleatoria (comunes en bases de datos) causan una latencia mucho mayor que la E/S secuencial (común en transmisión de medios o lectura de archivos grandes).

Las mejores investigaciones de latencia de disco siguen reduciendo la pregunta: ¿qué dispositivo, qué sistema de archivos, qué proceso, qué carga de trabajo y qué cambio reciente? Una vez que tenga esa cadena, la solución suele ser más clara. Deja de ajustar aleatoriamente la configuración del kernel y comienza a cambiar el horario de respaldo, agregar memoria, reparar almacenamiento, corregir una consulta o mover una carga de trabajo ruidosa lejos de un disco compartido.