Ajuste do Agendador de E/S do Linux: mq-deadline, nenhum, BFQ

Ajuste do agendador de E/S do Linux: mq-deadline, none e BFQ

O agendador de E/S do Linux determina a ordem em que os pedidos de leitura e gravação chegam ao seu dispositivo de armazenamento, e a escolha certa depende quase inteiramente do seu hardware. Use none para NVMe, mq-deadline para SSDs SATA e HDDs a executar cargas de trabalho mistas, e bfq quando precisar de impedir que um processo sobrecarregue os outros. Este guia aborda como funcionam os três principais agendadores, como escolher o mais adequado à sua carga de trabalho e como ajustar e verificar o resultado.

Se quiser um guia prático antes de ler, este vídeo aborda os conceitos básicos de como alternar e testar agendadores a partir do terminal.

Como o mq-deadline, o none e o BFQ diferem

Cada agendador lida com os pedidos com uma estratégia diferente. Saber como diferem é o que lhe permite escolher deliberadamente, em vez de executar o que quer que o kernel tenha escolhido no arranque.

mq-deadline

O mq-deadline agendador garante que nenhuma solicitação fique à espera indefinidamente. Ele mantém filas separadas e ordenadas para leituras e gravações, ordenando-as por Endereço de Bloco Lógico (LBA) para reduzir o tempo de busca, e impõe prazos: 500 ms para leituras e 5 segundos para gravações por padrão. Quando uma solicitação atinge o seu prazo, ela salta para o início da fila.

As leituras têm prioridade sobre as gravações, uma vez que as leituras normalmente bloqueiam a aplicação, enquanto as gravações são tratadas de forma assíncrona. Para impedir que as gravações fiquem totalmente prejudicadas, o agendador processa um lote de gravações em atraso após um número definido de leituras. O resultado é uma baixa latência consistente, o que o torna uma excelente opção para servidores de bases de dados e qualquer carga de trabalho que misture leituras e gravações.

nenhuma

O none agendador não faz praticamente nada. Ele encaminha as solicitações diretamente para o dispositivo na ordem First-In-First-Out, sem reordenação, fusão ou priorização. Isso é adequado para unidades NVMe modernas, que gerem as suas próprias filas internas e podem rastrear dezenas de milhares de solicitações em andamento ao mesmo tempo. Remover a camada de agendamento de software proporciona o caminho mais curto possível da aplicação ao dispositivo, que é exatamente o que as cargas de trabalho NVMe de alto rendimento desejam.

O problema é que isto só funciona quando o hardware consegue agendar de forma inteligente por si próprio. Em HDDs ou SSDs SATA com filas curtas, ignorar a reordenação do software geralmente piora o desempenho, em vez de o melhorar.

BFQ

O BFQ (Budget Fair Queuing) coloca a equidade em primeiro lugar. Em vez de intervalos de tempo, atribui a cada processo um orçamento medido em setores de disco. Leitores sequenciais de grande dimensão recebem orçamentos maiores para manter a taxa de transferência elevada, enquanto as tarefas sensíveis à latência recebem orçamentos menores para que sejam atendidas rapidamente, e um ciclo de feedback ajusta os orçamentos à medida que o sistema funciona.

O BFQ mantém as tarefas interativas responsivas mesmo sob carga pesada, de modo que a reprodução de vídeo ou uma consulta à base de dados permanece fluida enquanto uma transferência de ficheiros de grande dimensão é executada em segundo plano. Essa equidade tem um custo em termos de CPU. A sua sobrecarga por pedido é de aproximadamente 1,9 microssegundos, cerca de três vezes a do mq-deadline, e num núcleo ARM mais lento essa sobrecarga limita a taxa de transferência para um valor bem abaixo do que o mesmo agendador atinge num chip x86 rápido. Em servidores onde a taxa de transferência bruta e a eficiência da CPU são mais importantes, essa compensação é difícil de justificar.

Escolher um agendador adequado à sua carga de trabalho

Dois fatores determinam o agendador certo: o seu hardware de armazenamento e o padrão de acesso da sua aplicação. Comece pelo hardware. Se o dispositivo já reordena os pedidos, como uma unidade NVMe com firmware compatível, o agendamento por software apenas acrescenta sobrecarga, pelo que none ganha. Em discos rígidos rotativos, onde o tempo de busca é determinante, a reordenação por software reduz a latência, pelo que mq-deadline ou bfq são as melhores escolhas. Os SSDs SATA situam-se no meio: mais rápidos do que os HDDs, mas sem as filas profundas do NVMe, sendo que é aí que mq-deadline se encaixa.

A mesma lógica aplica-se quando outra coisa já está a agendar por si. As VMs convidadas no virtio-blk dependem do anfitrião para agendar a E/S, e os controladores RAID de hardware com cache de gravação posterior otimizam a sua própria ordenação. Em ambos os casos, none evita-se pagar duas vezes pelo trabalho.

O padrão de acesso é o segundo fator. Uma base de dados a realizar milhares de leituras aleatórias de 4K por segundo não tem nada em comum com uma tarefa de treino a transmitir grandes blocos sequenciais a partir de uma matriz NVMe, e ambas requerem agendadores diferentes. A tabela abaixo mapeia cargas de trabalho comuns para um ponto de partida.

Há uma exceção que vale a pena destacar. Mesmo no NVMe, se a latência de cauda no p99 ou p999 for a métrica que lhe interessa, como em sistemas financeiros, mq-deadline pode superar none ao impor prazos rigorosos e evitar o atraso ocasional de pedidos.

Alteração e ajuste dos parâmetros do agendador

Tanto a troca de agendadores como o ajuste dos seus parâmetros são feitos através do sysfs, sem necessidade de reiniciar o sistema para testar uma alteração.

Alterar o agendador ativo

Verifique o que está disponível para um dispositivo, sendo que o valor entre parênteses é o ativo:

cat /sys/block/sda/queue/scheduler

Mude para um agendador diferente em tempo de execução. Isto entra em vigor imediatamente, mas não sobrevive a um reinício:

echo bfq | sudo tee /sys/block/sda/queue/scheduler

Se bfq não estiver listado, carregue primeiro o módulo:

sudo modprobe bfq

Para tornar a escolha permanente, use uma regra udev em vez do antigo elevator= parâmetro do kernel, que já não altera o agendador no RHEL 9 e versões semelhantes. Esta regra define mq-deadline para todos os discos SCSI não rotativos em /etc/udev/rules.d/60-io-scheduler.rules:

ACTION=="add|change", SUBSYSTEM=="block", KERNEL=="sd[a-z]", ATTR{queue/rotational}=="0", ATTR{queue/scheduler}="mq-deadline"

Recarregue e aplique-a sem reiniciar:

sudo udevadm control --reload-rules && sudo udevadm trigger

Em sistemas baseados no RHEL, os perfis do TuneD fazem o mesmo trabalho através de perfis a nível do sistema, em vez de regras por dispositivo.

Parâmetros que vale a pena ajustar

Cada agendador expõe os seus parâmetros ajustáveis em /sys/block/<device>/queue/iosched/. Para mq-deadline, os prazos são as principais alavancas. As bases de dados sensíveis à latência em SSDs SATA beneficiam de prazos mais curtos:

echo 100 | sudo tee /sys/block/sda/queue/iosched/read_expire
echo 1000 | sudo tee /sys/block/sda/queue/iosched/write_expire

Para bfq em sistemas de alto rendimento, desativar a heurística de latência aumenta o rendimento:

echo 0 | sudo tee /sys/block/sda/queue/iosched/low_latency
echo 0 | sudo tee /sys/block/sda/queue/iosched/slice_idle

Para alojamento partilhado, o BFQ combina bem com o cgroups v2. A atribuição de io.weight valores permite atribuir a um processo de base de dados dez vezes a quota de E/S de uma tarefa de cópia de segurança, por exemplo, para que o trabalho em segundo plano não sobreponha o tráfego interativo. Independentemente das alterações que efetuar, o custo por pedido mais elevado do BFQ acumula-se em sistemas limitados pela CPU e com elevado IOPS, pelo que deve realizar testes de desempenho antes de avançar.

Verificar o desempenho após o ajuste

Registe sempre uma linha de base antes de alterar qualquer coisa. Sem ela, não há forma de saber se um ajuste ajudou.

O fio é a ferramenta padrão para isso. Reproduz padrões específicos de carga de trabalho através do tamanho do bloco, profundidade da fila e configurações do motor de E/S. Passe sempre --direct=1 para que ignore a cache de páginas e avalie diretamente o agendador e o dispositivo, em vez de leituras em cache. Adapte o teste à carga de trabalho real:

Execute o mesmo teste com iodepth valores de 1 a 256 para determinar o ponto de saturação do dispositivo, a profundidade em que as IOPS deixam de aumentar e a latência atinge picos. Para monitorização em tempo real após uma alteração, iostat -x 1 relate as métricas que importam: r_await e w_await para a latência de conclusão de leitura e gravação, aqu-sz para a profundidade média da fila e %util para a utilização do dispositivo. Quando %util se situa perto dos 100 por cento, o hardware é o limite e nenhuma alteração no agendador irá ajudar.

Para separar o custo do software do custo do hardware, execute o blktrace com o btt. Ele divide a latência em Q2D, o tempo gasto na fila do software, e D2C, o tempo que o dispositivo leva para atender à solicitação. Se o Q2D for predominante, o agendador é o seu gargalo. Se o D2C for predominante, o hardware é.

Uma coisa a ter em mente ao ler os resultados: a escolha do agendador molda principalmente a cauda da distribuição de latência, não a mediana. Mudar de none para mq-deadline em NVMe pode aumentar a latência mediana em alguns microssegundos, ao mesmo tempo que reduz a latência p99 e p999 para metade. Para serviços voltados para o utilizador e sujeitos a SLAs, essa troca vale quase sempre a pena, razão pela qual medir a latência da cauda, e não a taxa de transferência média, é o objetivo do exercício.

Escolher o agendador certo

O ajuste do agendador consiste em adaptar o algoritmo ao hardware e ao padrão de acesso e, em seguida, comprová-lo através de medições. A versão resumida:

• NVMe: use none e deixe que o firmware faça o enfileiramento.
• SSD SATA e HDD com E/S mista: use mq-deadline para uma latência previsível.
• Hosts partilhados ou multi-tenant: use bfq para evitar que uma carga de trabalho sobrecarregue as restantes.
• Acompanhe a latência mínima, não a mediana: as alterações do agendador aparecem em p99 e p999, por isso é isso que se deve medir.
• Torne-o persistente: use regras udev ou TuneD, nunca o parâmetro elevator= .

Tirar o máximo partido de qualquer agendador começa com hardware capaz de acompanhar o ritmo. Se precisar de servidores com suporte NVMe concebidos para cargas de trabalho de alto rendimento e baixa latência, explore as opções de VPS da FDC.