Aceleración de Linux usando hdparm

NOTA: El siguiente documento es una traducción del texto Speeding Linux Using hdparm por Rob Flickenger.

¿Estás utilizando un sistema Linux basado en Intel con al menos un disco duro (E)IDE? ¿No sería bueno que existiera un comando mágico para doblar instantáneamente la capacidad de entrada/salida de tus discos, o, en algunos casos, mostrar de 6 a 10 veces más rendimiento? No hace falta que leas hdparm(8). Si nunca has oido hablar de él, no te preocupes. Mucha de la gente con la que he hablado tampoco ha oido hablar de hdparm. Pero si estás utilizando un sistema Linux con unidades IDE (como mucha gente hace) te preguntarás como has podido vivir hasta ahora sin él. Lo sé. Yo lo hice.

¿Cuál es el trato?
Así que tienes tu recien estrenado dispositivo UltraATA/66 EIDE con un flamante nuevo controlador que soporta múltiples modos PIO y DMA, la opción de asientos de cuero y cromo extra... Pero, ¿está tu sistema tomando ventaja de estas características?. El comando hdparm(8) no solo te dirá cómo está actuando tu dispositivo, sino que te dejará exprimirlo al máximo.
Antes de que te excites demasiado con la idea, es necesario puntualizar que bajo determinadas circunstancias, estos comandos PUEDEN PRODUCIR UNA INESPERADA CORRUPCIÓN DE DATOS. ¡Usalos bajo tu propia responsabilidad!. Como mínimo, realiza una copia de seguridad de tu sistema y cambia a un modo mono-usuario antes de proceder.
Una vez hecha la advertencia habitual, me gustaría indicar que si estás utilizando hardware actual (por ejemplo, tu dispositivo Y controlador Y placa base fueron fabricados en los últimos dos o tres años) se tiene muy poco riesgo. He utilizado estos comandos en varias máquinas con varias configuraciones hardware, y lo peor que he visto ha sido un cuelgue ocasional, sin problemas de pérdida de datos al reiniciar. Y no importa las culpas que me des a mí o al mundo en general por una mala fortuna personal, todos conocemos quien es el último responsable de TU máquina: TÚ.
Y ahora, si todavía no te he asustado, prueba lo siguiente (como root, preferentemente en modo mono-usuario):

hdparm -Tt /dev/hda

Verás algo similar a:

/dev/hda:
Timing buffer-cache reads: 128 MB in 1.34 seconds =95.52 MB/sec
Timing buffered disk reads: 64 MB in 17.66 seconds =3.58 MB/sec

¿Qué nos dice esto? El -T significa que se pruebe el sistema de caché (por ejemplo, la memoria, CPU y buffer-cache). El -t significa que se muestren estadísticas del disco en cuestión, leyendo datos que no se encuentren en la caché. Los dos parámetros juntos, ejecutados varios veces seguidas en modo mono-usuario, nos darán una idea del rendimiento de tu sistema de entrada/salida del disco. (Los datos de ejemplo se han tomado en un PII/350 / 128M Ram / disco duro EIDE; tus números pueden variar de los mostrados).
3.58 MB/sec es PATÉTICO para el hardware indicado. El que me vendió la unidad dijo algo de unos 66MB por segundo!.
Bueno, veamos algo más de como nuestro Linux está direccionando nuestra unidad:

hdparm /dev/hda

/dev/hda:
multcount = 0 (off)
I/O support = 0 (default 16-bit)
unmaskirq = 0 (off)
using_dma = 0 (off)
keepsettings = 0 (off)
nowerr = 0 (off)
readonly = 0 (off)
readahead = 8 (on)
geometry = 1870/255/63, sectors = 30043440, start = 0

Estos son los valores por defecto. Bonitos, seguros, pero no necesariamente los óptimos. ¿Qué es eso del modo 16-bit? ¡Yo pensaba que se abandonó con el 386! ¿Y por qué la mayoría de las opciones se encuentran desactivadas?
Bueno, normalmente se considera una buena idea para cualquier distribución instalar de la forma más segura las cosas. Está virtualmente garantizados que los parámetros mostrados en el ejemplo anterior funcionarán con cualquier hardware que nos encontremos. Pero como sabemos que estamos utilizando algo más moderno que una unidad de hace 8 años con 16-bits, hablemos de las opciones interesantes:

multcount: abreviatura de multiple sector count. Esto controla cuantos sectores son leidos del disco en una única interrupción de entrada/salida. Casi todos los dispositivos IDE modernos lo soportan. La página man dice que:

Cuando esta característica es activada, normalmente reduce la carga del sistema operativo para la entrada/salida de un 30% a un 50%. En algunos sistemas además provee de un incremento del rendimiento de datos de un 5% a un 50%.

I/O Support: este es el más importante. Este flag controla como los datos son transferidos del bus PCI al controlador. Casi todos los modernos controladores soportan modo 3, o modo de 32-bits w/sync. Algunos incluso soportan 32-bits async. Activar esto practicamente duplicará el rendimiento.

unmaskIrq:activar esto permitirá a Linux desenmascarar otras interrupciones mientras se esté procesando una interrupción de disco. ¿Qué significa esto? Permite a Linux atender otras tareas relacionadas con interrupciones (por ejemplo, el tráfico de red) mientras se espera a que el disco devuelva los datos que se le pidieron. Podría incrementar el tiempo de respuesta del sistema, pero cuidado: no todas las configuraciones de hardware serán capaces de controlar esto. Para más información consultar la página man correspondiente.

using_dma: usar DMA puede ser algo difícil. Si puedes hacer que tu dispositivo utilice DMA, hazlo. Pero he visto más de una máquina colgarse mientras se jugaba con esta opción. De nuevo, consultar la página man es lo adecuado (junto con el siguiente ejemplo).

Metiendo el turbo
Una vez tenemos nuestro sistema en modo mono-usuario, como un buen pequeño administrador, intentemos algunos cambios:

hdparm -c3 -m16 /dev/hda

/dev/hda:
setting 32-bit I/O support flag to 3
setting multcount to 16
multcount = 16 (on)
I/O support = 3 (32-bit w/sync)

¡Bien! Suena bien eso de 32-bit. Y algunas multilecturas nos ayudarán. Volvemos a realizar la prueba:

hdparm -tT /dev/hda

/dev/hda:
Timing buffer-cache reads: 128 MB in 1.41 seconds = 90.78 MB/sec
Timing buffered disk reads: 64 MB in 9.84 seconds = 6.50 MB/sec

¡Guau! ¡Casi el doble de rendimiento sin apenas trabajo! Increible.
Pero espera, hay más: todavía no hemos desenmascarado las interrupciones, usado el DMA, o ni siquiera utilizado un modo PIO decente. De acuerdo, habilitar estas opciones es más arriesgado (¿Por qué hay siempre más seguridad cuanta menos libertad y viceversa?). La página man menciona el probar Multiword DMA mode2, así que:

hdparm -X34 -d1 -u1 /frv/hda

Desafortunadamente esta configuración parece no estar soportada en esta máquina en particular (se colgó como una máquina NT ejecutando un applet Java). Así que, tras reiniciarla (de nuevo en modo mono-usuario), intenté con lo siguiente:

hdparm -X66 -d1 -u1 -m16 -c3 /dev/hda

/dev/hda:
setting 32-bit I/O support flag to 3
setting multcount to 16
setting unmaskirq to 1 (on)
setting using_dma to 1 (on)
using xfermode to 66 (UltraDMA mode 2)
multcount = 16 (on)
I/O Support = 3 (32-bit w/sync)
unmaskirq = 1 (on)
using_dma = 1 (on)

y entonces volví a realizar el test:

hdparm -tT /dev/hda

/dev/hda:
Timing buffer-cache reads: 128 MB in 1.43 seconds = 89.51 MB/sec
Timing buffered disk reads: 64 MB in 3.18 seconds = 20.13 MB/sec

20.13 MB/sec. Bastante más que el minúsculo 3.58 con el que empezamos.
Por otra parte, ¿te has fijado como he especificado el -m16 y el -c3 de nuevo? Eso es porque el sistema no guarda los cambios tras reiniciar. Se debería añadir el comando anterior a los scripts /etc/rc.d/* una vez estemos seguros de que el sistema es estable (y preferentemente después de que fsck se haya ejecutado).
Ahora, después de probar con -tT unas cuantas veces más, reinicia en modo multi-usuario y arranca las X. Carga el Netscape. Y trata de no caerte de la silla.

Conclusiones
Este es uno de los pequeños trucos que se le escapa a muchos veteranos de Linux, especialmente debido a que uno nunca ve ninguna indicación de que el sistema no está usando la configuración óptima (todos mis mensajes del núcleo parecían correctos...). Y usar hdparm no es completamente seguro, pero vale la pena investigarlo.
Y no solo se queda en el rendimiento: hdparm permite también ajustar ciertos parámetros de ahorro de energía. Para verlo consulta hdparm(8).
Muchas gracias a Mark Lord por crear esta utilidad. Si tu distribución no incluye hdparm (normalmente se encuentra en /sbin o /usr/sbin), puedes obtener el código fuente en http://metalab.unc.edu/pub/Linux/system/hardware/.

[VOLVER]