Linux - ajuste de controlador RAID de hardware real (scsi e cciss)

28

A maioria dos sistemas Linux que eu gerencio controlam os RAIDs de hardware (principalmente HP Smart Array ). Todos eles estão executando o RHEL ou o CentOS.

Estou à procura de sintetizadores do mundo real para ajudar a otimizar o desempenho de configurações que incorporam controladores RAID de hardware com discos SAS (Smart Array, Perc, LSI etc.) e cache com suporte a bateria ou flash. Assuma o RAID 1 + 0 e vários eixos (4+ discos).

Eu gasto um tempo considerável ajustando as configurações de rede do Linux para aplicativos de baixa latência e financeiros. Mas muitas dessas opções são bem documentadas (alterando os buffers de envio / recebimento, modificando as configurações da janela TCP, etc.). O que os engenheiros estão fazendo no lado do armazenamento?

Historicamente, fiz alterações no elevador de programação de E / S , optando recentemente por os agendadores deadline e noop para melhorar o desempenho em meus aplicativos. À medida que as versões do RHEL progrediram, observei também que os padrões compilados para dispositivos de bloco SCSI e CCISS também foram alterados. Isso teve um impacto nas configurações recomendadas do subsistema de armazenamento ao longo do tempo. No entanto, faz um tempo desde que eu vi algumas recomendações claras. E sei que os padrões do sistema operacional não são ideais. Por exemplo, parece que o buffer padrão de leitura antecipada de 128kb é extremamente pequeno para uma implantação em hardware de classe de servidor.

Os artigos a seguir exploram o impacto no desempenho da alteração dos valores de cache read-ahead e de nr_requests nas filas de block.

link link
link

Por exemplo, estas são alterações sugeridas para um controlador RAID HP Smart Array:

echo "noop" > /sys/block/cciss\!c0d0/queue/scheduler 
blockdev --setra 65536 /dev/cciss/c0d0
echo 512 > /sys/block/cciss\!c0d0/queue/nr_requests
echo 2048 > /sys/block/cciss\!c0d0/queue/read_ahead_kb

O que mais pode ser ajustado de forma confiável para melhorar o desempenho do armazenamento? Estou procurando especificamente opções sysctl e sysfs em cenários de produção.

    
por ewwhite 26.03.2012 / 20:09

3 respostas

37

Descobri que, quando tive que sintonizar uma baixa latência versus uma taxa de transferência, afinei nr_requests do padrão (para um valor tão baixo quanto 32). A ideia de ser lotes menores é igual a menor latência.

Também para read_ahead_kb, descobri que, para leituras / gravações sequenciais, aumentar esse valor oferece melhor taxa de transferência, mas descobri que essa opção realmente depende da carga de trabalho e do padrão de E / S. Por exemplo, em um sistema de banco de dados que eu ajustei recentemente, alterei esse valor para corresponder a um único tamanho de página de banco de dados que ajudou a reduzir a latência de leitura. Aumentar ou diminuir além desse valor provou prejudicar o desempenho no meu caso.

Quanto a outras opções ou configurações para filas de dispositivos de bloco:

max_sectors_kb = Eu configurei este valor para combinar com o que o hardware permite para uma única transferência (verifique o valor do arquivo max_hw_sectors_kb (RO) em sysfs para ver o que é permitido)

nomerges = isso permite desabilitar ou ajustar a lógica de pesquisa para mesclar as solicitações do io. (desligar isso pode economizar alguns ciclos de cpu, mas eu não vi nenhum benefício ao mudar isso para os meus sistemas, então deixei o padrão)

rq_affinity = Eu não tentei isso ainda, mas aqui está a explicação por trás dele a partir dos documentos do kernel

If this option is '1', the block layer will migrate request completions to the cpu "group" that originally submitted the request. For some workloads this provides a significant reduction in CPU cycles due to caching effects.
For storage configurations that need to maximize distribution of completion processing setting this option to '2' forces the completion to run on the requesting cpu (bypassing the "group" aggregation logic)"

scheduler = você disse que tentou o prazo e o noop. Eu testei tanto o noop quanto o prazo, mas encontrei o prazo final para os testes que fiz recentemente para um servidor de banco de dados.

O NOOP teve um bom desempenho, mas para nosso servidor de banco de dados eu ainda consegui obter um melhor desempenho ajustando o agendador de prazos.

Opções para o planejador de prazo localizado em / sys / block / {sd, cciss, dm -} * / queue / iosched /:

fifo_batch = como nr_requests, mas específico para o agendador. A regra prática é ajustá-la para baixa latência ou para taxa de transferência. Controla o tamanho do lote de solicitações de leitura e gravação.

write_expire = define o tempo de expiração para o padrão de gravação de lotes é de 5000 ms. Mais uma vez, diminuir esse valor diminui sua latência de gravação enquanto aumenta o valor aumenta a taxa de transferência.

read_expire = define o tempo de expiração para o padrão de leitura de lotes é de 500 ms. As mesmas regras se aplicam aqui.

front_merges = Eu tenho a tendência de desativar isso e está ativado por padrão. Eu não vejo a necessidade de o agendador desperdiçar ciclos de CPU tentando fazer frente às solicitações de IO.

writes_starved = desde que o prazo final é direcionado para leituras, o padrão aqui é processar 2 lotes de leitura antes que um lote de gravação seja processado. Eu encontrei o padrão de 2 para ser bom para minha carga de trabalho.

    
por 27.03.2012 / 17:01
4

Mais do que tudo, tudo depende da sua carga de trabalho.

read_ahead_kb pode ajudá-lo se for realmente útil ler muitos dados de algum arquivo antes do tempo, como quando o fluxo de vídeo é transmitido. Às vezes pode te machucar muito. Sim, o padrão de 128 KB pode parecer pequeno, mas com concorrência suficiente ele começa a soar grande! Por outro lado, com um servidor como um servidor de codificação de vídeo que converte apenas os vídeos de um formato para outro, pode ser uma boa ideia ajustar.

nr_requests , quando overtuned, pode facilmente inundar seu controlador RAID, o que prejudica novamente o desempenho.

No mundo real, você precisa observar as latências . Se você estiver conectado à SAN, dê uma olhada com iostat , sar ou o que você quiser usar e veja se os tempos de serviço de solicitação de E / S estão no topo. É claro que isso também ajuda com os discos locais: se as latências forem muito grandes, considere ajustar suas configurações de elevador de E / S fazendo downgrade de max_requests e outras configurações.

    
por 27.03.2012 / 14:43
4

FYI read_ahead_kb e blockdev --setra são apenas diferentes maneiras de definir o mesmo ajuste usando unidades diferentes (kB vs setores):

foo:~# blockdev --setra 65536 /dev/cciss/c0d0
foo:~# blockdev --getra /dev/cciss/c0d0
65536
foo:~# cat /sys/block/cciss\!c0d0/queue/read_ahead_kb
32768
foo:~# echo 2048 > /sys/block/cciss\!c0d0/queue/read_ahead_kb
foo:~# cat /sys/block/cciss\!c0d0/queue/read_ahead_kb
2048
foo:~# blockdev --getra /dev/cciss/c0d0
4096

Então o

blockdev --setra 65536 /dev/cciss/c0d0

no seu exemplo não tem efeito.

    
por 25.09.2012 / 11:00