¿Disco lento en Linux? Cómo hallar cuellos de botella de IOPS

Qué sucede cuando tu disco colapsa bajo presión

Cuando una aplicación de base de datos o un servidor web comienza a responder con lentitud, la primera sospecha suele recaer sobre la falta de memoria RAM o el uso excesivo de la CPU. Sin embargo, en la gran mayoría de los casos, el verdadero villano invisible es el subsistema de almacenamiento. Los discos modernos, especialmente las unidades de estado sólido NVMe basadas en bus PCIe, consiguen realizar miles de operaciones por segundo. No obstante, cuando la concurrencia de procesos se dispara, se forman colas internas y la latencia de E/S se dispara, convirtiendo operaciones rápidas en graves cuellos de botella operativos.

Para entender este comportamiento en la práctica, imagina una autopista de diez carriles que de repente se reduce a un solo carril debido a una barrera invisible. Eso es exactamente lo que ocurre dentro del kernel de Linux cuando el número de peticiones de lectura y escritura supera la capacidad física de la controladora o medio de almacenamiento. Como detallamos en nuestro artículo sobre el análisis de cuellos de botella de IOPS en servidores de bases de datos, ignorar estos síntomas de latencia puede corromper datos o tumbar servicios enteros por agotamiento de conexiones esperando al disco.

Cómo usar iostat para identificar cuellos de botella iniciales

El primer paso en cualquier investigación seria sobre el rendimiento del almacenamiento es observar el comportamiento global del sistema a través de herramientas consagradas. El comando iostat, que forma parte del paquete sysstat, es el punto de partida perfecto para medir estadísticas de uso de CPU y E/S de dispositivos de bloques. Al ejecutar el comando con un intervalo de tiempo, el objetivo principal no es solo mirar el número de IOPS en bruto, sino monitorear métricas críticas como el tiempo medio de espera y el porcentaje de ocupación del disco.

Para iniciar el monitoreo en tiempo real cada dos segundos, ejecutamos el comando en la terminal con los parámetros adecuados:

iostat -xz 2

En la salida generada por este comando, la columna await indica el tiempo medio en milisegundos que cada petición tardó en ser atendida, incluyendo el tiempo en cola y el tiempo de procesamiento en el disco. Si este valor supera consistentemente unos pocos milisegundos en unidades SSD o NVMe, tienes un problema claro de colas. Asimismo, la columna %util muestra el nivel de saturación del dispositivo; si permanece cerca del cien por ciento durante largos periodos, el disco ha alcanzado su límite físico de procesamiento simultáneo.

Rastreando eventos profundos con blktrace

Cuando iostat solo señala que el disco está lento pero no revela qué proceso o capa está causando el retraso, debemos recurrir a utilidades más avanzadas de instrumentación del kernel. blktrace es una herramienta de rastreo a nivel de kernel que captura eventos detallados de E/S en tiempo real, registrando con precisión cuándo un bloque de datos entra en la cola, cuándo se despacha al controlador del dispositivo y cuándo el hardware finalmente confirma la operación.

Esta granularidad quirúrgica permite identificar si el problema radica en cómo el sistema operativo agrupa los bloques o si el propio hardware tarda demasiado en responder a los comandos NVMe. Para recopilar estos rastreos en un disco específico, como el dispositivo /dev/nvme0n1, utilizamos una secuencia de comandos que graba los datos en bruto y luego los resume con la utilidad blkparse:

blktrace -d /dev/nvme0n1 -o - | blkparse -i -

En la práctica, cada línea generada por esta herramienta representa un paso en el ciclo de vida de una petición de disco. Analizando letras como Q (queued), D (dispatched) y C (complete), podemos calcular el tiempo exacto que la petición pasó esperando en la cola interna del sistema operativo antes de ser enviada físicamente al hardware de almacenamiento.

Optimizando schedulers NVMe para alta concurrencia

Un error conceptual común en la administración de servidores modernos es mantener los mismos algoritmos de planificación de E/S que se usaban en la época de los discos duros mecánicos (HDD). Los discos mecánicos necesitaban algoritmos complejos como CFQ para reorganizar físicamente el movimiento de los cabezales de lectura y escritura, minimizando el tiempo perdido con el giro de los platos. Sin embargo, las unidades de estado sólido y memorias NVMe operan mediante chips electrónicos y poseen un paralelismo masivo nativo, haciendo que este ordenamiento mecánico sea totalmente innecesario y contraproducente.

Para extraer el máximo rendimiento de un entorno con alta concurrencia, debemos configurar el planificador de bloques en modo none o kyber, según la carga de trabajo. El modo none elimina por completo la sobrecarga de colas innecesarias en el software, permitiendo que las peticiones fluyan directamente hacia la controladora NVMe, la cual ya cuenta con su propio administrador de colas ultrarrápido en hardware. Como exploramos en la guía sobre optimización de bases de datos en hardware dedicado, este simple cambio reduce la latencia en valiosos microsegundos.

Ajustando parámetros de cola y profundidad en sysfs

Además de elegir el planificador adecuado, el kernel de Linux permite ajustar directamente los límites de profundidad de cola (queue depth) a través del sistema de archivos virtual sysfs. La profundidad de cola define cuántas operaciones puede enviar simultáneamente el sistema operativo al disco sin esperar la respuesta de la anterior. Si este número es muy bajo, el disco se queda ocioso esperando órdenes; si es muy alto, las peticiones se acumulan y generan retrasos perceptibles en las aplicaciones.

Para verificar y ajustar la profundidad de cola de un dispositivo NVMe de forma dinámica, podemos interactuar directamente con los archivos de configuración del kernel expuestos en el directorio del sistema:

cat /sys/block/nvme0n1/queue/nr_requests
echo 256 > /sys/block/nvme0n1/queue/nr_requests

Esta modificación inmediata ayuda a calibrar el margen de maniobra del subsistema de almacenamiento según la carga real de tu infraestructura. En servidores que manejan miles de conexiones simultáneas, elevar este límite suele destrabar el flujo de datos, evitando que los hilos de bases de datos queden bloqueados esperando espacio en las colas internas de E/S del sistema operativo. Para profundizar en estos conceptos arquitectónicos en producción, consulte también nuestro análisis técnico sobre Por qué usar Row-Level Security en PostgreSQL para aislar clientes.

Consideraciones finales sobre resiliencia de almacenamiento

Diagnosticar y resolver cuellos de botella de IOPS en entornos Linux de alta concurrencia exige un cambio de mentalidad, alejándose de las suposiciones y apostando por la observación métrica rigurosa. Al dominar herramientas como iostat para la visión macro y blktrace para el diagnóstico micro, el ingeniero adquiere la capacidad de ver con precisión dónde el flujo de datos sufre resistencia. Unir esta visibilidad quirúrgica al ajuste correcto de los planificadores y parámetros de cola del kernel garantiza que tu hardware NVMe funcione a su máximo potencial, protegiendo tus datos y asegurando la estabilidad operativa a largo plazo.