3

Correct me if I am wrong, but to my understanding slab reclaimable holds cached kernel objects which can be freed if needed. So if application needs to allocate more space, even if the 'free' memory is low, OS will drop some pages from slab reclaimable and privide application with the requested amount of memory (unless its not possible).

This is how my memory looks: Mem graph and /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

First thing I noticed is that the slab and cache are the exact copy of memory used, meaning is contant.

To the problem:

Sometimes when free memory reaches values around 100 Mb, OOM-killer is invoked, killing vital processes (php, clamd, ...). How is that possible? Shouldnt OS free slab reclaimable before invoking OOM?

Things I tried

I tried setting 

vm.vfs_cache_pressure=10000

thinking it will force kernel to drop more caches, but the graph didnt change, even after 24H.

Perhaps its a bug in kernel itself https://bugzilla.kernel.org/buglist.cgi?quicksearch=oom&list_id=904801

Horkyze
  • 151
  • 1
  • 4
  • I can't help but I am seeing something very similar myself. I tried setting vm.overcommit_memory=1 but that didn't work. – David Glasser Feb 03 '17 at 17:55
  • Same issue on my virtual machine. This should be [kernel bug 74771](https://bugzilla.kernel.org/show_bug.cgi?id=74771). – vinc17 Feb 03 '20 at 12:13

2 Answers2

0

This may be a duplicate of Linux process killed even though enough memory available which has a relevant link to this Ubuntu bug report: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1655842

Community
  • 1
David Glasser
  • 101
  • 2
0

It would be good if you provided the OOM log. The bug in the kernel mentioned in Linux process killed even though enough memory available seems to be talking about order 2 memory (16kb of physically contiguous memory allocations) and i believe that problem has been addressed in the later kernel (https://lkml.org/lkml/2016/11/29/618)

Jacek Tomaka
  • 121
  • 2