E / S de disco do Linux OOM. Também: swap, para que serve?

Question

Estou tendo problemas com o killer da OOM em uma das minhas instalações do Linux (2.6.37). O computador tem 4 GB de memória que, por vezes, utilizo totalmente. Nesses casos, espero que o manipulador de OOM entre e faça seu trabalho matando um processo ou dois. Em vez de fazer isso, ou talvez ao tentar fazer isso, o sistema trava, fazendo E / S de disco como se não houvesse amanhã. Aqui está a coisa: Eu não tenho nenhuma troca ativada. Por alguma razão, meu sistema sem remendos ainda está bloqueando grandes quantidades de E / S de disco, embora o curso de ação apropriado seja simplesmente matar um processo ou dois. Pensamentos?

A questão toda me faz pensar se o Linux exige swap de alguma forma que eu não conheço. Uma explicação sobre se este é o caso e por que seria muito apreciado. Estou familiarizado com as ideias de swap em um nível conceitual (por exemplo, memória virtual, paginação, supercomprometimento), mas gostaria de saber se há algum detalhe de implementação que eu possa ter perdido.

    

Answer 1

A verdadeira questão é: por que você está correndo sem swap? Especialmente se você está vendo problemas sérios de desempenho relacionados à falta de memória RAM? Você sabe que não ter swap pode realmente tornar seu sistema mais lento, certo?

A solução óbvia é adicionar algum espaço de troca, e não ter seu sistema cagado em você. Considerando como o espaço em disco é barato, não consigo pensar em nenhuma situação comum ¹ onde você deve sempre construir um sistema sem swap.

Quanto a responder a sua pergunta, não me lembro de todos os detalhes de baixo nível sobre o motivo pelo qual a troca é importante mesmo em sistemas em que você não vai esgotar a memória, mas existem argumentos sobre o envio de e-mails do kernel Linux lista sobre se é razoável executar sistemas sem swap (e não houve muitas respostas conclusivas). O consenso geral é tipicamente para sempre ter swap , e ajustar a troca conforme necessário.

Além disso, acho que você está entendendo mal algumas advertências importantes relacionadas ao assassino Linux OOM. Primeiro de tudo, confiar nele para lidar com seus problemas de falta de memória é uma idéia muito ruim (tm). Pode ser muito indiscriminado sobre o que mata, e é inteiramente possível que você fique com um sistema instável ou mesmo inutilizável. Sim, ele tenta matar processos recentes que estão consumindo muita memória (uma pequena salvaguarda para tentar pegar um processo de fuga), mas não há garantias. Eu vi isso matar o ssh, matar processos Xen (em um servidor host virtual Xen, causando a queda de VMs), e em um caso ele matou o NFS.

Quanto ao IO. . . Eu não sei ao certo o que estaria causando isso. Talvez um sistema de arquivos ou um processo relacionado a um disco tenha sido morto? Talvez um processo tenha algum tipo de funcionalidade "cache para disco" embutido quando não pode alocar memória suficiente?

Outra nota, se esta for uma área de trabalho, a troca é necessária para Suspender para o disco. Se é um servidor, confiar em OOM é never uma boa ideia, já que compromete a estabilidade, bem, sem uma boa razão.

[1] Sistemas embarcados são a única exceção óbvia, e eles não são particularmente comuns (e se você está lidando com sistemas embarcados, você já estará ciente dos requisitos).

    

Answer 2

Eu acho que AndreasM acertou na cabeça (a razão para o disco ficar todo agitado). Os executáveis são paginados por demanda - assim, em operação normal, você terá quase todos os seus executáveis e bibliotecas em boa RAM física. . Mas quando a RAM está baixa, mas não baixa o suficiente para que o assassino de falta de memória seja executado, essas páginas são removidas da RAM. Então você acaba com uma situação em que as páginas são despejadas - no começo, não há problema, porque elas são despejadas pelo menos recentemente usadas primeiro e isso elimina as páginas que você não está usando de qualquer maneira. Mas então, isso elimina os que você está usando, só para ter que pagá-los de volta em instantes depois. Thrash city.

Basicamente, se algo usasse um pouco mais de RAM, você provavelmente teria o killer da OOM, mas você ainda não estava lá. Como alguns disseram, o OOM killer é indiscriminado, é realmente mais um último recurso para evitar um pânico do kernel do que algo que você deve considerar usar em operação normal. Se você tiver alguma configuração personalizada, eu consideraria escrever algum daemon para monitorar a memória livre e matar usando a política de sua escolha quando ela estiver cheia.