Melhorando o desempenho do RAID

4

Acabei de instalar um LSI 9260-i8, usando dois drives virtuais, o primeiro composto de 4 SSDs, o segundo de 4 HDDs. Obviamente, a ideia é obter um melhor desempenho, mantendo alguma segurança e muita capacidade de armazenamento.

Os SSDs são ótimos e essa matriz é ridiculamente rápida ao lidar com arquivos pequenos e relativamente grandes. Os HDDs hospedam principalmente arquivos enormes (500MB-30GB). Pretende ser o principal recurso de armazenamento de longo prazo, enquanto o SSD é destinado apenas a arquivos operacionais e armazenamento de curto prazo. Isso significa que muitas vezes os arquivos serão movidos da matriz SSD para a matriz HDD.

O problema é que o desempenho diminui muito rapidamente após o primeiro gig ou mais de uma grande operação ser gravada. Ele começa em torno de 250MB / s, o que não é metade do desempenho de gravação para uma matriz RAID 5 de apenas 5 HDDS, mas a cópia que acabei de fazer, consistindo de 4 arquivos totalizando 12 GB, diminuiu gradualmente para um mínimo de 35MB / s.

Agora eu acho que o conselho de alguém dependeria de muitos metainfo, então aqui vai:

  • A placa LSI não tem uma BBU (ainda), portanto, a gravação está desabilitada.
  • Os HDDs são drives WD15EARS de 2TB. Obviamente, estes não são os discos rígidos mais rápidos, mas 200MB / s não é muito para pedir, eu acho.
  • Os SSDs são drives de 60 GB da OCZ Vertex 2.
  • Não pense que é relevante, mas os HDs têm o tempo de desaceleração aumentado para 5 minutos em vez dos 8 segundos normais
  • As unidades mostram-se íntegras no Storage Manager, não há erros de observação nos registros
  • Como eu disse, os SDDs são realmente rápidos, com velocidade de leitura de até 1100MB / s, o que não parece ser o gargalo.
  • A cópia parece pausar, ela será executada rapidamente, parará, será executada novamente por cerca de 500 MB, etc, resultando em uma velocidade geral menor.
  • Ao criar o array HDD, usei um tamanho de faixa de 512Kb. Isso é enorme, mas estou esperando apenas grandes arquivos enormes nessa matriz. Eu prefiro não mudar isso agora, pois isso destruiria os dados existentes e eu não tenho um backup (ainda)
  • O sistema operacional é o Ubuntu 10.04 (64 bits)
  • Placa-mãe Asus WS Revolution (é uma estação de trabalho), 24 GB de RAM ECC, Xeon W3570 em estoque de 3,2 GHz
  • A placa LSI é inserida no primeiro slot PCIe (para evitar a latência introduzida pelo NF200)
  • O sistema é perfeitamente estável
  • A matriz HDD foi formatada usando "mkfs.ext4 -b 4096 -E stride = 128, stripe-width = 384 -L" DATA "/ dev / sdb"
  • fstab não inclui data = writeback, nem noaccess, embora eu não ache que isso deva ser um problema que influencia os arquivos grandes

Qualquer e todo conselho é apreciado.

    
por Jake 05.12.2010 / 20:06

3 respostas

1

Eu acho que "O cartão LSI não tem um BBU (ainda), então o write-back está desativado" é o gargalo.

Se você tiver o UPS - ative o Write Back.

Se não - tente obter a BBU.

Se você não puder - pode arriscar a consistência dos dados na unidade virtual perdendo os dados armazenados em cache em caso de sobrecarga de energia se ativar o recurso Write-Back ou se fixar nessas velocidades usando o cache de gravação.

Mesmo se você alinhar a partição ao volume lógico (que normalmente é feito automaticamente pela maioria dos sistemas operacionais modernos) e formatar o volume com tamanho de bloco / bloco otimizado grande o suficiente (acho que deve ser 2mb no seu caso) para obter todos as unidades para processar a única solicitação de E / S, não acho que você conseguirá uma diferença de desempenho de gravação muito grande.

Porque o desempenho de gravação do RAID5 é um processo muito excessivo. E como é escrever através do processador XOR não tenho os dados completos em cache para realizar os cálculos de paridade em tempo real eu acho

Com cache habilitado para Write-Back em 4x320gb hdds 515kb stip tamanho RAID 5 eu recebo média 250-350 MB / s velocidade de gravação escrevendo grandes arquivos sequenciais ou média de 150 MB / s copiando arquivos grandes dentro do volume virtual. (Eu ainda não tenho BBU, mas eu tenho e velho apc 700VA ups inteligentes, então eu acho que é o suficiente para minimizar os surtos de energia e eventual perda de cache para um monte)

Estamos discutindo 100% aleatório, 100% sequencial ou algum padrão misto? Estou tendo altas velocidades quando leio, escrevo ou copio arquivos grandes de / para / para meu array. Por outro lado, como já foi dito, as gravações aleatórias (leituras) são muito menores, variando de menos de 1 mb / s a velocidades médias de 190 mb / s, dependendo do tamanho dos arquivos e / ou dos tamanhos das solicitações. Principalmente sob a faixa de 20mb / s em uso diário pequeno de tamanho / arquivo. Portanto, depende muito das aplicações nas transferências aleatórias da vida real. Como eu estou usando o sistema operacional Windows, meus volumes são bastante fragmentados e fragmentados, e para grandes arquivos, grandes operações como copiar de / para são muito rápidas

E uma sugestão como solução para velocidades lentas de leitura / gravação aleatórias de hdds normais - se você chegar ao ponto de reconfigurar toda a sua configuração de controlador, por que você não considera o CacheCade usando 1 ou 2 dos SSDs para nenhum cache de invasão dependente de energia (algo como as invasões híbridas adaptec) e o restante para sua unidade OS / app como você está usando agora? Desta forma, você deve ser capaz de aumentar a velocidade do seu volume RAID 5, mesmo com a escrita, porque acho que a gravação real para os hdds físicos deve ocorrer em segundo plano e como você está usando o cache de gravação (sem cache do controlador de bordo) e o ssds como cache, em vez disso, eu acho que você deve estar livre de preocupações com redefinições do sistema. Mas, para obter informações reais e concretas sobre como funciona o cachecade, leia a documentação do lsi e até pergunte ao suporte técnico do LSI, pois ainda não tive a chance de usá-lo.

    
por 05.12.2010 / 22:10
4

TomTom já respondeu, mas um pouco mais de contexto para a resposta pode ser útil.

Você está usando o RAID 5. O RAID 5 tem problemas de desempenho bem conhecidos ao gravar dados.

Para cada faixa do RAID 5 existe um bloco de dados de paridade, e os blocos de dados de paridade estão espalhados por todos os discos no modo round-robin. Para cada gravação em um array RAID 5, o controlador precisa recalcular as informações de paridade e, em seguida, gravar o novo bloco de paridade no disco. Uma citação aqui ilustra isso (com relação a uma atualização parcial de tarja, mas o mesmo princípio se aplica):

If you [...] modify the data block it recalculates the parity by subtracting the old block, and adding in the new version. Then in two separate operations it writes the data block followed by the new parity block. To do this it must first read the parity block from whichever drive contains the parity for that stripe block and reread the unmodified data for the updated block from the original drive. This read-read-write-write is known as the RAID5 write penalty since these two writes are sequential and synchronous the write system call cannot return until the reread and both writes complete, [...]

Cerca de 35 MB / s soam à direita para um único disco rígido SATA fazendo um bom número de E / S aleatórios mais ou menos devido à distribuição RAID 5, e as velocidades de gravação RAID 5 reais estão em torno de ~ 1 desempenho de disco para matrizes menores. Portanto, é um desempenho mais ou menos esperado; que copia mais rápido no início é provavelmente o cache do sistema operacional em jogo.

Obter uma unidade de backup de bateria e ativar o cache de gravação não é uma solução definitiva. Você escreve que muitas vezes você copia arquivos grandes (> 1 GB). O cache de escrita BBU + ajuda tremendamente com gravações aleatórias de arquivos pequenos, mas menos com gravações sequenciais grandes (porque o buffer no controlador eventualmente fica cheio).

Se você deseja ter um bom desempenho de gravação, a resposta geralmente é RAID 10 .

E, por último, quando você cria suas partições, deve tomar cuidado para garantir que os limites das partições se alinhem com os limites da faixa do array.

    
por 05.12.2010 / 22:19
0

Hmpf. Algumas noções básicas.

It starts at around 250MB/s, which isn't half bad write performance for an RAID 5 array of only 5 HDDS

Verificação da realidade: A velocidade de gravação de qualquer RAID 5 é lenta, limitada à velocidade de wirte de ONE DISC. 3, 5, 15 sics não faz diferença nas gravações.

The HDDs are WD15EARS 2TB drives. Obviously these aren't the fastest HDDs out there, but a consistent 200MB/s isn't too much to ask I think.

Verificação da realidade: é muito alto para um disco de usuário final em uma situação aleatória de E / S, e é isso que você demonstra. Até 200MB RAW é muito alto. Mas se você adicionar todas as operações necessárias para um Raid 45 (consulte a Wikipedia), é engraçado pedir por isso. Você quer velocidade? Obtenha discos RÁPIDOS e mude para um RAID 10.

Don't think it's relevant, but the HDDs have the spin down time upped to 5 minutes instead of the normal 8 seconds

8 segundos de tempo de desaceleração para um HDD? Onde diabos você conseguiu esse número? Isso é muito lento, muito mau .. Spin up deve ser evitado quando mais operações acontecem em um curto espaço de tempo - falamos minutos. 5 minutos é muito baixo. 8 segundos é suicida.

No final do dia, você espera muito pouco - você ficou barato no RAID 5 e nunca fez nenhuma verificação da realidade. Os números estão bem ok.

Coisas para checK:

  • As unidades suportam o NCQ? É usado?
  • Quão cara é uma BBU? Muito em movimento para escrever de volta em vez de escrever pode fazer uma melhoria HUGH. No momento, você não é otimizável nos padrões de E / S para gravações, porque nada entre pode armazenar em cache.

Além disso, obter discos MAIS RÁPIDOS e se afastar do RAID 5 são suas únicas opções. Fazer algumas verificações iniciais em matemática também ajudará você - praticamente sua suposição de que a velocidade que você deve ter é terrivelmente baixa.

    
por 05.12.2010 / 21:23