La synchronisation écrit très lentement. Ubuntu 10.10, 32 bits, ext4

J'utilise ActiveMQ sur mon Macbook Pro qui exécute Ubuntu 10.10, 32 bits avec une partition 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 j'active la persistance dans ActiveMQ, les performances chutent terriblement. J'ai testé la même chose sur d'autres machines et la différence est de 2 ordres de grandeur.

Il existe un outil avec activeMQ pour tester la HD, voici les résultats:

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.

Les performances des écritures de synchronisation sont s ** t. Il doit y avoir quelque chose de mal configuré, mais c'est la seule application où j'ai remarqué un problème de performances HD.

hdparm renvoie les valeurs attendues:

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

Le principal facteur limitant pour les E / S synchrones n'est pas le débit de votre disque dur, mais plutôt le temps qu'il faut entre le moment où l'écriture est émise et celle qui est validée sur disque. La mesure de performance la plus pertinente pour un disque dur à cet égard serait le temps de recherche du disque dur et non son débit dans des circonstances idéales.

En plus du matériel qui fonctionne contre vous, le noyau aussi, je suppose que vous pourriez voir une petite amélioration (bien que, probablement loin de ce que vous obtiendrez en faisant des asynchrones IO) si vous pouvez ioniser le benchmark (application) pour exécuté sous la classe de planification d'E / S en temps réel. Par défaut, les applications seront planifiées dans la classe du meilleur effort, ce qui augmentera probablement aussi le temps d'attente de vos écritures. Utilisez la classe de planification en temps réel à vos propres risques, car cela aura des effets négatifs sur les performances des autres applications lors de l'accès au disque.

En général, je ne pense pas vraiment qu'il y ait quelque chose d'horriblement mauvais avec les performances d'écriture synchrone que vous voyez. Les E / S synchrones fonctionneront généralement horriblement par rapport aux E / S asynchrones.

En remarque, un rapide google d'activemq et d'io synchrone a donné ce qui suit :

Pour des raisons de performances, vous souhaiterez peut-être diffuser des messages vers le courtier le plus rapidement possible, même si vous utilisez des messages persistants.

Le planificateur d'E / S cfq a tendance à fonctionner horriblement dans ce genre de tests. En plus de la suggestion d'ionice plus tôt, vous voudrez peut-être essayer de passer au planificateur d'E / S d'échéance (soit en démarrant avec elevator=deadlineou en faisant en for n in /sys/block/sd*/queue/scheduler ; do echo deadline > $n ; donetant que root).

Une écriture synchrone doit recevoir en retour un accusé de réception que l'écriture a été validée (que la validation ait été un succès ou une erreur) avant de pouvoir se retourner. Ceci est de par leur conception, et rend intrinsèquement les écritures synchrones beaucoup plus lentes en raison des temps de latence élevés impliqués avec un disque métallique tournant (sur le cache de la mémoire RAM du disque ne compte pas).

Les écritures asynchrones sont généralement écrites sur la RAM et le système d'exploitation traite de les valider sur le disque plus tard (plus tard, généralement en quelques secondes ou moins (je crois que ZFS est 5x / seconde, ou toutes les 5 secondes)). Les temps de recherche de disque sont mesurés en ms tandis que les temps de recherche de RAM sont mesurés en ns. C'est une différence de 1000x.

Utilisez des écritures synchrones lorsqu'il est absolument essentiel que les données soient stockées en permanence avant de continuer et qu'un délai de 1 seconde où une perte d'alimentation peut se produire est inacceptable.

Utilisez les écritures asynchrones à tout autre moment.

La raison la plus probable pour laquelle vous voyez cette dégradation des performances est que vous utilisez "-o sync" avec un système de fichiers journalisé et des barrières activées (ce qui est la valeur par défaut pour ext4).

C'est là que la décision sur ce qu'il faut faire pour l'améliorer devient très difficile.

Cela se résume surtout à la confiance que vous accordez à votre matériel.

Depuis le montage (8): "Les barrières d'écriture imposent un bon ordre sur disque des validations de journal, ce qui rend les caches d'écriture de disque volatiles sûrs à utiliser, avec une certaine pénalité de performance. Le système de fichiers ext3 n'active pas les barrières d'écriture par défaut. Assurez-vous de les activer sauf si vos disques sont alimentés par batterie d'une manière ou d'une autre. Sinon, vous risquez de corrompre le système de fichiers en cas de panne de courant. "

Donc, soit acceptez le fait que les performances "-o sync" sont lamentables, soit achetez un cache avec batterie pour votre contrôleur et de très bons disques SAS, puis désactivez les barrières en utilisant "-o sync, nobarrier".

Si ce que vous utilisez actuellement est un backend de stockage FC ou iSCSI de classe entreprise, je suppose que vous pouvez également le faire.

Dans l'ensemble, ActiveMQ 5.4 utilise le backend de stockage KahaDB par défaut, et que celui-ci a son propre journal de transactions également, donc peut-être même que la journalisation au niveau du système de fichiers pourrait fonctionner pour vous, mais assurez-vous ensuite absolument que vous utilisez "enableJournalDiskSyncs" option pour le backend, et vous voudrez probablement le mettre sur un périphérique de bloc séparé également si vous ne l'avez pas encore fait.

(voir http://activemq.apache.org/kahadb.html pour plus)

Les écritures synchrones sont lentes, c'est pourquoi nous tamponnons tout. Jetez un oeil à IOPS sur Wikipedia et vous verrez un disque dur typique à 7200 tr / min avec 75 à 100 IOPS. Jetez maintenant un coup d'œil aux spécifications techniques d'un Macbook Pro , et il a un disque dur de 5400 tr / min. C'est 75% de performances au mieux, donc vous regardez au mieux 50-75 IOPS pour l'ordinateur portable.

Un MQ écrit peut-être un grand livre de données et un grand livre comptable, ce qui vous amène aux 20 IOPS que vous voyez dans le benchmark ActiveMQ.

Vous avez deux options, tester sur tmpfs , c'est-à-dire le système de fichiers en mémoire, ou utiliser un SSD. Normalement, les serveurs utilisant des écritures synchrones auront une matrice RAID SAS / SCSI importante avec des disques de 15 000 tr / min. Des disques supplémentaires sont ajoutés à la baie pour améliorer les performances et non pour augmenter la capacité.

Sur une machine virtuelle hébergée (dans VirtualBox) exécutant le serveur Ubuntu 11.10 64 bits utilisant également ext4, nous avons obtenu les résultats suivants:

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

Sur un serveur physique exécutant Redhat 5.7 64 bits en utilisant ext3, les résultats suivants ont été obtenus:

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

Je me demande si l'OP fonctionnait également dans une machine virtuelle ou s'il y avait un problème entre ext3 et ext4. J'apprécie qu'il puisse y avoir une différence entre les environnements hébergés et non hébergés, mais je ne m'attendais pas à une telle différence.

Utilisez une taille de bloc plus grande. Êtes-vous peut-être en train de confondre les E / S de synchronisation / async avec les E / S directes / tamponnées?