Tive problemas com um processo que gerava muitos threads devido a um bug, consumindo memória e causando trocas pesadas para a partição swap. Portanto, desativei o swap – que de qualquer maneira é recomendado em clusters de servidores – para permitir que o programa com bugs falhasse mais cedo. Para minha surpresa, isso não melhorou em nada as coisas! Da mesma forma, definir vm.swappinesscomo 0 não ajudou. iotoprevelou pesadoleiturado disco (quase sem gravação).
Suspeito que o kernel do Linux ainda esteja trocando páginas de código na memória e relê as páginas de código sobrescritas do disco quando necessário. Quando a RAM está muito baixa, isso acontece com muita frequência, causando travamentos, fazendo com que o computador quase não responda.
Como evitar esta situação infeliz e potencialmente perigosa? Tentei desligar swap, cgroups para memória e restrições de CPU para esse processo e ulimit para max. 30 processos. Nada melhorou a situação. (Bem, isso não é inteiramente verdade: um limite de RAM que deixou centenas de MB permanentemente sem uso ajudou.)
Em particular: posso evitar a troca de segmentos de código na memória e permitir que o processo de solicitação de RAM simplesmente obtenha um NULL para o próximo malloc?
Responder1
Que tal ajustar a contabilidade de superalocação de memória e configurá-la para a opção 2 (não supercomprometer) em vez da opção padrão 0 (sobrecomprometer heurística)? A descrição para isso afirma
Don't overcommit. The total address space commit
for the system is not permitted to exceed swap + a
configurable amount (default is 50%) of physical RAM.
Depending on the amount you use, in most situations
this means a process will not be killed while accessing
pages but will receive errors on memory allocation as
appropriate.
O trecho acima é dedocumentação do kernel
A política pode ser definida com vm.overcommitajuste.