A ativação do cache de write-back do controlador RAID pode prejudicar o desempenho geral?

Question

Eu tenho uma configuração RAID 10 de 8 unidades conectada a uma Adaptec 5805Z, executando o Centos 5.5 e o planejador de prazos.

Um teste de leitura% dd básico mostra 400mb / seg, e um teste de gravação dd básico mostra o mesmo.

Quando eu corro os dois simultaneamente, vejo a velocidade de leitura cair para ~ 5mb / seg enquanto a velocidade de gravação permanece mais ou menos os mesmos 400mb / seg. A saída de iostat -x , como seria de se esperar, mostra que muito poucas transações de leitura estão sendo executadas enquanto o disco é bombardeado com gravações.

Se eu desativar o cache de writeback do controlador, não vejo uma divisão de 50:50, mas vejo uma melhoria acentuada, em torno de 100mb / s de leituras e 300mb / s de gravações. Eu também descobri que se eu diminuir a configuração nr_requests na fila da unidade (algo em torno de 8 parece ótimo), eu posso acabar com leituras de 150mb / s e gravações de 150mb / s; ie. uma redução no throughput total, mas certamente mais adequada para minha carga de trabalho.

Este é um fenômeno real? Ou o meu teste sintético é muito simplista?

O motivo pelo qual isso pode acontecer parece claro o suficiente, quando o agendador muda de leituras para gravações, ele pode executar muitos pedidos de gravação porque todos eles simplesmente aterram no cache dos controladores, mas devem ser executados em algum momento. Eu diria que as gravações reais do disco estão ocorrendo quando o agendador começa a tentar executar leituras novamente, resultando em muito poucas solicitações de leitura sendo executadas.

Essa parece ser uma explicação razoável, mas também parece uma grande desvantagem em usar o cache de write-back em um sistema com cargas de gravação não triviais. Eu tenho procurado discussões em torno disso durante toda a tarde e não encontrei nada. o que estou perdendo?

    

Answer 1

Bem, um dd básico provavelmente não é a melhor maneira de medir o throughput da unidade. Não é uma carga realista. No entanto, se você executar dd , passe o sinalizador oflag=direct na linha de comando para eliminar o efeito do cache do sistema de arquivos. Veja também: Como medir a taxa de transferência de disco? para sugestões sobre como medir cargas de trabalho.

Acho que sua escolha de agendador está tendo um efeito maior nos seus resultados do que em qualquer outra coisa. Para controladores RAID com bateria ou cache de cache flash (cache de gravação), eu costumava executar com o deadline scheduler, mas agora uso o noop scheduler se o cache for de 512 MB ou 1 GB. Você pode trocar o agendador na hora, então tente os testes com o algoritmo noop e oflag=direct e veja como os resultados se parecem.

Você executou bonnie++ ou iozone ?

    

Answer 2

Se você planeja usar iozone , veja algumas maneiras de verificar seu desempenho. Eles são melhores que dd , pois permitem o tipo de teste que você está procurando.

iozone -s 4G -a -i 0 -i 1 -i 2

Isso executará testes com um conjunto de dados de 4 GB ( -s 4G ), usando um tamanho de registro variável e executando o teste de gravação ( -i 0 ), o teste de leitura ( -i 1 ) e a leitura / gravação aleatória teste ( -i 2 ). Selecionar o tamanho do arquivo é crítico. Se você escolher uma que caiba na RAM, seus resultados serão baseados mais no cache de arquivos do que no desempenho de armazenamento real. Portanto, se você tiver um servidor com 4 GB de RAM, teste com um tamanho de arquivo maior do que isso.

No entanto, se você tiver quantidades obscenas de RAM (tenho um servidor com 12 GB) e quiser que seus testes sejam concluídos em menos de algumas horas, é possível fornecer a opção -I , que informa ao iozone para definir O_DIRECT e ignorar o sistema de arquivos cache. Você terá o desempenho real do subsistema de armazenamento lá.

Você também pode fazer testes que verificam o acesso simultâneo.

iozone -s 128M -r 4k -t 32 -i 0 -i 1 -i 2

Isso executará 32 encadeamentos simultâneos de 128 MB executando os mesmos testes do comando anterior, mas com um tamanho de registro em 4K ( -r 4k ). O conjunto de trabalho é de 4 GB, mas alguns dos arquivos caberão no cache de arquivos. Dependendo do que você está fazendo com esse armazenamento, isso pode ser um teste mais preciso do seu desempenho provável. Como antes, o parâmetro -I irá definir O_DIRECT.

iozone -s 128M -r 4k -l 16 -u 32 -i 0 -i 1 -i 2

Isso faz o mesmo que o comando acima, mas executa uma série de testes começando com 16 threads e aumentando para 32 threads.