Problemas de acceso a disco con vmware y debian 6

Hola a todos, despues de casi 11 meses sin escribir ninguna entrada, hoy me he levantado con ganas ... ;)

Ultimamente me ha tocado pelearme mucho (bueno y a mis compañeros también) con herramientas de stress para optimizar el rendimiento del sistema operativo, en nuestro caso el pauperrimo acceso a disco que da la debian 6 cuando está montada sobre un ESX (4.1 o 5).

En nuestro caso en particular hemos usado sysbench. Hay muchas herramientas de este tipo, pero más allá de entrar en debate de cual es mejor o peor, lo importante es realizar los test con de manera homogenea para que los resultados sean lo más reveladores posible.

Bueno, poniendo un poco al personal en antecedentes, nuestra problematica como he dicho anteriormente viene tras detectar el pobre acceso a disco  (a los discos locales) que estabamos teniendo en nuestra plataforma, todo en debian 6 sobre ESX 4.1 de VMWARE.

Para realizar el test de disco hemos hecho un script que al final llama al sysbech y nos saca la tasa de transferencia de las operaciones a disco realizadas:

#!/bin/sh
for i in 1 2 8 16 32
do
echo "hilos $i"
for j in 1
do
echo "  intento $j"
sysbench --num-threads=$i --test=fileio --file-test-mode=rndrd --file-extra-flags=direct --max-requests=10000 prepare > /dev/null
sysbench --num-threads=$i --test=fileio --file-test-mode=rndrd --file-extra-flags=direct --max-requests=10000 run | grep transferred
sysbench --num-threads=$i --test=fileio --file-test-mode=rndrd --file-extra-flags=direct --max-requests=10000 cleanup > /dev/null
done
echo "___________________"
done

El script como vereis hace 5 veces con 1, 2, 8, 16 y 32 thread simultaneos. Lo normal cuando lanzas el test sobre un disco es que te de menos tasa de transferecia con 1 hilo y que la cosa vaya subiendo a medida que le metes hilos hasta que se estabiliza.

Pues bien la primera cosa que vimos fue que la tasa de transferecia era lineal, es decir, daba aproximadamente la misma tasa de transfercia con 1 hilo que con 32, raro, raro, raro....

La segunda cosa que vimos fue como podeis ver mas abajo que la tasa de transferecia era bajisima, apenas 9MB/s para estar montadas las imagenes de vmware montadas sobre una bandeja de discos en fiber channel de un almacenamiento EMC.

Si quereis saber las IOPS que son 9MBps la formula es facil:
  IOPS = (MBps Throughput / KB per IO) * 1024
Aqui KB por IO es 16K que es tamaño de bloque que sysbench usa por defecto en una operacion de entrada/salida

En nuestro caso y siguiendo esa formula son 575 IOPS.

 Aqui os pego el test con los resultados:

root@pre1 ~/kk $ /root/bin/benchmark_disk.sh
hilos 1
  intento 1
Read 156.25Mb  Written 0b  Total transferred 156.25Mb  (8.9316Mb/sec)
___________________
hilos 2
  intento 1
Read 156.25Mb  Written 0b  Total transferred 156.25Mb  (9.2897Mb/sec)
___________________
hilos 8
  intento 1
Read 156.25Mb  Written 0b  Total transferred 156.25Mb  (8.8921Mb/sec)
___________________
hilos 16
  intento 1
Read 156.25Mb  Written 0b  Total transferred 156.25Mb  (9.4219Mb/sec)
___________________
hilos 32
  intento 1
Read 156.25Mb  Written 0b  Total transferred 156.25Mb  (9.2804Mb/sec)


Como podeis apreciar, bastante bajo y lineal.


Pues bien, despues de estar persiguiendo este problema con el fabricante, leer mucho al respecto y hacer 1001 pruebas, a uno de nuestros compis se le encendio la bombilla y como por arte de magia cambiando un parametro todo empezo a funcionar a toda velocidad.

Que? Ya os creiais que os iba a dejar asi, sin contaros la solución verdad? ;)

La clave del asunto esta en el scheduler de las colas de acceso al disco. Y os preguntareis que es esto del scheduler, bueno, pues para los que no lo sepais, sin exterme mucho y entrar en demasiados detalles es la forma que tiene el sistema operativo de gestionar de una manera optima las operaciones enviadas al disco.

Esto se hace através de una cola, en debian 6 hay cuatro diferentes (noop, cfq, anticipatory y deadline) , cada una gestiona los accesos al disco de una manera distinta pero como dato deciros que por defecto se suele usar la cfg.

Esta cola lo que hace a groso modo es reorganizar las operaciones de IO en le van llegando de una manera optima para que los movimientos mecanicos del disco sean los menos posibles.

Algunos (los que no se hayan dormido ya) habrán llegado a la conclusión por si solos de que hay determinadas ocasiones en las que no tiene mucho sentido este tipo de comportamiento, como podria ser con discos SSD que no tienen parte mecanica o cuando el acceso al disco se esta gestionando desde otra capa como es en nuestro caso VMWARE.

Pues bien para esto esta la cola de tipo noop, que es la cola más sencilla de las cuatro, es de tipo FIFO y todo lo que entra sale al disco sin ningun tipo de orden que no sea el de prioridad de entrada.

Este parametro lo encontrais aqui:

root@pre1 ~/kk $ cat /sys/block/sdb/queue/scheduler
noop anticipatory deadline [cfq]

Para cambiarlo basta con ejecutar este comando y vereis que el scheduler cambia a noop:
root@pre1 ~/kk $ echo noop > /sys/block/sda/queue/scheduler
root@pre1 ~/kk $ cat /sys/block/sdb/queue/scheduler
[noop] anticipatory deadline cfq

Una vez echo esto repetimos las pruebas con asombrosos resultados:

root@pre1 ~/kk $ /root/bin/benchmark_disk.sh
hilos 1
  intento 1
Read 156.25Mb  Written 0b  Total transferred 156.25Mb  (8.5274Mb/sec)
___________________
hilos 2
  intento 1
Read 156.25Mb  Written 0b  Total transferred 156.25Mb  (17.948Mb/sec)
___________________
hilos 8
  intento 1
Read 156.25Mb  Written 0b  Total transferred 156.25Mb  (36.151Mb/sec)
___________________
hilos 16
  intento 1
Read 156.25Mb  Written 0b  Total transferred 156.25Mb  (39.358Mb/sec)
___________________
hilos 32
  intento 1
Read 156.25Mb  Written 0b  Total transferred 156.25Mb  (64.089Mb/sec)


Ahora si que si, la curva crece a medida que le metes hilos y la tasa de transferecia es mucho mayor, llegando a 64MBps (aunque el sysbench ponga Mb en realidad son MB) con unas IOPS de 4096.

Bueno espero con esto arrojar luz sobre este tema que tanto tiempo nos ha hecho perder, mejor dicho invertir, ya que ahora sabemos un poquito más que ayer...

Ciao!!

P.D. Gracias a todo mi equipo que son unos fieras, Oscar, Dani, Rober y Fermin.