1. Introducción
El siguiente artículo busca aportar información práctica para poder depurar y determinar donde pueden estar localizados los problemas de entrada/salida (I/O) a disco, cómo evaluarlos y cómo afectan al rendimiento de su sistema.
El artículo se centra en dos herramientas habitualmente utilizadas y que aportan información complementaria de los consumos de disco, que son iotop y sar (de sysstat). Existen otras herramientas como top, htop e iostat. Todas ellas usan interfaces similares del kernel por lo que la información aquí contenida será homóloga a la que se puede obtener con esas otras utilidades.
2. Analizando el uso de disco con iotop
Una herramienta socorrida para saber quién está generando lecturas y escrituras en nuestro sistema es iotop.
Esta herramienta se basa en el sistema de accounting taskstats que proporciona el kernel de linux:
Básicamente, iotop, lo que muestra es la cantidad de ancho de banda que se genera por proceso, entiendo
este valor como la cantidad de datos leídos y escritos por el mismo.
Esta cantidad de datos leídos y escritos no tiene en cuenta el numero de IOPS que realmente se están
generando por debajo, ni tampoco si fueron leídos seguidos (de un fichero grande), o si fueron leídos
de sectores aleatorios discontinuos, ni tampoco si durante ese periodo de entrada salida se generaron
operaciones cambio de atributos o borrado de ficheros.
iotop muestra la información de entrada/salida neta que ha sido finalmente recibida o escrita por el proceso, es decir, es una lectura al final de todo el proceso de entrada/salida.
Con todos estos datos, para ver la entrada/salida neta, sólo relacionada con lectura y escritura, ejecutamos (como root):
>> iotop -a
3. iotop: la entrada/salida (I/O) no sólo se limita a la escritura/lectura que hace un proceso
Esa es la principal pega de iotop: nos oculta mucha información de I/O que genera el proceso, sólo mostrando el dato limpio de lectura y escritura, sin entrar a valorar las IOPS/tps que se generaron durante el proceso.
En definitiva: cuando se hace entrada/salida (I/O), no todo es lectura y escritura. También hay que contabilizar todas las operaciones que puedan generar lecturas y escrituras de bloques en el disco, y por tanto, IOPS, donde se puede incluir:
- Modificación/actualización del journaling del sistema de ficheros
- Borrado de ficheros
- Actualización de atributos (lsattr, chmod, chown)
- Reparado y contabilización (quotafs, e2fsck)
- Creado y borrado de carpetas
- Lectura y escaneado de directorios (find, opendir)
- …
En este sentido, si queremos saber la entrada/salida total que se está generando en el sistema, ahí es donde sar del paquete systat nos puede ayudar.
4. sar: cómo interpretar el número de operaciones de I/O al disco y parámetro "await"
La herramienta sar del paquete sysstat, nos permitirá obtener dos parámetros muy importantes asociados a la entrada/salida (I/O) y que son:
-
tps: número de operaciones I/O por segundo (se podría decir que son las IOPS)
-
await: tiempo medio de espera, en milisegundos, para atender las peticines de I/O recibidas.
Con estos datos, podemos ejecutar el siguiente comando para obtener una estatística refrescada cada segundo:
>> sar -d 1
....
18:38:34 DEV tps rd_sec/s wr_sec/s avgrq-sz avgqu-sz await svctm %util
18:38:35 dev8-0 10,28 2183,18 0,00 212,36 0,09 8,36 5,45 5,61
18:38:35 DEV tps rd_sec/s wr_sec/s avgrq-sz avgqu-sz await svctm %util
18:38:36 dev8-0 29,41 2431,37 305,88 93,07 0,15 4,97 3,33 9,80
18:38:36 DEV tps rd_sec/s wr_sec/s avgrq-sz avgqu-sz await svctm %util
18:38:37 dev8-0 107,07 2618,18 11167,68 128,75 0,18 1,94 1,51 16,16
18:38:37 DEV tps rd_sec/s wr_sec/s avgrq-sz avgqu-sz await svctm %util
18:38:38 dev8-0 12,39 148,67 134,51 22,86 0,14 10,93 6,29 7,79
Como hemos dicho, de la salida que genera nos interesan los parámetros tps y await.
De manera concreta, el await debe de ser cero, o estar cerca de cero y mantenerse por debajo de 4ms de manera general. Si sube por encima, la máquina tendrá problemas.
Un await por encima de 30ms o superior, de manera constante o durante varios segundos es una indicación de que se está generando un número de operaciones de entrada/salida (tps, IOPS), por encima de la capacidad de I/O que tiene la máquina.
Es decir, se están realizando operaciones de lectura, escritura, borrados, cambios de atributos, flushing, sync, etc, en una suma tal que excede la capacidad de I/O de la máquina.
Al mismo tiempo, hay que fijarse en el parámetro tps para ver a partir de cuándo se comienzan a generar esperas (await). Ese será el límite de IOPS/tps que puede aguantar el disco.
5. Lectura de un sistema sano, sin problemas de entrada/salida con sar
A continuación se muestra ejemplo de un sistema con mucha entrada salida (tps) pero que está siendo capaz de gestionarlo sin problemas (await cero o cerca de cero):
>> sar -d 1
....
06:53:23 PM DEV tps rkB/s wkB/s areq-sz aqu-sz await svctm %util
06:53:24 PM dev8-0 24.00 0.00 320.00 13.33 0.00 0.00 0.00 0.00
06:53:24 PM dev8-16 615.00 548.00 6204.00 10.98 0.03 0.05 0.05 3.20
06:53:24 PM dev253-1 619.00 548.00 6204.00 10.91 0.04 0.06 0.06 3.60
06:53:24 PM dev253-0 38.00 0.00 312.00 8.21 0.00 0.00 0.00 0.00
06:53:24 PM dev8-32 427.00 236.00 4684.00 11.52 0.06 0.14 0.09 4.00
06:53:24 PM dev253-2 432.00 236.00 4684.00 11.39 0.07 0.15 0.11 4.80
06:53:24 PM dev8-48 345.00 296.00 4144.00 12.87 0.06 0.17 0.10 3.60
06:53:24 PM dev253-3 345.00 296.00 4144.00 12.87 0.06 0.16 0.09 3.20
06:53:24 PM dev8-64 192.00 96.00 2152.00 11.71 0.03 0.15 0.15 2.80
06:53:24 PM dev253-4 195.00 96.00 2152.00 11.53 0.03 0.14 0.14 2.80
06:53:24 PM dev8-80 304.00 448.00 3124.00 11.75 0.02 0.07 0.05 1.60
06:53:24 PM dev253-5 310.00 448.00 3124.00 11.52 0.02 0.06 0.05 1.60
06:53:24 PM dev8-96 1186.00 1012.00 11840.00 10.84 0.09 0.08 0.06 7.20
06:53:24 PM dev253-6 1198.00 1016.00 11840.00 10.73 0.10 0.08 0.07 8.00
Como se puede ver, el sistema está generando una suma de 6230 tps/IOPS por segundo, y en ninguno de sus dispositivos está teniendo problemas de await (todos a cero o cerca de cero).
Este ejemplo está sacado de un nodo de almacenamiento ceph con discos SSD.
6. Lectura de un sistema con problemas de entrada/salida usando sar
A continuación mostramos una lectura de un sistema con problemas de entrada/salida, donde las peticiones se están atascando, generando esperas, lo que se traduce en webs lentas, accesos de correo lentos, accesos a directorios lentos, borrados lentos, etc…
>> sar -d 1
18:59:10 DEV tps rd_sec/s wr_sec/s avgrq-sz avgqu-sz await svctm %util
18:59:11 dev8-0 24,58 352,54 637,29 40,28 0,32 13,21 12,41 30,51
18:59:11 DEV tps rd_sec/s wr_sec/s avgrq-sz avgqu-sz await svctm %util
18:59:12 dev8-0 1915,65 0,00 19429,57 10,14 77,78 7,60 0,16 30,96
18:59:12 DEV tps rd_sec/s wr_sec/s avgrq-sz avgqu-sz await svctm %util
18:59:13 dev8-0 206,31 0,00 1888,29 9,15 223,36 815,45 4,28 88,29
18:59:13 DEV tps rd_sec/s wr_sec/s avgrq-sz avgqu-sz await svctm %util
18:59:14 dev8-0 196,61 0,00 1579,66 8,03 212,94 1178,21 4,29 84,41
18:59:14 DEV tps rd_sec/s wr_sec/s avgrq-sz avgqu-sz await svctm %util
18:59:15 dev8-0 276,47 47,06 2831,37 10,41 243,84 936,85 3,50 96,86
18:59:15 DEV tps rd_sec/s wr_sec/s avgrq-sz avgqu-sz await svctm %util
18:59:16 dev8-0 361,68 209,35 4142,06 12,03 219,32 739,38 2,55 92,34
18:59:16 DEV tps rd_sec/s wr_sec/s avgrq-sz avgqu-sz await svctm %util
18:59:17 dev8-0 198,25 280,70 9529,82 49,49 24,90 378,45 4,32 85,61
18:59:17 DEV tps rd_sec/s wr_sec/s avgrq-sz avgqu-sz await svctm %util
18:59:18 dev8-0 9,57 187,83 0,00 19,64 0,91 101,55 84,73 81,04
18:59:18 DEV tps rd_sec/s wr_sec/s avgrq-sz avgqu-sz await svctm %util
18:59:19 dev8-0 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00
En este caso vemos cómo el sistema, al superar las 200/300 tps/IOPS, comienza a tener problemas con la entrada/salida, generando esperas medias de hasta 1.17 segundos para las peticiones (await).
Este es un ejemplo de sistema que durante 8 segundos tuvo un rendimiento con bloqueos y esperas. Para un sistema de correo puro o de backup puede no llegar a notarse. Para un sistema con alta reactividad como bases de datos, plataformas web o plataformas de juegos, estos retrasos son críticos y se notarán mucho en la experiencia de usuario.
7. Preguntas frecuentes
-
¿En qué se diferencian iotop y sar?
La principal diferencia es que iotop proporciona lecturas y escrituras netas, recibidas y enviadas por el proceso, sin entrar a valorar cuántas tps/IOPS fueron generadas.
Al contrario, sar proporciona la entrada/salida real que se están produciendo en los discos, sin entrar a valorar si viene de lecturas hechas por procesos, por reparaciones del sistema de fichero, por borrados de ficheros, cambios de permisos, escaneo de bloqueos (por ejemplo una reparación de quotafs).
-
¿Qué ventajas tienen iotop y sar?
iotop es muy útil a la hora de saber qué proceso está leyendo o escribiendo más.
sar es muy útil para saber qué entrada/salida global se está generando en todo el servidor.
-
¿Porqué veo lecturas tranquilas con el iotop pero el servidor está saturado?
Con todo lo explicado, se puede dar la situación donde las lecturas de iotop no muestren mucha entrada/salida o muestren un proceso principal marcado como 99% o 100% de consumo, pero al fijarnos en la columna de ancho de banda vemos que se están escribiendo o leyendo relativamente pocos datos (no los suficientes para tumbar el sistema).
En ese caso, hay que arrancar sar para determinar el número de operaciones de entrada salida que se estén haciendo (tps/IOPS) así como los tiempos medios de espera await.
Si encontramos lecturas de await descontroladas (por encima de 30 y subiendo), entonces debe de haber otros procesos realizando operaciones que no son lecturas o escrituras pero que también generan entrada salida.
-
¿Qué relación guarda iotop con las lecturas/escrituras pequeñas?
iotop es muy malo para detectar pequeñas operaciones, aleatorias de escritura y lectura. Escribir una línea de log, modificar un atributo, añadir un dato al final del fichero, son todas operaciones que generan muy pocos bytes de lectura/escritura y por tanto pasan por debajo del radar de iotop. Sin embargo, todas estas opearciones generan IOPS/tps del mismo modo que operaciones con bloques de datos más grandes y continuos.
Debido a esta característica, en sistemas con muchos usuarios realizando accesos aleatorios a distintas partes del disco, causan una entrada/salida difuminada que no es fácil de capturar con iotop pero que con sar se refleja perfectamente.
-
¿Porqué iotop marca un proceso con 100% de consumo I/O cuando está leyendo pocos megas por segundo?
iotop se basa en la interfaz de accounting del kernel donde sólo se percibe la entrada/salida neta asociada a las lecturas y escrituras. A continuación la programación de iotop contabiliza los totales de toda esta información para todos los procesos para determinar el 100%. Con ese valor distribuye los porcentajes a cada proceso haciendo lecturas y escrituras.
Sin embargo, como ya hemos visto, iotop no tiene en cuenta toda la entrada salida real que se está produciendo en el sistema. Sólo la que le comunica el kernel a iotop y que ha sido completada.
Por todo esto, el máximo de referencia del 100% que usa iotop para sus cálculos no es el máximo real, causando que el resto de cálculos deban ser considerados bajo esta limitación.
-
¿Qué puedo hacer para mejorar el rendimiento de entrada/salida del servidor?
Esta es una pregunta compleja y muy abierta. Intentaremos dar unas pautas:
-
Hay que intentar dimensionar los servidores para las cargas que van a soportar, dándoles un margen de seguridad de al menos el 40%. Es decir, que su consumo máximo habitual esté al 60% de su capacidad de manera que el servidor pueda soportar picos.
-
Los rendimientos habitualmente esperados para sistemas con discos desktop están entre 50 y 100 IOPS. Para sistemas con discos profesionales podemos llegar hasta 200 IOPS (dependiendo de la controladora).
-
Si añadimos controladoras RAID hardware, podemos estar trabajando entre 300 y 800 IOPS, aunque sólo durante un tiempo (hasta que se acaba la cache, momento en que la I/O se reduce a la velocidad de los discos). Para estar por encima de esos valores hay que contar con discos SSD, memorias NVME y sistemas cluster de almacenamiento como Ceph.
-
-
¿Cómo puedo instalar éstas herramienta?
# Para sistemas ubuntu y debian >> apt-get install itop >> apt-get install sysstat # para sar
8. Resúmen
-
Un sistema sano dará siempre buenas lecturas con sar (await bajos).
-
Use iotop para poder localizar procesos concretos escribiendo o leyendo mucho.
-
Al contrario de sar, iotop nunca dará lecturas buenas (o malas): sólo mediciones de lo que se está leyendo/escribiendo. Esas mediciones que da iotop pueden causar problemas de entrada/salida en algunas máquinas o ser perfectamente normales en otras. Ahí es donde entra sar.