ti-enxame.com

Sync escreve muito lento. 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 habilitar 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:

[email protected]:~/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.

Desempenho para gravações de sincronização é s ** t. Deve haver algo mal configurado, mas este é o único aplicativo onde eu notei um problema de performance HD.

hDPARM lança valores esperados:

[email protected]:~$ 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
8
Iker Jimenez

O principal fator limitante para síncrono IO não é transferência de seu disco rígido, mas o tempo que demora quando a gravação é emitida e está sendo comprometida com o disco. A métrica de desempenho mais relevante para um Harddrive a este respeito seria o tempo de busca do disco rígido e não é taxa de transferência em circunstâncias ideais.

Além do hardware trabalhando contra você, então é o kernel, eu estou supondo que você pode ver uma pequena melhoria (embora, provavelmente nem perto do que você vai conseguir de fazer async io) se você puder ionice o benchmark (aplicativo) para Executar sob a classe Realtime IO Agendando a classe. Por padrão, os aplicativos serão agendados sob a classe de melhor esforço, que provavelmente também irá adicionar ao tempo de espera de suas gravações. Use a classe de agendamento em tempo real no seu risco próprio, pois terá efeitos adversos em outros aplicativos de desempenho ao acessar o disco.

Em geral, eu realmente não acho que há algo terrivelmente errado com o desempenho de gravação síncrona que você está vendo. Síncrono IO Em geral realizará terrivelmente comparado ao io assíncrono.

Como uma nota lateral, um rápido google do ActiveMQ e Io Synchronous deram o seguindo :

Por motivos de desempenho, você pode desejar transmitir mensagens para o corretor o mais rápido possível, mesmo se estiver usando mensagens persistentes

7
Kjetil Jorgensen

O agendador CFQ E/S tende a realizar terrivelmente nesses tipos de testes. Além da sugestão de ionice anterior, você pode querer tentar mudar para o planejador de E/S de prazo (ou inicializando com elevator=deadline ou fazendo for n in /sys/block/sd*/queue/scheduler ; do echo deadline > $n ; done como root).

3
Steven Pritchard

Uma escrita síncrona deve receber de volta um reconhecimento de que a gravação foi confirmada (se o commit era um sucesso ou erro) antes que ele possa se devolver. Isso é por design, e inerentemente faz grava síncrono muito mais lento devido aos altos tempos de latência envolvidos com um disco de metal giratório (no cache de RAM de disco não conta).

As gravações assíncronas são geralmente escritas para RAM e o sistema operacional lida com a cometimento ao disco mais tarde (mais tarde, geralmente sendo meros segundos ou menos (acredito que o ZFS é 5x/segundo ou a cada 5 segundos)). Os tempos de busca em disco são medidos no MS enquanto RAM Os tempos de busca são medidos no NS. Isso é uma diferença de 1000x.

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

Usar escreve assíncrona em todas as outras vezes.

3
bahamat

A razão mais provável que você está vendo este aviso de desempenho é porque você está usando "-O Sync" com um sistema de arquivos de diário e barreiras ativado (que é o padrão para ext4).

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

Em sua maioria se resume a quanto você confia em seu hardware.

Do Mount (8): "As barreiras de gravação imponha a ordem adequada no disco do diário, tornando o disco volátil escreva coqueiros seguros para usar, em alguma penalidade de desempenho. O sistema de arquivos ext3 não permite habilitar as barreiras, a menos que Seus discos são apoiados por bateria ou outro. Caso contrário, você arrisca a corrupção do sistema de arquivos em caso de falha de energia. "

Então, aceite o fato "-O Sync" O desempenho é desanimado, ou comprar cache de backup de bateria para o seu controlador e realmente Bom SAS discos, depois desligue as barreiras usando "-o Sync, Nobrrier".

Se o que você está usando é um backend de armazenamento adequado de classe empresarial-classe ou iSCSI, então eu acho que você está seguro para fazer o último também.

Todos em todos os, o ActiveMQ 5.4 usa o backend de armazenamento do Kahadb por padrão, e esse tem seu próprio log de transações, então talvez até mesmo ativar o registro do registro no nível do sistema de arquivos poderá funcionar para você, mas, em seguida, certifique-se de que você usa "EnableJournaldiskSyncs" Opção para o backend, e você provavelmente deseja colocá-lo em um dispositivo de bloco separado, também se você ainda não tiver.

(ver http://activemq.apache.org/kahadb.html para mais)

2
Grega Bremec

Escreve síncronas são lentas, é por isso que buffer tudo. Dê uma olhada em IOPS na Wikipedia e você verá um típico 7.200 RPM HDD tem 75-100 IOPS. Agora dê uma olhada no especfres técnicas de um MacBook Pro , e tem um HDD de 5.400 rpm. Isso é 75% de desempenho, na melhor das hipóteses, então você está olhando para 50-75 Iops na melhor das hipóteses para o laptop.

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

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

1
Steve-o

Em um hospedado VM (in virtualbox) executando o Ubuntu 11.10 Server 64 bit 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 em execução RedHat 5.7 64 bit usando 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.

Eu me pergunto se o op estava executando isso em um VM também ou se houver um problema entre ext3 e ext4. Eu aprecio que poderia haver uma diferença entre ambientes hospedados e não hospedados, não esperava uma diferença tão grande.

1
Alex