Estou executando uma estação de trabalho Linux sem swap e eu instalei o daemon earlyoom para matar automaticamente alguns processos se eu ' estou ficando sem RAM. O earlyoom funciona monitorando o valor do MemAvailable do kernel e, se a memória disponível ficar baixa o suficiente, elimina processos menos importantes.
Isso funcionou bem por um longo tempo, mas de repente estou correndo para uma situação em que MemAvailable é de repente muito baixo comparado com o resto do sistema. Por exemplo:
$ grep -E '^(MemTotal|MemFree|MemAvailable|Buffers|Cached):' /proc/meminfo
MemTotal: 32362500 kB
MemFree: 5983300 kB
MemAvailable: 2141000 kB
Buffers: 665208 kB
Cached: 4228632 kB
Observe como o MemAvailable é muito inferior a MemFree + Buffers + Cached .
Há alguma ferramenta que eu possa executar para investigar por que isso acontece? Eu sinto que o desempenho do sistema é um pouco pior do que o normal e eu tive que parar o serviço earlyoom porque sua lógica não funciona a menos que MemAvailable seja estável (ou seja, descreve corretamente a memória disponível para processos no modo de usuário).
De acordo com link MemAvailable é uma estimativa da quantidade de memória disponível para iniciar novos aplicativos, sem trocar. Como não tenho troca, o que isso significa? Isso deveria significar a quantidade de memória que um novo processo pode adquirir antes que o OOM Killer seja acionado (porque isso logicamente atingiria a situação "a troca está cheia")?
Eu supus que MemAvailable > = MemFree seria sempre verdadeiro. Não aqui.
Informações adicionais:
A pesquisa na Internet sugere que a causa pode ser arquivos abertos que não são suportados pelo sistema de arquivos e, como resultado, não podem ser liberados da memória. O comando sudo lsof | wc -l outputs 653100 , então eu definitivamente não posso passar manualmente por essa lista.
O topo do sudo slabtop diz
Active / Total Objects (% used) : 10323895 / 10898372 (94.7%)
Active / Total Slabs (% used) : 404046 / 404046 (100.0%)
Active / Total Caches (% used) : 104 / 136 (76.5%)
Active / Total Size (% used) : 6213407.66K / 6293208.07K (98.7%)
Minimum / Average / Maximum Object : 0.01K / 0.58K / 23.88K
OBJS ACTIVE USE OBJ SIZE SLABS OBJ/SLAB CACHE SIZE NAME
4593690 4593656 99% 1.06K 153123 30 4899936K ext4_inode_cache
3833235 3828157 99% 0.19K 182535 21 730140K dentry
860224 551785 64% 0.06K 13441 64 53764K kmalloc-64
515688 510872 99% 0.66K 21487 24 343792K proc_inode_cache
168140 123577 73% 0.20K 8407 20 33628K vm_area_struct
136832 108023 78% 0.06K 2138 64 8552K pid
...
que parece normal para mim.
Criando um resumo aproximado de lsof
$ sudo lsof | awk '{ print $2 }' | sort | uniq -c | sort -h | tail
6516 1118
7194 2603
7884 18727
8673 19951
25193 28026
29637 31798
38631 15482
41067 3684
46800 3626
75744 17776
aponta para mim o PID 17776, que é uma instância do VirtualBox. (Outros processos com muitos arquivos abertos são Chrome, Opera e Thunderbird.) Então eu não ficaria surpreso em descobrir depois que a principal causa desse problema é o VirtualBox, porque é a única coisa que realmente mexe com o kernel. / p>
No entanto, o problema não desaparece mesmo se eu encerrar o VirtualBox e eliminar o Chrome, o Opera e o Thunderbird.