O que são mesclagens frontais no planejamento de E / S e como posso ajustar esse parâmetro?

Question

Meu Linux usa o algoritmo Prazo final para agendamento de E / S. Um dos parâmetros é o parâmetro front_merges em /sys/block/sda/queue/iosched/front_merges . Por padrão, é definido como 1, o que significa que as mesclagens frontais provavelmente ocorrerão. Pode-se definir como 0 para obter um aumento de desempenho, se não esperar que as mesclagens frontais ocorram.

1. O que são as mesclagens frontais exatamente? Alguém pode descrever isso por favor?
2. Como sei ou teste se as mesclagens frontais ocorrem no meu sistema ou não?

Answer 1

A documentação do kernel diz melhor:

Sometimes it happens that a request enters the io scheduler that is contiguous with a request that is already on the queue. Either it fits in the back of that request, or it fits at the front. That is called either a back merge candidate or a front merge candidate. Due to the way files are typically laid out, back merges are much more common than front merges. For some work loads, you may even know that it is a waste of time to spend any time attempting to front merge requests. Setting front_merges to 0 disables this functionality. Front merges may still occur due to the cached last_merge hint, but since that comes at basically 0 cost we leave that on. We simply disable the rbtree front sector lookup when the io scheduler merge function is called.

A razão pela qual as mesclagens iniciais são incomuns é que os gravadores normalmente não gravam blocos no disco em ordem reversa.

Considere um processo que faça uma simples gravação seqüencial de um novo arquivo contendo dois blocos. Primeiro ele grava o bloco 0 e, em seguida, grava o bloco 1. Quando o bloco 1 atinge a fila, ele está na parte de trás do bloco 0, de modo que o kernel faz uma mesclagem retroativa e envia os dois blocos ao disco físico ao mesmo tempo. Este é o caso típico.

Para obter uma mesclagem frontal, o processo primeiro teria que escrever o bloco 1, depois procurar para trás e escrever o bloco 0. Este não é o caso típico, embora algumas cargas de trabalho aconteçam (por exemplo, bancos de dados).

Eu não esperaria que a mudança no desempenho fosse tão significativa aqui, mesmo com alta E / S. Você pode testá-lo nos dois sentidos em sua carga de trabalho real. Se você não está fazendo algo intensivo em disco, isso não é realmente importante.

    

Answer 2

A Red Hat diz:

front_merges: You can set this tunable to 0 if you know your workload will never generate front merges. Unless you have measured the overhead of this check, it is advisable to leave it at its default setting (1).

Portanto, a configuração recomendada é deixar no padrão. Posso dizer que normalmente não modifico essa configuração em meus esforços de ajuste, mas isso depende da sua carga de trabalho.

Veja: Linux - real de controlador RAID de hardware global (scsi e cciss)

Além disso, a melhor abordagem é fazer um teste científico com seus dados, sistemas e ambiente.

Você pode monitorar a atividade de mesclagem usando o comando iostat -x e rastreando os campos rrqm/s e wrqm/s na saída. Qualquer coisa que não seja ZERO nessas colunas indica que as solicitações contíguas foram mescladas antes de serem entregues ao armazenamento subjacente. Isso também indica que a carga de trabalho é seqüencial.

Se você não encontrar atividade nessas colunas, modificar o prazo de ajuste do front_merge não o beneficiará.

Você não forneceu detalhes reais em sua pergunta sobre o tipo de servidor ou o subsistema de armazenamento. Se você estiver usando qualquer tipo de RAID de hardware com armazenamento em cache, ou determinados sistemas de arquivos, eles levam em consideração o impacto desse parâmetro ajustável.