Periodicamente, aqui e ali surgem dúvidas sobre as recomendações de Gluster sobre o ajuste do kernel e se há uma necessidade para isso.
Essa necessidade é rara. O kernel tem um desempenho muito bom na maioria das cargas de trabalho. Embora haja uma desvantagem. Historicamente, o kernel Linux consome avidamente muita memória se tiver a oportunidade, inclusive para armazenamento em cache como a principal forma de melhorar o desempenho.
Na maioria das vezes isso funciona bem, mas sob carga pesada pode causar problemas.
Temos muita experiência com sistemas que consomem muita memória, como CAD, EDA e similares, que começaram a ficar mais lentos sob alta carga. E às vezes tínhamos problemas com Gluster. Depois de observar cuidadosamente a memória usada e a latência dos discos por mais de um dia, obtivemos sua sobrecarga, enorme iowait, erros de kernel (kernel oops), congelamentos, etc.
Este artigo é o resultado de muitos experimentos de ajuste realizados em várias situações. Esses parâmetros não apenas melhoraram a capacidade de resposta geral, mas também estabilizaram significativamente o desempenho do cluster.
Quando se trata de ajuste de memória, a primeira coisa a se observar é o subsistema de memória virtual (VM), que tem um grande número de opções que podem confundir você.
vm.swappiness
Este parâmetro
vm.swappinessdetermina o quanto o kernel usa swap (swap) em comparação com a RAM. No código-fonte, também é definido como "tendência a roubar memória mapeada" (tendência a roubar memória mapeada). Um valor alto de troca significa que o kernel estará mais sujeito a descarregar páginas renderizadas. Um valor de troca baixo significa o oposto: o kernel irá trocar menos páginas da memória. Em outras palavras, quanto maior o valor vm.swappiness, mais o sistema fará a troca.
O grande uso de swapping é indesejável, pois grandes blocos de dados são carregados e descarregados na RAM. Muitos argumentariam que o valor de swapiness deve ser alto, mas na minha experiência, defini-lo como "0" aumentará o desempenho.
Você pode ler mais detalhes aqui -lwn.net/Articles/100978
Mas, novamente, essas configurações devem ser aplicadas com cuidado e somente após testar um aplicativo específico. Para aplicativos de streaming altamente carregados, este parâmetro deve ser definido como "0". Mudar para "0" melhora a capacidade de resposta do sistema.
vm.vfs_cache_pressure
Este parâmetro controla a memória consumida pelo kernel para armazenar em cache objetos de diretório e inodes (dentry e inode).
Com o padrão de 100, o kernel tentará liberar os caches dentry e inode com justiça para o 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 irá limpar os caches dentry e inode devido à pressão de memória insuficiente 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 o descarregamento do dentry e do inode.
Com 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 tem que processar estruturas de dados em um sistema com 40 GB de memória ... Definir esse parâmetro para mais de 100 ajudou muitos usuários a obter um armazenamento em cache mais justo e melhorar a capacidade de resposta do kernel.
vm.dirty_background_ratio e vm.dirty_ratio
O primeiro parâmetro (
vm.dirty_background_ratio) define a porcentagem de memória com páginas sujas, após o que é necessário iniciar uma descarga em segundo plano das páginas sujas para o disco. Até que essa porcentagem seja atingida, nenhuma página é liberada para o disco. E quando a reinicializaçã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 têm permissão para continuar em execução até que a operação de E / S solicitada seja realmente concluída e os dados estejam no disco. Com alta carga de I / O, isso causa um problema, pois não há armazenamento em cache de dados e todos os processos que fazem I / O são bloqueados esperando por I / O. Isso leva a um grande número de processos congelados, alta carga, operação do sistema instável e baixo desempenho.
Diminuir os valores desses parâmetros resulta em dados sendo liberados para o disco com mais freqüência e não armazenados na RAM. Isso pode ajudar os sistemas com muita memória, para os quais não há problema em liberar o cache de página de 45-90 GB, o que resulta em grande latência para aplicativos front-end, reduzindo a capacidade de resposta e interatividade geral.
"1"> / proc / sys / vm / pagecache
Um cache de página é um cache que armazena dados de arquivos e programas executáveis, ou seja, são páginas com o conteúdo real dos arquivos ou dispositivos de bloco. Esse cache é usado para reduzir o número de leituras de disco. Um valor de "1" significa que o cache usa 1% da RAM e haverá mais leituras do disco do que da RAM. Não é necessário alterar este parâmetro, mas se você é paranóico sobre o controle do cache da página, pode usá-lo.
Prazo> / sys / block / sdc / queue / scheduler
O agendador de E / S é o componente do kernel do Linux que lida com as 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 um controlador com bom conhecimento da geometria do disco processar a solicitação o mais rápido possível. Mas o prazo parece melhorar o desempenho. Para mais informações sobre programadores podem ser encontrados na documentação para o 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 gravações).
"256"> / sys / block / sdc / queue / nr_requests
O número de solicitações de E / S no buffer antes de serem enviadas ao planejador. Alguns controladores têm um tamanho de fila interno (queue_depth) maior do que nr_requests do agendador de E / S, portanto, o agendador de E / S tem pouca chance de priorizar e mesclar adequadamente as solicitações. Para prazos e agendadores CFQ, é melhor quando nr_requests é 2 vezes a fila interna do controlador. Combinar e reordenar as consultas ajuda o planejador 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 vez. No exemplo acima, o valor é definido como "16" de acordo com o tamanho da faixa de 64 KB do RAID. Não faz sentido com swappiness = 0, mas se você definir swappiness para 10 ou 20, o uso desse valor o ajudará quando o tamanho da faixa RAID for 64 KB.
blockdev --setra 4096 / dev / <devname >(-sdb, hdc ou dev_mapper)
As configurações de dispositivo de bloco padrão para muitos controladores RAID geralmente resultam em desempenho terrível. Adicionar a opção acima configura a leitura antecipada para setores de 4096 * 512 bytes. Pelo menos para operações de streaming, a velocidade é aumentada preenchendo o cache de disco on-board com leitura antecipada durante o período que o kernel leva para preparar E / S. O cache pode conter dados que serão solicitados na próxima leitura. Muita leitura antecipada pode eliminar a E / S aleatória de arquivos grandes se estiver usando um tempo de disco potencialmente útil ou carregando dados fora do cache.
Abaixo estão mais algumas diretrizes no nível do sistema de arquivos. Mas eles ainda não foram testados. Certifique-se de que seu sistema de arquivos saiba o tamanho da faixa e o número de discos no array. Por exemplo, é uma matriz raid5 com um tamanho de faixa de 64 K de seis discos (na verdade, cinco porque um disco é usado para paridade). Essas recomendações são baseadas em suposições teóricas e coletadas de vários blogs / artigos por 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 acima.
ATENÇÃO! Tudo o que foi descrito acima é extremamente subjetivo para alguns tipos de aplicativos. Este artigo não garante nenhuma melhoria sem o teste prévio do usuário dos respectivos aplicativos. Ele só deve ser usado se for necessário para melhorar a capacidade de resposta geral do sistema ou se resolver problemas atuais.
Materiais adicionais:
- dom.as/2008/02/05/linux-io-schedulers
- www.nextre.it/oracledocs/oraclemyths.html
- lkml.org/lkml/2006/11/15/40
- misterd77.blogspot.com/2007/11/3ware-hardware-raid-vs-linux-software.html
Consulte Mais informação