Estou usando Linux 5.15 com Ubuntu 22.04.
Eu tenho um processo que usa muita memória. Requer mais memória do que tenho RAM na minha máquina. A primeira vez que o executei, foi morto pelo OOM Killer. Eu entendo isso: o sistema ficou sem memória, o OOM Killer foi acionado, meu processo foi encerrado. Isso faz sentido. Também tenho certeza de que foi isso que aconteceu: dei uma olhada dmesge está tudo lá.
Então eu adicionei algum espaço de troca. Não me importo se esse processo demorar muito para ser executado: não o executarei com frequência.
Executei o processo novamente. Desta vez, funcionou por mais tempo do que da primeira vez. Todo o sistema ficou muito lento, daquele jeito que os sistemas ficam quando estão trocando muito. Parecia estar funcionando... e então morreu. Não apenas o processo morreu, mas o processo shell que era seu pai também morreu, e o processo Tmux que era seu pai, e o processo shell que era pai do processo Tmux, e até mesmo o processo do terminal GNOME que era seu pai ! Mas então o processo de assassinato parou: nenhum outro pai morreu.
A princípio, pensei que o OOM Killer havia sido acionado novamente - embora ainda houvesse muito espaço de troca disponível - e que ele havia escolhido encerrar o processo do terminal GNOME. Mas eu verifiquei dmesge journalctl -knão havia nada de novo lá. Não havia sinal de que o OOM Killer havia sido acionado.
Então, primeira pergunta: existe alguma circunstância em que o OOM Killer pode ser acionado sem registrar nada no buffer de anel do kernel?
Fiquei intrigado com o fato de que o kernel do Linux parecia ter começado a trocar, mas de alguma forma não havia trocado o suficiente... ou não havia trocado rápido o suficiente... ou algo assim.
Então eu aumentei vm.swappiness. Isso realmente não deve afetar a estabilidade do sistema: é apenas um botão para girar para otimizar o desempenho. Mesmo com o kernel vm.swappinessdefinido 0, ainda deve iniciar a troca quando a memória livre em uma zona cair abaixo de um limite crítico.
Mas parecia que tinha começado a trocar, mas não havia trocado o suficiente ... então aumentei vm.swappinesspara 100incentivá-lo a trocar um pouco mais.
Então eu executei o processo novamente. Todo o sistema ficou muito lento, daquela forma que os sistemas fazem quando estão trocando muito ... até que o processo seja executado com sucesso até a conclusão.
Então, segunda pergunta: por que o kernel não usou o espaço de troca disponível, mesmo quando a memória livre caiu abaixo do limite crítico e certamente havia muito espaço de troca disponível? Por que a mudança vm.swappinessfez a diferença?
Atualizar:
Testes adicionais revelaram que a configuração vm.swappinessnão é uma solução confiável. Eu tive algumas falhas mesmo com vm.swappinessset to 100. Isso pode melhorar as chances de o processo ser concluído com sucesso, mas não tenho certeza.