A memória recuperável da placa não é liberada quando necessário

Question

Corrija-me se estiver errado, mas, para mim, o slab reclaimable contém objetos do kernel em cache que podem ser liberados se necessário. Portanto, se o aplicativo precisar alocar mais espaço, mesmo que a memória "livre" seja baixa, o SO deixará algumas páginas do laje recuperável e do aplicativo privado com a quantidade solicitada de memória (a menos que isso não seja possível).

É assim que minha memória parece: Gráfico de memórias e saída / proc / meminfo:

MemTotal:        8171852 kB
MemFree:          825892 kB
MemAvailable:    6273852 kB
Buffers:          227448 kB
Cached:          1261944 kB
SwapCached:        15324 kB
Active:          2582260 kB
Inactive:         499232 kB
Active(anon):    1460764 kB
Inactive(anon):   131340 kB
Active(file):    1121496 kB
Inactive(file):   367892 kB
Unevictable:          32 kB
Mlocked:              32 kB
SwapTotal:        524284 kB
SwapFree:         440372 kB
Dirty:               372 kB
Writeback:             0 kB
AnonPages:       1579556 kB
Mapped:            40500 kB
Shmem:                 4 kB
Slab:            4113080 kB
SReclaimable:    4061308 kB
SUnreclaim:        51772 kB
KernelStack:        6992 kB
PageTables:        70692 kB
NFS_Unstable:          0 kB
Bounce:                0 kB
WritebackTmp:          0 kB
CommitLimit:     4610208 kB
Committed_AS:    2644508 kB
VmallocTotal:   34359738367 kB
VmallocUsed:           0 kB
VmallocChunk:          0 kB
DirectMap4k:       14200 kB
DirectMap2M:     2082816 kB
DirectMap1G:     8388608 kB

A primeira coisa que notei é que a laje e o cache são a cópia exata da memória usada, ou seja, é contant.

Para o problema:

Às vezes, quando a memória livre atinge valores em torno de 100 Mb, o OOM-killer é chamado, eliminando processos vitais (php, clamd, ...). Como isso é possível? A laje livre do OS não deve ser recuperada antes de invocar a OOM?

Coisas que tentei

Eu tentei definir

vm.vfs_cache_pressure=10000

achando que forçará o kernel a derrubar mais caches, mas o gráfico não mudou, mesmo depois das 24H.

Talvez seja um bug no próprio kernel link

    

Answer 1

Isso pode ser uma cópia de processo do Linux morto, mesmo com memória suficiente disponível que tem um link relevante para este relatório de bug do Ubuntu: link