O Gentoo Hardened consome 3 GB de memória depois de executar por ~ 12 horas com muito poucos processos em execução

Question

Estou executando o AMD64 do Gentoo Hardened usando o kernel 4.3.3-endurecido-r4. Com meu sistema executando apenas alguns daemons básicos como wpa_supplicant, cron ou DHCP, e com uma sessão X com apenas Windowmaker, GKrellM e xterm abertos, o Linux começa a comer mais e mais memória RAM com o passar do tempo até depois de 8-12 horas. ficando sem RAM e lança um pânico no kernel. Esta não é uma questão de relatórios do Linux RAM usada para buffers e cache de sistema de arquivos, porque top, htop e GKrellM são responsáveis por esses casos e mostram quanta RAM é realmente tomada pelos processos. Até recentemente eu pensava que ele estava ligado ao meu cliente Bitcoin Core, mas não era esse o caso (eu acabei casualmente por rodar esse aplicativo enquanto meu sistema Linux estava funcionando).

Eu pude ver que, em alguns casos, meu uso de RAM saltou de volta ao normal durante a emissão de uma atualização completa do mundo ( emerge -NDu --with-bdeps=y @world ), mas não consegui reproduzir essa solução alternativa.

Até agora eu tentei as seguintes correções:

1. Compilando o suporte a NUMA no meu kernel (por padrão não habilitado pelo genkernel do Gentoo) e adicionando vm.zone_reclaim_mode=1 ao meu sysctl. Não funcionou.
2. Adicionando vm.drop_caches=1 ao meu sysctl. Não funcionou.
3. Verificando se uma montagem tmpfs estava ficando cheia. Minhas montagens tmpfs dificilmente registram mais de 1 MB de uso do sistema de arquivos.

Evidências desse comportamento podem ser vistas nessas capturas de tela:

Exibição A: Em que os únicos processos que comem memória que estão em execução são o Firefox, o GKrellm e o X, no entanto, o Linux está comendo quase 3 GB de núcleo. Nota: Eu não tinha meu espaço de troca ativado aqui (ele está em um HD externo USB 3.0 porque meu HD interno é antigo e lento), mas mesmo com a troca ativada eu ainda termino com um kernel OOM entre em pânico após 8+ horas mantendo o Bitcoin Core rodando.

ExibiçãoB:ApenasnocasodeohtopeoGKrellmseremfalhos,euverifiqueinovamentecomotopo.Omesmoresultado.

ExibiçãoC:Minhasestatísticasdeusodemontagemtmpfs,minhasaídadefreeemeuconteúdode/proc/meminfo disponível aqui

Esta postagem foi bastante editada para explicar minhas descobertas mais recentes. O post antigo pode ser encontrado em este Pastebin aqui .

    

Answer 1

Então, depois de quase dois meses intrigados com essa questão, decidi perguntar em torno de como habilitar a opção vm.zone_reclaim_mode sysctl e jogar um pouco com valores diferentes, e eis que - problema resolvido.

Solução:

1. Ative o CONFIG_NUMA na configuração do meu kernel e reconstrua-o.
2. Coloque vm.zone_reclaim_mode = 7 no sysctl.conf

Agora meu sistema pode finalmente ficar inteiro por mais de 24 horas.

Estou com um pouco de medo do desempenho reduzido, pois a documentação do kernel diz que tanto o NUMA quanto uma configuração de recuperação de zona agressiva provavelmente poderiam atrasar as coisas, mas por enquanto meu sistema finalmente funciona.

    

Answer 2

Você tem uma montagem baseada em SHM, como /tmp ou /var/tmp com backup de memória? É possível que arquivos temporários estejam sendo gerados e consumam ram mesmo depois que o processo é encerrado. Esses arquivos permanecerão no RAM até que sejam excluídos ou o sistema seja reiniciado. Verifique suas montagens em /etc/fstab e também com mount para entradas tmpfs.

Verifique também sua rotação de log, pois pode estar criando arquivos grandes em um diretório temporário. Pode valer a pena limpar o diário se você estiver usando o systemd. por exemplo:

journalctl --vacuum-size=500M

    

Answer 3

Para resumir:

• Depois de usar o cliente BitCoin, ele começa a devorar seu RAM até o ponto em que ele falha
• Não retorna memória (até que você faça algo estranho)

O primeiro se parece com um vazamento de memória clássico. Você pode verificar o desempenho e o gerenciamento de memória do programa usando valgrind , mas isso diminuirá consideravelmente.

O segundo pode ser o filho do primeiro problema. Eu não sei por que isso está acontecendo, mas eu só posso imaginar que por causa dos problemas com a memória (ou grande consumo de memória, ou talvez algum outro bug - por exemplo, processo preso no estado D?). Já que outros aplicativos não mostram o mesmo comportamento, eu acho que o problema é o software bitcoin, e não o seu sistema.

Portanto, tudo o que fazemos para corrigir isso seria um hack. Pode haver um hack bem-sucedido, mas ainda não é o melhor caminho. Se você tem acesso ao código-fonte e conhece um pouco de programação, pode tentar executar algum analisador de código estático para ver se há algum erro 'simples' a ser corrigido. Você pode tentar depurar seu gerenciamento de memória com valgrind . Se você não tem nenhum destes (código / habilidades), a última coisa que você pode fazer é dar feedback para os desenvolvedores - provavelmente algum bugtracker, fórum ou lista de discussão. Dessa forma, alguém irá investigar e confirmar (e, com sorte, consertar) o problema.