Рекламируемая память Slab не освобождается при необходимости

Поправьте меня, если я ошибаюсь, но, насколько я понимаю, slab reclaimable содержит кэшированные объекты ядра, которые можно освободить, если необходимо. Таким образом, если приложению необходимо выделить больше места, даже если «свободной» памяти мало, ОС сбросит некоторые страницы из slab reclaimable и предоставит приложению запрошенный объем памяти (если это невозможно).

Так выглядит моя память: Граф памяти и / proc / meminfo output:

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

Первое, что я заметил, это то, что slab и cache являются точной копией используемой памяти, то есть непрерывны.

К проблеме:

Иногда, когда объем свободной памяти достигает значений около 100 Мб, вызывается OOM-killer, убивающий жизненно важные процессы (php, clamd, ...). Как такое возможно? Разве ОС не должна восстанавливать свободную плиту перед вызовом OOM?

То, что я пробовал

Я попытался установить

vm.vfs_cache_pressure=10000

, думая, что это заставит ядро ​​сбросить больше кешей, но график не изменился даже через 24 часа.

Возможно, это ошибка в самом ядре https://bugzilla.kernel.org/buglist.cgi?quicksearch=oom&list_id=904801