Software RAID 5 e 6 tamanho da faixa: por que menor é menos eficiente?

Question

Eu li aqui e, em seguida, que o tamanho da pequena faixa é ruim para o software (e talvez o hardware) RAID 5 e 6 no Linux. Os benchmarks raros que vi concordam plenamente com isso.
Mas a explicação dada por todos é que isso induz mais movimentos da cabeça. Eu não entendo como um pequeno tamanho da tira leva a mais movimentos da cabeça.

Digamos que temos uma configuração do RAID 6 com 4 unidades SAS locais.

caso 1: escrevemos 1 Gb de dados sequenciais
O programa pede ao kernel para escrever os dados, então o kernel divide-o para combinar com o tamanho da distribuição e calcula cada pedaço (dados e / ou paridade) a ser gravado em cada disco. O kernel é capaz de gravar os 4 discos ao mesmo tempo (com o controlador de disco apropriado). Se os dados gravados não estiverem totalmente alinhados com as distribuições, o kernel terá apenas que ler as primeiras e últimas faixas antes de calcular os dados resultantes. Todas as outras faixas serão sobrescritas sem nenhum cuidado com dados anteriores.
Como essa computação é feita muito mais rápido do que a taxa de transferência de discos, cada bloco é gravado ao lado do anterior em cada disco sem pausa. Então, isso é basicamente uma gravação seqüencial em 4 discos.
Como um pequeno tamanho da faixa poderia retardar isso?

caso 2: escrevemos 1.000.000 x 1 kb de dados em locais aleatórios
1 kb é menor que o tamanho da faixa (o tamanho da faixa comum é atualmente de 512 kb)
O programa pede ao kernel para escrever alguns dados, depois alguns outros dados, e novamente algum outro, etc. Para cada escrita, o kernel precisa ler os dados atuais no disco, computar o novo conteúdo e gravá-lo de volta no disco. Em seguida, as cabeças movem-se para outro lugar e a operação é repetida mais 999.999 vezes.
Quanto menor o tamanho da faixa, mais rápido os dados são lidos / computados / gravados. Idealmente, um tamanho de faixa de 4 kb deve ser o melhor com discos modernos (se corretamente alinhados).

Então, mais uma vez, como um pequeno tamanho de faixa pode atrasar isso?

    

Answer 1

Eu falo sobre o software Linux RAID. Quando você procura no código , vê que o driver md não está totalmente otimizado: quando várias solicitações contíguas são feitas , o driver md não se funde em um maior. Isso leva a sobrecarga enorme em algumas situações comuns.

Grandes leituras ou gravações são otimizadas: elas são reduzidas a várias solicitações iguais ao tamanho da faixa e tratadas de maneira ideal.

Se a leitura ou gravação for de 2 faixas, o driver md faz o trabalho corretamente: tudo é tratado em uma operação.

Com pequenas leituras, não há problema porque os dados estão no cache do kernel após a primeira leitura. Portanto, várias leituras contíguas geram apenas uma pequena sobrecarga para CPU e memória, em comparação com a largura de banda de disco lenta. Por exemplo, eu leio 1 Gb de dados a 100 bytes de cada vez: o kernel primeiro o transforma em uma leitura de 512 kb porque esse é o tamanho mínimo de E / S (se o tamanho da faixa for de 512 kb). Então os próximos 100 bytes já estarão no cache do kernel. É exatamente a mesma coisa que ler de uma partição não RAID.

Com gravações menores que o tamanho da faixa, o driver md primeiro lê a tarja completa na memória, depois sobrescreve na memória com os novos dados, calcula o resultado se a paridade for usada (principalmente RAID 5 e 6) e grava. aos discos.
Por exemplo, eu escrevo 1 Gb de dados 100 bytes de cada vez: o kernel primeiro lê a faixa de 512 kb, sobrescreve as partes necessárias na memória, computa o resultado se a paridade estiver envolvida, depois grava no disco. Ao escrever os próximos 100 bytes, apenas o "read the 512 kb stripe" é evitado porque os dados estão no cache do kernel. Portanto, temos uma pequena sobrecarga para sobrescrever na memória e na paridade de computação, mas uma grande sobrecarga, porque os dados são gravados novamente na mesma faixa. O código do kernel aqui não está otimizado.

Eu não gravei o suficiente para entender por que essas gravações repetidas não são armazenadas corretamente no cache, e os dados descarregados no disco somente após alguns segundos (portanto, apenas uma vez por faixa). Se eles forem armazenados em cache, a sobrecarga será apenas um pouco de CPU e memória, mas meus próprios benchmarks mostram que a CPU permanece abaixo de 10%, e a E / S é o gargalo.

Se as gravações foram otimizadas, o tamanho mínimo da faixa será sempre o melhor: o RAID 6 com 4 discos com 4 k setores levará a faixas de 8 kb, e será o melhor para leitura e gravação em todas as possíveis carga.

    

Answer 2

Até onde eu sei, o problema nunca teve a ver com movimentos da cabeça e tudo simplesmente devido a mais despesas gerais. Para uma determinada leitura ou gravação sequencial, um tamanho de faixa de 4KB resulta em dezesseis vezes mais operações do que um tamanho de faixa de 64 KB. Mais tempo de CPU, mais largura de banda de memória, mais comutadores de contexto, mais E / Ss, mais trabalho para o planejador de E / S do kernel, mais mesclagens para computar e assim por diante, portanto, mais latência por E / S.

Lembre-se de muitos aplicativos emitem E / S com uma profundidade de fila de 1, portanto, talvez você nem sempre consiga mesclar 16 solicitações sequenciais de 4KB a uma solicitação de 64 KB para o disco.

Além disso, se você observar um benchmark de disco típico da ATTO como este:

Vocêpodeverqueodisconãopodesequerlerseqüencialmenteemvelocidademáximaatéqueasleiturassejamfeitasemblocosde128KBoumaiores.

ATomshardwaretemumarevisãobastanteabrangentedosefeitosdotamanhodafaixaaqui:

link

    

Answer 3

Como em todas as coisas, há um meio feliz. Mas eu sugiro dar uma olhada no RAID2 e no RAID3 - ambos os tipos que são raramente usados - para entender melhor a natureza do problema.

No entanto, isso basicamente se resume à latência do IO e da transferência simultânea de dados. Toda operação IO de leitura tem uma sobrecarga de vários milésimos de segundo para que as cabeças procurem e a unidade gire.

Se tivermos pedaços maiores de dados, pagamos essa penalidade com menos frequência. É muito parecido com uma forma mais bruta de pré-busca - por causa dessa sobrecarga, geralmente é uma boa ideia pré-buscar vários trechos de dados quando um é solicitado, simplesmente porque é estatisticamente provável que você precise disso de qualquer maneira.

Mas principalmente - é uma operação de ajuste tuning do que uma regra difícil - você deve definir o tamanho do bloco com base na carga de trabalho que estiver enviando para o disco. Se sua carga de trabalho for mista ou aleatória, ficará cada vez mais difícil fazer isso. Pedaços maiores significam mais taxa de transferência com menos operações de E / S e, em geral, suas operações de E / S são o fator limitante na velocidade da sua unidade e, portanto, é geralmente benéfico ter solicitações maiores.

Para casos de uso específicos (como bancos de dados!), isso pode não ser aplicável.