La sincronización escribe muy lento. Ubuntu 10.10, 32 bits, ext4

Estoy ejecutando ActiveMQ en mi Macbook Pro que ejecuta Ubuntu 10.10, 32 bits con una partición ext4.

Linux iker-laptop 2.6.35-23-generic-pae #40-Ubuntu SMP Wed Nov 17 22:32:51 UTC 2010 i686 GNU/Linux

Si habilito la persistencia en ActiveMQ, el rendimiento cae terriblemente. He probado lo mismo en otras máquinas y la diferencia es de 2 órdenes de magnitud.

Hay una herramienta con activeMQ para probar el HD, aquí están los resultados:

iker@iker-laptop:~/apps/apache-activemq-5.4.1$ java -classpath lib/kahadb-5.4.1.jar org.apache.kahadb.util.DiskBenchmark 

Benchmarking: /home/iker/apps/apache-activemq-5.4.1/disk-benchmark.dat
Writes: 
  146171 writes of size 4096 written in 11.074 seconds.
  13199.477 writes/second.
  51.560455 megs/second.

Sync Writes: 
  197 writes of size 4096 written in 10.006 seconds.
  19.688187 writes/second.
  0.07690698 megs/second.

Reads: 
  5589861 reads of size 4096 read in 10.001 seconds.
  558930.2 writes/second.
  2183.321 megs/second.

El rendimiento de Sync Writes es s ** t. Debe haber algo mal configurado, pero esta es la única aplicación en la que he notado un problema de rendimiento de HD.

hdparm arroja los valores esperados:

iker@iker-laptop:~$ sudo hdparm -tT /dev/sda

/dev/sda:
 Timing cached reads:   6282 MB in  2.00 seconds = 3141.73 MB/sec
 Timing buffered disk reads:  240 MB in  3.00 seconds =  79.88 MB/sec

El principal factor limitante para la E / S sincrónica no es el rendimiento de su disco duro, sino el tiempo que toma desde que se emite la escritura y se confirma en el disco. La métrica de rendimiento más relevante para un disco duro a este respecto sería el tiempo de búsqueda del disco duro y no su rendimiento en circunstancias ideales.

Además del hardware que trabaja en su contra, también lo está el núcleo, supongo que puede ver una pequeña mejora (aunque, probablemente, no se acerque a lo que obtendrá de hacer IO asincrónico) si puede ionizar el punto de referencia (aplicación) para ejecutar bajo la clase de programación IO en tiempo real. De manera predeterminada, las aplicaciones se programarán en la clase de mejor esfuerzo, lo que probablemente también aumentará el tiempo de espera de sus escrituras. Utilice la clase de programación en tiempo real bajo su propio riesgo, ya que tendrá efectos adversos en el rendimiento de otras aplicaciones al acceder al disco.

En general, realmente no creo que haya nada terriblemente mal con el rendimiento de escritura síncrona que estás viendo. El IO síncrono en general funcionará horriblemente en comparación con el IO asíncrono.

Como nota al margen, un rápido google de activemq y synio io dio lo siguiente :

Por razones de rendimiento, es posible que desee transmitir mensajes al corredor lo más rápido posible, incluso si está utilizando mensajes persistentes

El programador de E / S cfq tiende a funcionar horriblemente en este tipo de pruebas. Además de la sugerencia de ionice anterior, es posible que desee intentar cambiar al planificador de E / S de fecha límite (ya sea iniciando con elevator=deadlineo haciendo for n in /sys/block/sd*/queue/scheduler ; do echo deadline > $n ; donecomo root).

Una escritura síncrona debe recibir un acuse de recibo de que la escritura se ha confirmado (si la confirmación fue un éxito o un error) antes de que pueda devolverse. Esto es así por diseño, e inherentemente hace que las escrituras sincrónicas sean mucho más lentas debido a los altos tiempos de latencia involucrados con un disco de metal giratorio (en el disco la memoria caché de ram no cuenta).

Las escrituras asincrónicas generalmente se escriben en la RAM y el sistema operativo se encarga de enviarlo al disco más tarde (más tarde suele ser solo segundos o menos (creo que ZFS es 5x / segundo, o cada 5 segundos)). Los tiempos de búsqueda de disco se miden en ms, mientras que los tiempos de búsqueda de RAM se miden en ns. Esa es una diferencia de 1000x.

Utilice las escrituras síncronas cuando sea absolutamente crítico que los datos se almacenen permanentemente antes de continuar y un retraso de 1 segundo en el que puede producirse una pérdida de energía es inaceptable.

Use escrituras asincrónicas en cualquier otro momento.

La razón más probable por la que está viendo este desglose del rendimiento es porque está usando "-o sync" con un sistema de archivos registrado y las barreras activadas (que es el valor predeterminado para ext4).

Aquí es donde la decisión sobre qué hacer para mejorarlo se vuelve muy difícil.

Sin embargo, se reduce principalmente a cuánto confías en tu hardware.

Del soporte (8): "Las barreras de escritura imponen el orden adecuado en disco de las confirmaciones de diario, lo que hace que el uso de cachés de escritura de disco volátil sea seguro, con alguna penalización de rendimiento. El sistema de archivos ext3 no habilita barreras de escritura de forma predeterminada. Asegúrese de habilitar las barreras a menos que sus discos están respaldados por batería de una forma u otra. De lo contrario, corre el riesgo de que se dañe el sistema de archivos en caso de falla de energía ".

Así que acepte el hecho de que el rendimiento "-o sync" es pésimo, o compre caché con respaldo de batería para su controlador y discos SAS realmente buenos, luego apague las barreras usando "-o sync, nobarrier".

Si lo que está utilizando actualmente es un backend de almacenamiento FC o iSCSI de clase empresarial adecuado, entonces supongo que también es seguro hacerlo.

Con todo, ActiveMQ 5.4 usa el backend de almacenamiento KahaDB de manera predeterminada, y ese también tiene su propio registro de transacciones, por lo que tal vez incluso desactivar el registro diario en el nivel del sistema de archivos podría funcionar para usted, pero luego asegúrese de usar "enableJournalDiskSyncs" opción para el backend, y probablemente también desee colocarlo en un dispositivo de bloque separado si aún no lo ha hecho.

(ver http://activemq.apache.org/kahadb.html para más información)

Las escrituras sincrónicas son lentas, es por eso que almacenamos todo en búfer. Eche un vistazo a IOPS en Wikipedia y verá que un HDD típico de 7.200 rpm tiene 75-100 IOPS. Ahora eche un vistazo a las especificaciones técnicas de un Macbook Pro , y tiene un disco duro de 5.400 rpm. Eso es el 75% de rendimiento en el mejor de los casos, por lo que está buscando 50-75 IOPS en el mejor de los casos para la computadora portátil.

Un MQ puede escribir un libro de contabilidad y un libro de contabilidad, que lo lleva a los 20 IOPS que está viendo en el benchmark ActiveMQ.

Tiene dos opciones, probar en tmpfs , es decir, sistema de archivos en memoria, o usar un SSD. Normalmente, los servidores que utilizan escrituras síncronas tendrán una matriz RAID SAS / SCSI significativa con discos de 15,000 rpm. Se agregan discos adicionales a la matriz para mejorar el rendimiento, no para aumentar la capacidad.

En una VM alojada (en VirtualBox) que ejecuta el servidor Ubuntu 11.10 de 64 bits que también usa ext4, obtuvimos los siguientes resultados:

Sync Writes:
 288 writes of size 4096 written in 10.034 seconds.
 28.702412 writes/second.
 0.112118796 megs/second.

En un servidor físico que ejecuta Redhat 5.7 de 64 bits con ext3, se obtuvieron los siguientes resultados:

Sync Writes:
  54987 writes of size 4096 written in 10.001 seconds.
  5498.1504 writes/second.
  21.47715 megs/second.

Me pregunto si el OP también estaba ejecutando esto en una VM o si hay un problema entre ext3 y ext4. Aprecio que podría haber una diferencia entre entornos alojados y no alojados, sin embargo, no esperaba una diferencia tan grande.

Use un tamaño de bloque más grande. ¿Quizás confunde la sincronización / async IO con la IO directa / almacenada?