¿Disco NVMe lento? Cómo hallar cuellos de botella de I/O en Linux

Por qué el almacenamiento NVMe aún puede generar cuellos de botella

Las unidades de almacenamiento modernas basadas en el protocolo NVMe revolucionaron la informática actual al eliminar los cuellos de botella mecánicos de los discos duros antiguos y superar al bus SATA tradicional. En la práctica, esto significa que nuestros servidores ahora pueden procesar cientos de miles de operaciones por segundo sin sudar. Sin embargo, incluso con velocidades estratosféricas de lectura y escritura, las aplicaciones de alta demanda siguen sufriendo de lentitud inexplicable. Comprender la salud del subsistema de almacenamiento requiere ir mucho más allá de revisar el espacio libre en disco.

Cuando una aplicación se congela esperando datos de la memoria persistente, el problema rara vez es la falta de capacidad bruta. El verdadero culpable suele ser la latencia de I/O, es decir, el tiempo que el sistema tarda en atender una solicitud de lectura o escritura. Para diagnosticar esto correctamente, debemos observar métricas fundamentales como IOPS (operaciones de entrada y salida por segundo) y la profundidad de la cola de comandos. Antes de culpar al código de la aplicación, vale la pena investigar si el problema está en el hardware o en la controladora, algo que también analizamos al ver cómo diagnosticar fallas en SSDs NVMe en Linux por medio de la terminal.

Monitoreando el pulso del disco con iostat

La herramienta más rápida y accesible para inspeccionar la actividad de discos en Linux forma parte del paquete sysstat. El comando iostat muestra estadísticas detalladas sobre la utilización de la CPU y el rendimiento de las particiones de disco y unidades lógicas. Al ejecutarlo con parámetros de intervalo, podemos observar el comportamiento exacto del hardware bajo carga. En la práctica, nos brinda una perspectiva panorámica de cuánto tiempo pasa el disco ocupado procesando peticiones y cuál es el tamaño promedio de las colas acumuladas.

Para comenzar a monitorear en tiempo real con actualizaciones cada dos segundos, simplemente ejecute el siguiente comando en la terminal de su servidor. Preste mucha atención a la columna await, que mide el tiempo promedio en milisegundos que tardan las solicitudes en ser atendidas, incluyendo el tiempo en cola y el procesamiento físico del dispositivo.

iostat -xz 2 5

Si los valores de await se disparan mientras el porcentaje de utilización (util) llega al ciento por ciento, ha encontrado un claro indicador de saturación. Esto significa que el disco recibe más peticiones de las que puede procesar simultáneamente. Tenga en cuenta que problemas térmicos paralelos, como se discute al revisar cómo monitorizar la temperatura del NVMe en Linux por terminal, también reducen la velocidad para prevenir daños por calor.

Midiendo la capacidad real con pruebas de estrés

A menudo, las especificaciones técnicas impresas en la caja del SSD NVMe representan escenarios ideales que rara vez ocurren en el mundo real. Para saber si su hardware cumple lo prometido o sufre de desgaste, el mejor camino es realizar pruebas controladas. La utilidad fio (Flexible I/O Tester) es el estándar de la industria para simular patrones de carga complejos, desde accesos secuenciales masivos hasta miles de lecturas aleatorias simultáneas.

El siguiente comando ejecuta una prueba rápida de escritura aleatoria con bloques de cuatro kilobytes, simulando el comportamiento típico de una base de datos relacional moviendo índices pesados. Utiliza múltiples procesos para estresar la controladora y medir el comportamiento real de la latencia bajo presión.

fio --name=randwrite-test --ioengine=libaio --rw=randwrite --bs=4k --numjobs=4 --size=1G --iodepth=64 --runtime=60 --time_based

Analizar el informe generado por fio requiere prestar especial atención a la distribución de la latencia expresada en percentiles. Si el percentil noventa y nueve (p99) muestra tiempos de respuesta en cientos de milisegundos, su aplicación experimentará pausas perceptibles para el usuario final, aunque el promedio general parezca aceptable.

Investigando colas profundas y cuellos de botella en el kernel

Cuando iostat señala cuellos de botella pero las pruebas sintéticas muestran un disco saludable, el problema puede estar en cómo el sistema operativo gestiona las peticiones de E/S. Linux utiliza capas de software en el núcleo para organizar el tráfico antes de entregarlo físicamente al bus NVMe. Herramientas como blktrace permiten rastrear cada evento de I/O a nivel de bloque, mapeando exactamente dónde se produce el retraso en la pila de software.

Para capturar eventos de seguimiento en tiempo real en una unidad específica y convertirlos en un formato legible, combinamos blktrace con la utilidad blkparse. Esto ayuda a identificar si el planificador de E/S del núcleo está encolando solicitudes de forma ineficiente para la topología de su hardware.

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

Este análisis minucioso es indispensable en entornos de alta densidad de virtualización o clústeres de bases de datos donde múltiples procesos compiten por los mismos canales DMA. Identificar si el cuello de botella reside en la cola del controlador o en el dispositivo mismo evita reemplazos innecesarios de hardware. Para profundizar en estos conceptos arquitectónicos en producción, consulte también nuestro análisis técnico sobre ¿Chip de red dañado en la placa base? Cómo probarlo con multímetro.

Consideraciones finales

Diagnosticar cuellos de botella de I/O en discos NVMe en Linux deja de ser un misterio al combinar la observación en tiempo real con pruebas de estrés dirigidas. El secreto radica en no mirar solo la velocidad máxima teórica, sino la consistencia de la latencia y el comportamiento de las colas bajo presión operativa. Mantener rutinas de monitoreo preventivo garantiza que su infraestructura permanezca resiliente, rápida y lista para soportar picos de tráfico sin degradación imperceptible.