Phenquestions
Como vm.min_free_kbytes funciona
Alocações de memória podem ser necessárias para o sistema, a fim de garantir o funcionamento adequado do próprio sistema. Se o kernel permitir que toda a memória seja alocada, ele pode ter dificuldades ao precisar de memória para operações regulares para manter o sistema operacional funcionando sem problemas. É por isso que o kernel fornece o vm ajustável.min_free_kbytes. O ajuste forçará o gerenciador de memória do kernel a manter pelo menos uma quantidade X de memória livre. Aqui está a definição oficial do documentação do kernel linux: “Isso é usado para forçar a VM Linux a manter um número mínimo de kilobytes livres. A VM usa esse número para calcular um valor de marca d'água [WMARK_MIN] para cada zona de baixa memória no sistema. Cada zona de baixa memória obtém um número de páginas gratuitas reservadas com base proporcionalmente em seu tamanho. Alguma quantidade mínima de memória é necessária para satisfazer as alocações PF_MEMALLOC; se você definir isso para menos de 1024 KB, seu sistema ficará sutilmente quebrado e sujeito a um deadlock sob altas cargas. Definir um valor muito alto OOM sua máquina instantaneamente.“
Validando vm.min_free_kbytes funciona
Para testar se a configuração de min_free_kbytes está funcionando conforme o planejado, criei uma instância virtual do Linux com apenas 3.75 GB de RAM. Use o comando gratuito abaixo para analisar o sistema:
# free -m
Olhando para o utilitário de memória livre acima usando o sinalizador -m para ter os valores impressos em MB. A memória total é 3.5 a 3.75 GB de memória. 121 MB de memória são usados, 3.3 GB de memória estão livres, 251 MB são usados pelo cache do buffer. E 3.3 GB de memória disponíveis.
Agora vamos mudar o valor de vm.min_free_kbytes e veja qual é o impacto na memória do sistema. Vamos ecoar o novo valor para o sistema de arquivos virtual proc para alterar o valor do parâmetro do kernel conforme abaixo:
# echo 1500000> / proc / sys / vm / min_free_kbytes# sysctl vm.min_free_kbytes
Você pode ver que o parâmetro foi alterado para 1.5 GB aproximadamente e entrou em vigor. Agora vamos usar o gratuitamente comando novamente para ver quaisquer alterações reconhecidas pelo sistema.
# free -m
A memória livre e o cache do buffer não são alterados pelo comando, mas a quantidade de memória exibida como acessível foi reduzido de 3327 para 1222 MB. Que é uma redução aproximada da mudança no parâmetro para 1.5 GB min de memória livre.
Agora vamos criar um arquivo de dados de 2 GB e ver o que a leitura desse arquivo no cache do buffer faz com os valores. Aqui está como criar um arquivo de dados de 2 GB em 2 linhas de script bash abaixo. O script irá gerar um arquivo aleatório de 35 MB usando o comando dd e, em seguida, copiá-lo 70 vezes em um novo data_file resultado:
# dd if = / dev / random of = / root / d1.contagem txt = 1000000# para i em 'seq 1 70'; faça echo $ i; cat / root / d1.txt >> / root / data_file; feito
Vamos ler o arquivo e ignorar o conteúdo lendo e redirecionando o arquivo para / dev / null conforme abaixo:
# cat data_file> / dev / nullOk, o que aconteceu com a memória do nosso sistema com este conjunto de manobras, vamos verificar agora:
# free -m
Analisando os resultados acima. Ainda temos 1.8 GB de memória livre para que o kernel tenha protegido um grande pedaço de memória como reservado por causa de nossa configuração min_free_kbytes. O cache do buffer usou 1691 MB, que é menor que o tamanho total do nosso arquivo de dados, que é 2.3 GB. Aparentemente, todo data_file não pôde ser armazenado no cache devido à falta de memória disponível para usar o cache do buffer. Podemos validar que o arquivo inteiro não está armazenado no cache, mas cronometrando as repetidas tentativas de ler o arquivo. Se estivesse em cache, demoraria uma fração de segundo para ler o arquivo. Vamos tentar.
# time cat data_file> / dev / null# time cat data_file> / dev / null
A leitura do arquivo levou quase 20 segundos, o que implica que quase certamente nem todos estão armazenados em cache.
Como uma validação final, vamos reduzir o vm.min_free_kbytes para permitir que o cache da página tenha mais espaço para operar e podemos esperar ver o cache funcionando e o arquivo lido ficando muito mais rápido.
# echo 67584> / proc / sys / vm / min_free_kbytes# time cat data_file> / dev / null
# time cat data_file> / dev / null
Com a memória extra disponível para armazenamento em cache, o tempo de leitura do arquivo caiu de 20 segundos antes para .364 segundos com tudo em cache.
Estou curioso para fazer outro experimento. O que acontece com chamadas malloc para alocar memória de um programa C em face desta VM realmente alta.configuração de min_free_kbytes. Será que vai falhar o malloc?? O sistema morrerá? Primeiro reinicie o vm.configuração de min_free_kbytes com o valor realmente alto para retomar nossos experimentos:
# echo 1500000> / proc / sys / vm / min_free_kbytesVamos olhar novamente para a nossa memória livre:
Teoricamente, temos 1.9 GB grátis e 515 MB disponíveis. Vamos usar um programa de teste de estresse chamado stress-ng para usar um pouco de memória e ver onde falhamos. Usaremos o vm tester e tentaremos alocar 1 GB de memória. Uma vez que reservamos apenas 1.5 GB em um 3.Sistema de 75 GB, acho que deve funcionar.
# stress-ng --vm 1 --vm-bytes 1G --timeout 60sstress-ng: info: [17537] despacho porcos: 1 vm
stress-ng: info: [17537] cache alocar: tamanho padrão do cache: 46080K
stress-ng: info: [17537] execução bem-sucedida concluída em 60.09s (1 min, 0.09 segs)
# stress-ng --vm 2 --vm-bytes 1G --timeout 60s
# stress-ng --vm 3 --vm-bytes 1G --timeout 60s
Vamos tentar novamente com mais trabalhadores, podemos tentar 1, 2, 3, 4 trabalhadores e em algum ponto deve falhar. No meu teste, passou com 1 e 2 trabalhadores, mas falhou com 3 trabalhadores.
Vamos reiniciar o vm.min_free_kbytes para um número baixo e veja se isso nos ajuda a executar 3 estressores de memória com 1 GB cada em um 3.Sistema de 75GB.
# echo 67584> / proc / sys / vm / min_free_kbytes# stress-ng --vm 3 --vm-bytes 1G --timeout 60s
Desta vez funcionou com sucesso sem erros, tentei duas vezes sem problemas. Portanto, posso concluir que há uma diferença comportamental de ter mais memória disponível para malloc, quando o vm.o valor de min_free_kbytes é definido com um valor inferior.
Configuração padrão para vm.min_free_kbytes
O valor padrão para a configuração no meu sistema é 67584 que é cerca de 1.8% de RAM no sistema ou 64 MB. Por razões de segurança em um sistema muito debilitado, eu tenderia a aumentá-lo um pouco talvez para 128 MB para permitir mais memória livre reservada, no entanto, para uso médio, o valor padrão parece razoável. A documentação oficial alerta sobre tornar o valor muito alto. Configurá-lo para 5 ou 10% da RAM do sistema provavelmente não é o uso pretendido da configuração e é muito alto.
Configurando vm.min_free_kbytes para sobreviver a reinicializações
A fim de garantir que a configuração sobreviva às reinicializações e não seja restaurada aos valores padrão durante a reinicialização, certifique-se de tornar a configuração do sysctl persistente, colocando o novo valor desejado em / etc / sysctl.arquivo conf.
Conclusão
Vimos que o vm.min_free_kbytes linux kernel tunable pode ser modificado e pode reservar memória no sistema a fim de garantir que o sistema é mais estável, especialmente durante o uso pesado e alocações de memória pesadas. As configurações padrão podem ser um pouco baixas, especialmente em sistemas com muita memória e devem ser consideradas para serem aumentadas com cuidado. Vimos que a memória reservada por este sintonizável impede que o cache do sistema operacional use toda a memória e também impede que algumas operações malloc usem toda a memória também.
