Durante anos, o assassino de OOM do meu sistema operacional não funciona corretamente e leva a um sistema congelado.
Quando o uso da memória é muito alto, todo o sistema tende a "congelar" (de fato: se torna extremamente lento) por horas ou até dias , em vez de interromper processos para liberar a memória.
O máximo que gravei é de 7 dias antes de me demitir para operar uma redefinição.
Quando o OOM está prestes a ser alcançado, o iowait é muito, muito alto (~ 70%), antes de se tornar incomensurável.
A ferramenta: iotopmostrou que todos os programas estão lendo com uma taxa de transferência muito alta (por dezenas de MB / s) do meu disco rígido.
O que esses programas estão lendo?
- A hierarquia de diretórios?
- O próprio código executável?
Eu não exatamente agora.
[editado] Na época em que escrevi esta mensagem (em 2017), eu estava usando um ArchLinux atualizado (4.9.27-1-lts), mas já havia experimentado o problema há anos.
Eu experimentei o mesmo problema com várias distribuições Linux e configurações de hardware diferentes.
Atualmente (2019), estou usando uma atualização atualizada do Debian 9.6 (4.9.0). Tenho 16 GB de RAM física, um SSD no qual meu sistema operacional está instalado e nenhuma partição de swap .
Devido à quantidade de memória RAM que tenho, não quero habilitar uma partição de swap, pois isso atrasaria a aparição do problema.
Além disso, a troca de SSDs com muita frequência pode reduzir potencialmente a vida útil do disco.
A propósito, eu já tentei com e sem uma partição swap, provou atrasar apenas a aparição do problema, mas não sendo a solução.
Para mim, o problema é causado pelo fato de o Linux remover dados essenciais dos caches , o que leva a um sistema congelado porque ele precisa ler tudo, sempre, a partir do disco rígido.
Eu até me pergunto se o Linux não descartaria as páginas de códigos executáveis dos programas em execução, o que explicaria por que os programas que normalmente não lêem muitos dados se comportam dessa maneira nessa situação.
Eu tentei várias coisas na esperança de corrigir esse problema.
Um deles foi definido /proc/sys/vm/min_free_kbytescomo 1000000(1 GB).
Como esse 1 GB deve permanecer livre, pensei que essa memória seria reservada pelo Linux para armazenar em cache dados importantes.
Mas não deu certo.
Além disso, acho útil acrescentar que mesmo que poderia soar grande na teoria, restringindo o tamanho da memória virtual para o tamanho da memória física, definindo /proc/sys/vm/overcommit_memorya 2não é decentemente tecnicamente possível na minha situação, porque o tipo de aplicações que eu uso, exigem mais memória virtual do que efetivamente usam por alguns motivos.
De acordo com o arquivo /proc/meminfo, o Commited_ASvalor geralmente é superior ao dobro da ram física no meu sistema (16 GB, Commited_AS geralmente é> 32 GB).
Eu experimentei esse problema com /proc/sys/vm/overcommit_memoryseu valor padrão:, 0e por um tempo eu o defini como:, 1porque eu preferia que os programas fossem mortos pelo assassino do OOM em vez de se comportarem incorretamente porque eles não verificam os valores de retorno de mallocquando o alocações são recusadas.
Quando eu estava falando sobre esse problema no IRC , conheci outros usuários do Linux que tiveram esse mesmo problema, então acho que muitos usuários estão preocupados com isso.
Para mim, isso não é aceitável, pois até o Windows lida melhor com o alto uso de memória.
Se você precisar de mais informações, tenha uma sugestão, por favor me diga.
Documentação:
https://en.wikipedia.org/wiki/Thrashing_%28computer_science%29
https://en.wikipedia.org/wiki/Memory_overcommitment
https://www.kernel.org/doc/Documentation/sysctl/vm. txt
https://www.kernel.org/doc/Documentation/vm/overcommit-accounting
https://lwn.net/Articles/317814/
Eles falam sobre isso:
Por que o assassino de falta de memória (OOM) do Linux não é executado automaticamente, mas funciona com a chave sysrq?
Por que o OOM-killer às vezes falha em matar porcos de recursos?
Pré-carregando o assassino do OOM
É possível acionar o OOM-killer em trocas forçadas?
Como evitar alta latência perto da situação da OOM?
https://lwn.net/Articles/104179/
https://bbs.archlinux.org/viewtopic.php?id=233843
min_free_kbytesnão é relevante, não é uma reserva para páginas em cache. AFAICT nenhum dos sysctls vm permite reservar qualquer memória especificamente para páginas em cache, ou seja, limitando alocações MAP_ANONYMOUS :(.