LinuxParty

Hay momentos en los que un sistema Linux empieza a comportarse de forma extraña.

No se cae.
No da errores claros.
Pero algo no va bien.

Las aplicaciones tardan más en responder, las consultas a base de datos se vuelven lentas y tareas que antes eran instantáneas ahora parecen quedarse pensando. Lo primero que solemos mirar es la CPU. Luego la memoria. A veces incluso la red.

Y, sin embargo, muchas veces el problema está en otro sitio.

En el disco.

El problema que no hace ruido

A diferencia de otros fallos, el almacenamiento no suele avisar de forma evidente. No hay un pico espectacular que lo delate ni un mensaje claro que diga “esto es el problema”.

Simplemente empieza a no dar más de sí.

El sistema sigue funcionando, pero cada operación de lectura o escritura tarda un poco más. Y cuando esas pequeñas demoras se acumulan, el resultado es un sistema que parece pesado, torpe, como si algo lo estuviera frenando desde dentro.

Ese “algo” suele ser un cuello de botella en el disco.

Cuando todo depende del I/O

En muchos entornos reales, el rendimiento no depende tanto de la potencia de cálculo como de la velocidad a la que el sistema puede mover datos.

Bases de datos, logs, sistemas web, máquinas virtuales… todos ellos dependen constantemente del acceso a disco. Si ese acceso se vuelve lento, todo lo demás se ve afectado.

Es fácil caer en el error de pensar que añadir más CPU o más RAM solucionará el problema. Pero si el disco no puede seguir el ritmo, da igual cuántos recursos tengas: el sistema seguirá esperando.

Y en informática, esperar es perder rendimiento.

Aprender a mirar donde casi nadie mira

Una de las claves para detectar este tipo de problemas en Linux es observar lo que realmente está pasando con el I/O.

Herramientas como iostat, iotop o vmstat permiten ver algo que normalmente pasa desapercibido: cuánto tiempo pasa el sistema esperando al disco.

Cuando ese tiempo empieza a crecer, es una señal clara de que algo no va bien.

No hace falta que el disco esté al 100% de uso. A veces basta con que las operaciones se acumulen o que la latencia aumente para que todo empiece a degradarse.

Y eso es justo lo que estas herramientas ayudan a descubrir.

El tipo de disco sí importa (y mucho)

No todos los discos se comportan igual.

Un disco mecánico tradicional no puede competir con un SSD moderno, y mucho menos con soluciones NVMe. La diferencia no es solo de velocidad máxima, sino de cómo responden bajo carga.

En entornos donde hay muchas operaciones pequeñas y constantes, como bases de datos o sistemas con muchos accesos simultáneos, esa diferencia se vuelve crítica.

A veces el problema no es una mala configuración.
Es simplemente que el hardware ya no está a la altura.

Afinar el sistema también marca la diferencia

Pero no todo pasa por cambiar discos.

Linux ofrece bastante margen para ajustar cómo se gestionan las operaciones de entrada y salida. El planificador de I/O, por ejemplo, puede influir directamente en cómo se priorizan las tareas de lectura y escritura.

Elegir correctamente entre opciones como noop, deadline o cfq puede marcar la diferencia dependiendo del tipo de carga y del hardware que se esté utilizando.

También hay otros factores que suelen pasarse por alto: sistemas de archivos mal elegidos, configuraciones por defecto que no encajan con el uso real, o incluso procesos que generan más escritura de la necesaria.

Pequeños detalles que, acumulados, terminan afectando al rendimiento.

A veces no es el disco… pero casi siempre lo parece

Hay algo importante que conviene tener en cuenta: no todo lo que parece un problema de disco lo es realmente.

Un sistema sin memoria suficiente puede empezar a usar swap, y eso genera actividad de disco que no debería existir. Lo mismo ocurre con aplicaciones mal optimizadas o con configuraciones que provocan escrituras constantes.

Por eso, antes de sacar conclusiones, es importante mirar el conjunto.

Pero si después de revisar todo lo demás el sistema sigue lento… el disco suele ser el siguiente sospechoso.

El clásico error: mirar tarde

Quizá el mayor problema de los cuellos de botella de disco es que muchas veces se detectan tarde.

Cuando el sistema ya está claramente degradado.
Cuando los usuarios ya se quejan.
Cuando el rendimiento ha caído lo suficiente como para ser evidente.

Pero en realidad, esos problemas suelen llevar tiempo formándose.

Por eso, en entornos profesionales, monitorizar el I/O no es opcional. Es una forma de adelantarse a los problemas antes de que sean críticos.

Conclusión: el cuello de botella que no perdona

Linux es robusto, eficiente y capaz de sacar el máximo partido al hardware.

Pero hay algo que no puede hacer: ignorar un disco lento.

Cuando el almacenamiento no responde como debería, todo el sistema se resiente. Y lo hace de una forma silenciosa, progresiva y, a veces, difícil de detectar.

Por eso, la próxima vez que un sistema “vaya raro” y no encuentres el problema…

Mira el disco.

Porque muchas veces, el verdadero cuello de botella no está donde todos miran primero.

💬 Y tú, ¿cuándo fue la última vez que miraste el I/O?

¿Has tenido problemas de rendimiento que al final eran culpa del disco?
¿O sigues confiando demasiado en CPU y RAM?

Lea alguno de nuestros artículos:

Comprobar el estado de salud del disco duro con Smartmontools, smartctl buscando sectores ilegibles

Comprobar el estado de los discos duros en linux

Comprobar la salud del disco duro en Linux

Cómo formatear discos en Linux desde la línea de comandos

Testar el rendimiento de discos duros en Linux

3 útiles herramientas GUI de escaneo de disco de Linux basadas en terminales

Filelight: analice rápidamente las estadísticas de uso del disco en Linux

Herramientas útiles para monitorear y depurar el rendimiento de E/S de disco en Linux

Cómo recuperar un disco o partición de Linux o Windows. NTFS

Chequear y comprobar el disco duro automáticamente al inicio en Linux

Recuperar los datos de un disco duro muerto usando el dd_rescue