A sincronização é muito lenta. Ubuntu 10.10, 32 bits, ext4

Question

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 cai terrivelmente. Eu testei a mesma coisa em outras máquinas e a diferença é de 2 ordens de magnitude.

Existe uma ferramenta com o activeMQ para testar o HD, aqui estão 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 das gravações de sincronização é s ** t. Deve haver algo mal configurado, mas esse é o único aplicativo em que notei um problema de desempenho em HD.

hdparm gera 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

    

Answer 1

O principal fator limitante para o IO síncrono não é a taxa de transferência de seu disco rígido, mas sim o tempo que leva quando a gravação é emitida e está sendo confirmada no disco. A métrica de desempenho mais relevante para um disco rígido a esse respeito 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 kernel também, eu acredito que você possa ver uma pequena melhoria (embora, provavelmente nem de perto o que você conseguirá fazendo IOs assíncrono) se você puder ionizar o benchmark ( aplicativo) para executar sob a classe de agendamento de E / S em tempo real. Por padrão, os aplicativos serão agendados na melhor classe de 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. A E / S síncrona em geral tem um desempenho horrível em comparação com a E / S assíncrona.

Como um destaque, um rápido google de activemq e io síncrono deram o seguinte :

For performance reasons you may wish to stream messages to the broker as fast as possible even if you are using persistent messages

    

Answer 2

O planejador de E / S cfq tende a apresentar um desempenho horrível nesses tipos de testes. Além da sugestão de ionice anterior, você pode tentar alternar para o agendador de E / S de prazo final (inicializando com elevator=deadline ou fazendo for n in /sys/block/sd*/queue/scheduler ; do echo deadline > $n ; done como root).

    

Answer 3

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

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

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

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

    

Answer 4

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

Um QM talvez esteja escrevendo um livro de dados e um livro contábil, que leva você aos 20 IOPS que você está vendo no benchmark ActiveMQ.

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

    

Answer 5

Em uma VM hospedada (no VirtualBox) executando o servidor Ubuntu 11.10 de 64 bits também usando o 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, os seguintes resultados foram obtidos:

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.

    

Answer 6

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

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

Isso se resume a quanto você confia no seu hardware.

Do monte (8): "Barreiras de gravação reforçam o ordenamento em disco dos envios de diário, tornando os caches de gravação de disco voláteis seguros de usar, com alguma penalidade de desempenho. O sistema de arquivos ext3 não habilita barreiras de gravação por padrão. Certifique-se de ativar barreiras a menos que seus discos sejam apoiados por bateria. De qualquer forma, você corre o risco de corrupção do sistema de arquivos em caso de falta de energia. "

Então, aceite o fato de que o desempenho "-o sync" é lúgubre, ou compre cache com bateria para o seu controlador e realmente bons discos SAS, depois desligue as barreiras usando "-o sync, nobarrier ".

Se o que você está usando atualmente é um back-end de armazenamento FC ou iSCSI corporativo adequado, então acho que também é seguro fazer o último.

Em suma, o ActiveMQ 5.4 usa o backend de armazenamento KahaDB por padrão, e esse também possui seu próprio log de transações, então talvez até mesmo tornar o journaling off no nível do sistema de arquivos funcione para você, mas então certifique-se de usar opção "enableJournalDiskSyncs" para o backend, e você provavelmente também deseja colocá-lo em um dispositivo de bloco separado, se ainda não o tiver feito.

(veja link para saber mais)

    

Answer 7

Use um tamanho de bloco maior. Você pode confundir E / S sincronizado com IO direto / buffer?