Ajuste da memória virtual do Linux para solucionar problemas de E / S de disco

Question

Estou tendo um problema com um servidor Linux que está gravando muito em disco, portanto, estou tendo um tempo de resposta lento devido a uma grande espera de IO. Eu já verifiquei valores inteligentes para os discos e estou bem. Esta é uma configuração de dois discos no software RAID1, sistema de arquivos ext4.

Como não posso atualizar o hardware por enquanto nem me livrar dos intensos aplicativos de E / S, estava planejando configurar o Linux vm na tentativa de facilitar o tempo de espera de E / S.

Estou pensando em ajustar a troca, mas principalmente o dirty_background_ratio e o dirty_ratio.

Pergunta:

Como posso estimar o ajuste desses valores com base na carga atual do meu sistema e no uso de memória?

    

Answer 1

Você quer poucas coisas. Primeiro você quer reduzir o swappiness

sysctl -w vm.swappiness=10

Isso salvará algum disco IO; porque a última coisa que você precisa é de gravações adicionais em disco quando o kernel tenta mostrar algumas coisas da mem. O objetivo é sintonizar as coisas, pois é necessária pouca troca. No entanto, não desligue o swap, definindo-o como 0 ou desativando. Eu recomendaria a ação extrema para ir tão longe como a configuração de swappiness para 1. Se você observar a saída do dstat por um tempo, você notará rapidamente quantos dados realmente são gravados e lidos a partir da troca.

Agora existe um mecanismo nos novos kernels (3.2+) chamado throttling writeback . Para poder usá-lo como você disse, você precisa ajustar as taxas de sujeira. Verifique para mais detalhes este link . Cite de lá que lhe interessa é

Once dirty_ratio (resp. dirty_bytes) limit is hit then the process which 
writes gets throttled.

Portanto, por padrão, dirties são bastante altos, especialmente se você tiver muita memória e subsistema de disco lento. Então você precisa ajustá-los; o mais baixo possível para não afetar o uso normal * e ainda assim o valor ditará o volume de dados que existirão na memória antes do kernel gerar processos para gravar isso no disco, quando a situação de gargalo do IO do disco começar a ocorrer. Nesse ponto, você quer que o processo seja acelerado, o que o kernel faz com a injeção inativa nele.

* para descobrir o que é uso normal; Eu recomendaria instalar no topo e observar o que está acontecendo lá; você deseja verificar os números de dirty lá e ver a visão geral D, onde as leituras / gravações de disco são rastreadas. Existe coluna WCANCL; Estas são, na verdade, gravações que foram manipuladas na memória e nunca foram necessárias para serem gravadas no disco (páginas sujas), mas para alguns dados temporários. O Mysql tem aqueles quando ele faz consultas complexas, compilador ao fazer um monte de pequenos arquivos obj que não serão necessários por muito tempo etc ...

Além disso, pode ajudar a alternar para o agendador de disco de prazo final e ajustar a afinidade de leituras x gravações para ajustar melhor seu ambiente. por exemplo. se você fizer 10x mais leituras que as gravações, talvez queira definir

/sys/block/<device>/queue/iosched/writes_starved

para 5, em vez de padrão 2. Configuração mais alta

/sys/block/<device>/queue/iosched/write_expire

também ajudará. Além disso, você pode ganhar alguma latência se diminuir o número de solicitações feitas em lote de 128 para dizer 32

/sys/block/<device>/queue/nr_requests

    

Answer 2

Se você tiver gravações pesadas, será restringido por não ter uma camada de cache de gravação disponível em seu sistema. Dois discos e software RAID tornam isso difícil. Geralmente, esse é um recurso do RAID de hardware. O que você tem agora não é a configuração de hardware correta para sua carga de trabalho.

Para fornecer respostas melhores, precisaríamos de detalhes sobre o que seu aplicativo está fazendo, o SO, se as barreiras de gravação estão ativadas em seu sistema de arquivos, etc.

Edit: Você só pode ajustar até agora se a sua fundação estiver ruim. Talvez você deva considerar SSDs em vez de girar discos para esse propósito.

    

Answer 3

Eu escrevi sobre dirty_background_ratio e dirty_ratio etc no meu blog recentemente:

A versão curta é não usar as variáveis * _ratio, mas usar a versão * _bytes e estimar o número de bytes tomando a largura de banda (ou taxa de geração de dados) e multiplicando por uma latência máxima que você está disposto a ter antes que grandes gravações comecem a bater no disco.

Ao definir o valor dirty_background_bytes relativamente baixo (menos de um segundo de atraso na taxa de recepção / geração total de dados), você garantirá que o buffer não se acumule enquanto ninguém estiver fazendo nada. Definir os dirty_bytes um fator de 2 ou 3 vezes maior (pelo menos, talvez até 10x ou mais, dependendo da quantidade de RAM) garantirá que um processo em rajadas não seja acelerado. Você pode estimar o valor de dirty_bytes considerando a diferença entre a taxa de geração de dados e a velocidade de gravação do disco. Essa é uma taxa de preenchimento de buffer e você pode multiplicar por um tempo máximo de buffer antes de o preenchimento ser acelerado. Por exemplo, se você gerar dados na taxa Rg e gravar em disco na taxa Rd e Rg for maior que Rd, você pode definir dirty_background_bytes como Rg * (0,5 segundos) para que o disco comece a gravar cerca de 0,5 segundos depois de começar a bater os dados nos buffers e defina dirty_bytes para max (2 * Rg * 0.5, (Rg-Rd) * (2 segundos)) por exemplo. Os processos em rajada poderão gravar por até 2 segundos antes que os buffers fiquem grandes o suficiente para serem acelerados.