A sincronização escreve muito devagar. Ubuntu 10.10, 32 bits, ext4

Estou executando o ActiveMQ no meu Macbook Pro que executa o Ubuntu 10.10, 32 bits com uma partição ext4.

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

Se eu ativar a persistência no ActiveMQ, o desempenho cairá muito. Eu testei a mesma coisa em outras máquinas e a diferença é de 2 ordens de magnitude.

Existe uma ferramenta com activeMQ para testar o HD, eis os 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.

O desempenho para gravações de sincronização é s ** t. Deve haver algo mal configurado, mas este é o único aplicativo em que notei um problema de desempenho em HD.

O hdparm lança os 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

O principal fator limitante para E / S síncrona não é a taxa de transferência do disco rígido, mas o tempo que leva para a emissão da gravação e a confirmação do disco. A métrica de desempenho mais relevante para um disco rígido nesse sentido seria o tempo de busca do disco rígido e não a taxa de transferência em circunstâncias ideais.

Além do hardware trabalhar contra você, o mesmo ocorre com o kernel, acho que você poderá ver uma pequena melhoria (embora, provavelmente nem de longe o que você obterá ao fazer E / S assíncrona), se puder otimizar o benchmark (aplicativo) para executado sob a classe de agendamento de E / S em tempo real. Por padrão, os aplicativos serão agendados na classe de melhor esforço, o que provavelmente também aumentará o tempo de espera de suas gravações. Use a classe de agendamento em tempo real por sua conta e risco, pois isso terá efeitos adversos no desempenho de outros aplicativos ao acessar o disco.

Em geral, eu realmente não acho que haja algo terrivelmente errado com o desempenho de gravação síncrona que você está vendo. As E / S síncronas geralmente terão um desempenho horrível em comparação às E / S assíncronas.

Como observação, um rápido google do activemq e io síncrono deu o seguinte :

Por motivos de desempenho, convém transmitir mensagens para o broker o mais rápido possível, mesmo se você estiver usando mensagens persistentes

O planejador de E / S cfq tende a ter um desempenho horrível nesses tipos de testes. Além da sugestão anterior do ionice, convém mudar para o planejador de E / S de prazo final (inicializando com elevator=deadlineou executando for n in /sys/block/sd*/queue/scheduler ; do echo deadline > $n ; donecomo root).

Uma gravação síncrona deve receber de volta uma confirmação de que a gravação foi confirmada (se a confirmação foi um sucesso ou erro) antes de poder retornar por si mesma. Isso ocorre por design e, inerentemente, torna as gravações síncronas muito mais lentas devido aos tempos de alta latência envolvidos com um disco de metal giratório (no cache de ram do disco não conta).

As gravações assíncronas geralmente são gravadas na RAM e o sistema operacional lida com o armazenamento em disco mais tarde (mais tarde, geralmente, meros segundos ou menos (acredito que o ZFS é de 5x / segundo ou a cada 5 segundos)). Os tempos de busca do disco são medidos em ms, enquanto os tempos de busca da RAM são medidos em ns. Essa é uma diferença de 1000x.

Use gravações síncronas quando for absolutamente crítico que os dados sejam armazenados permanentemente antes de continuar e um atraso de 1 segundo em que possa ocorrer perda de energia é inaceitável.

Use gravações assíncronas em todos os outros momentos.

A razão mais provável pela qual você está vendo esse problema de desempenho é porque está usando "-o sync" com um sistema de arquivos com diário e barreiras ativadas (que é o padrão para o ext4).

É aqui que a decisão sobre o que fazer para melhorá-lo se torna muito difícil.

Porém, tudo se resume a quanto você confia no seu hardware.

Do mount (8): "As barreiras de gravação impõem a ordem adequada das confirmações de diário no disco, tornando os caches voláteis de gravação em disco seguros para uso, com alguma penalidade no desempenho. O sistema de arquivos ext3 não habilita barreiras de gravação por padrão. Certifique-se de habilitar barreiras, a menos que seus discos são suportados por bateria de uma maneira ou de outra. Caso contrário, você corre o risco de corrupção do sistema de arquivos em caso de falta de energia. "

Portanto, aceite o fato de que o desempenho "-o sync" é sombrio ou compre um cache com bateria para seu controlador e discos SAS realmente bons e desative as barreiras usando "-o sync, nobarrier".

Se o que você está usando no momento é um back-end de armazenamento FC ou iSCSI de classe empresarial adequado, acho que também é seguro fazer o último.

Em suma, o ActiveMQ 5.4 usa o back-end de armazenamento KahaDB por padrão, e esse também possui seu próprio log de transações, portanto, talvez até desativar o registro no diário no nível do sistema de arquivos possa funcionar para você, mas tenha certeza absoluta de que você usa "enableJournalDiskSyncs" opção para o back-end e você provavelmente deseja colocá-lo em um dispositivo de bloco separado, se ainda não o tiver.

(consulte http://activemq.apache.org/kahadb.html para obter mais informações)

Gravações síncronas são lentas, é por isso que armazenamos tudo em buffer. Dê uma olhada no IOPS na Wikipedia e você verá um HDD típico de 7.200 rpm com 75-100 IOPS. Agora dê uma olhada nas especificações técnicas de um Macbook Pro e ele possui um disco rígido de 5.400 rpm. Isso representa 75% de desempenho, na melhor das hipóteses, para que você consiga 50-75 IOPS na melhor das hipóteses para o laptop.

Um MQ talvez escreva um ledger de dados e um ledger contábil, o que leva você aos 20 IOPS que você vê no benchmark ActiveMQ.

Você tem duas opções, teste no tmpfs , ou seja, sistema de arquivos na memória ou use um SSD. Normalmente, os servidores que usam gravações síncronas terão uma matriz RAID SAS / SCSI significativa com discos de 15.000 rpm. Discos extras são adicionados à matriz para melhorar o desempenho, não para aumentar a capacidade.

Em uma VM hospedada (no VirtualBox) executando o servidor Ubuntu 11.10 de 64 bits também usando ext4, obtivemos os seguintes resultados:

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

Em um servidor físico executando o Redhat 5.7 de 64 bits usando o ext3, foram obtidos os seguintes resultados:

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

Gostaria de saber se o OP estava executando isso em uma VM também ou se há um problema entre ext3 e ext4. Compreendo que poderia haver uma diferença entre ambientes hospedados e não hospedados, mas não esperava uma diferença tão grande.

Use um tamanho de bloco maior. Talvez você esteja confundindo E / S sincronizada / assíncrona com E / S direta / em buffer?