A tradução do artigo foi preparada na véspera do início do curso .
Periodicamente, aqui e ali, surgem dúvidas sobre as recomendações do Gluster em relação ao ajuste do kernel e se há necessidade disso.
Essa necessidade raramente surge. Na maioria das cargas de trabalho, o kernel funciona muito bem. Embora haja uma desvantagem. Historicamente, o kernel do Linux está disposto a consumir muita memória se for dada a oportunidade, inclusive para cache como a principal forma de melhorar o desempenho.
Na maioria dos casos, isso funciona bem, mas sob carga pesada pode causar problemas.
Temos muita experiência com sistemas intensivos de memória, como CAD, EDA e similares, que começaram a desacelerar sob carga pesada. E às vezes tínhamos problemas em Gluster. Depois de observar cuidadosamente o uso de memória e a latência do disco por muitos dias, obtivemos sobrecarga, iowait enorme, erros de kernel (kernel oops), congelamentos, etc.
Este artigo é resultado de vários experimentos de tuning realizados em diversas situações. Graças a esses parâmetros, não apenas a capacidade de resposta geral melhorou, mas o cluster também se estabilizou significativamente.
Quando se trata de ajuste de memória, a primeira coisa a se observar é o subsistema de memória virtual (VM, memória virtual), que possui um grande número de opções que podem confundi-lo.
vm.swappiness
Parâmetro vm.swappiness determina quanto o kernel usa swap (swap, paginação) em comparação com a RAM. Também é definido no código-fonte como "tendência para roubar memória mapeada". Um swappiness alto significa que o kernel estará mais inclinado a trocar páginas mapeadas. Um baixo valor de swappiness significa o oposto: o kernel paginará menos da memória. Em outras palavras, quanto maior o valor vm.swappiness, mais o sistema usará swap.
Um grande uso de troca é indesejável, uma vez que grandes blocos de dados são carregados e descarregados na RAM. Muitas pessoas argumentam que o valor de troca deve ser grande, mas, na minha experiência, defini-lo como "0" leva a um melhor desempenho.
Você pode ler mais aqui -
Mas, novamente, essas configurações devem ser aplicadas com cuidado e somente após o teste de um aplicativo específico. Para aplicativos de streaming altamente carregados, esse parâmetro deve ser definido como "0". Quando alterado para "0", a capacidade de resposta do sistema melhora.
vm.vfs_cache_pressão
Esta configuração controla a memória consumida pelo kernel para cache de diretório e objetos inode (dentry e inode).
Com um valor padrão de 100, o kernel tentará liberar os caches dentry e inode de forma "justa" para pagecache e swapcache. Diminuir vfs_cache_pressure faz com que o kernel mantenha os caches dentry e inode. Quando o valor é "0", o kernel nunca liberará o cache dentry e inode devido à pressão de memória, e isso pode facilmente levar a um erro de falta de memória. Aumentar vfs_cache_pressure acima de 100 faz com que o kernel priorize dentry e liberação de inode.
Ao usar o GlusterFS, muitos usuários com grandes quantidades de dados e muitos arquivos pequenos podem facilmente usar uma quantidade significativa de RAM no servidor devido ao cache inode/dentry, o que pode levar à degradação do desempenho, pois o kernel precisa processar estruturas de dados em um sistema com 40 GB de memória. Definir esse valor acima de 100 ajudou muitos usuários a obter um cache mais justo e uma melhor capacidade de resposta do kernel.
vm.dirty_background_ratio e vm.dirty_ratio
Primeiro parâmetro (vm.dirty_background_ratio) determina a porcentagem de memória com páginas sujas, após atingir a qual é necessário iniciar a descarga de páginas sujas em segundo plano para o disco. Até que essa porcentagem seja atingida, nenhuma página será descarregada no disco. E quando a redefinição é iniciada, ela é executada em segundo plano sem interromper os processos em execução.
O segundo parâmetro (vm.dirty_ratio) define a porcentagem de memória que pode ser ocupada por páginas sujas antes do início do flash forçado. Quando esse limite é atingido, todos os processos se tornam síncronos (bloqueados) e não podem continuar até que a E/S solicitada seja realmente concluída e os dados estejam no disco. Com E/S pesada, isso causa um problema porque não há cache de dados e todos os processos que fazem E/S ficam bloqueados esperando por E/S. Isso leva a um grande número de processos travados, alta carga, instabilidade do sistema e baixo desempenho.
Diminuir essas configurações faz com que os dados sejam liberados para o disco com mais frequência e não sejam armazenados na RAM. Isso pode ajudar sistemas com muita memória, onde é normal liberar caches de página de 45 a 90 GB para o disco, resultando em uma grande latência para aplicativos de front-end, reduzindo a capacidade de resposta e a interatividade geral.
"1" > /proc/sys/vm/pagecache
Um cache de página é um cache que armazena os dados de arquivos e programas executáveis, ou seja, são páginas com o conteúdo real de arquivos ou dispositivos de bloco. Esse cache é usado para reduzir o número de leituras de disco. Um valor de "1" significa que 1% da RAM é usado para o cache e haverá mais leituras do disco do que da RAM. Não é necessário alterar essa configuração, mas se você é paranóico em relação ao controle do cache da página, pode usá-lo.
"prazo final" > /sys/block/sdc/queue/scheduler
O agendador de E/S é um componente do kernel do Linux que lida com filas de leitura e gravação. Em teoria, é melhor usar "noop" para um controlador RAID inteligente, porque o Linux não sabe nada sobre a geometria física do disco, então é mais eficiente deixar o controlador, que conhece bem a geometria do disco, processar a solicitação o mais rápido possível. possível. Mas parece que "deadline" melhora o desempenho. Você pode ler mais sobre agendadores na documentação do código-fonte do kernel do Linux: linux/Documentation/block/*osched.txt. E também vi um aumento na taxa de transferência de leitura durante operações mistas (muitas operações de gravação).
"256" > /sys/block/sdc/queue/nr_requests
O número de solicitações de E/S no buffer antes de serem passadas para o planejador. O tamanho da fila interna de alguns controladores (profundidade_da_fila) é maior do que nr_requests do escalonador de E/S, portanto, o escalonador de E/S tem poucas chances de priorizar e mesclar solicitações adequadamente. Para agendadores de deadline e CFQ, é melhor quando nr_requests é 2 vezes a fila interna do controlador. Solicitações de mesclagem e reordenação ajudam o agendador a ser mais responsivo sob carga pesada.
echo "16" > /proc/sys/vm/page-cluster
O parâmetro page-cluster controla o número de páginas que são gravadas na troca de uma só vez. No exemplo acima, o valor é definido como "16" de acordo com o tamanho da faixa RAID de 64 KB. Não faz sentido com swappiness = 0, mas se você definir swappiness como 10 ou 20, usar esse valor ajudará quando o tamanho da faixa RAID for 64K.
blockdev --setra 4096 /dev/<nome do desenvolvedor> (-sdb, hdc ou dev_mapper)
As configurações padrão do dispositivo de bloco para muitos controladores RAID geralmente resultam em desempenho terrível. Adicionar a opção acima configura leitura antecipada para setores de 4096 * 512 bytes. No mínimo, para operações de streaming, a velocidade é aumentada preenchendo o cache de disco on-chip com read-ahead durante o período usado pelo kernel para preparar I/O. O cache pode conter dados que serão solicitados na próxima leitura. Muita pré-busca pode matar E/S aleatória para arquivos grandes se usar tempo de disco potencialmente útil ou carregar dados fora do cache.
Abaixo estão mais algumas recomendações no nível do sistema de arquivos. Mas ainda não foram testados. Certifique-se de que seu sistema de arquivos saiba o tamanho da faixa e o número de discos na matriz. Por exemplo, que este é um array raid5 de 64K com seis discos (na verdade, cinco, porque um disco é usado para paridade). Essas recomendações são baseadas em suposições teóricas e compiladas de vários blogs/artigos de especialistas em RAID.
-> ext4 fs, 5 disks, 64K stripe, units in 4K blocks
mkfs -text4 -E stride=$((64/4))
-> xfs, 5 disks, 64K stripe, units in 512-byte sectors
mkfs -txfs -d sunit=$((64*2)) -d swidth=$((5*64*2))Para arquivos grandes, considere aumentar os tamanhos de faixa listados acima.
ATENÇÃO! Tudo descrito acima é altamente subjetivo para alguns tipos de aplicações. Este artigo não garante nenhuma melhoria sem o teste prévio do usuário de aplicativos relacionados. Só deve ser usado se for necessário melhorar a capacidade de resposta geral do sistema ou se resolver problemas atuais.
Materiais adicionais:
Consulte Mais informação
Fonte: habr.com