如果我错了请纠正我,但据我理解板坯可回收保存缓存的内核对象,如果需要,可以释放这些对象。因此,如果应用程序需要分配更多空间,即使“可用”内存不足,操作系统也会从中删除一些页面板坯可回收并为应用程序提供所请求的内存量(除非不可能)。
我的记忆是这样的: 内存图 和 /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
我注意到的第一件事是,slab 和 cache 是所用内存的精确副本,也就是说是恒定的。
对于问题:
有时当可用内存达到 100 Mb 左右时,会调用 OOM-killer,终止重要进程(php、clamd 等)。这怎么可能?在调用 OOM 之前,OS 空闲内存块不应该可回收吗?
我尝试过的事情
我尝试设置
vm.vfs_cache_pressure=10000
我认为它将强制内核丢弃更多的缓存,但是即使 24 小时后图表也没有改变。
或许这是内核本身的一个错误https://bugzilla.kernel.org/buglist.cgi?quicksearch=oom&list_id=904801
答案1
这可能是尽管有足够的内存可用,但 Linux 进程仍被终止其中有一个与此 Ubuntu 错误报告相关的链接:https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1655842
答案2
如果你能提供 OOM 日志就好了。内核中提到的 bug尽管有足够的内存可用,但 Linux 进程仍被终止似乎是在谈论 2 阶内存(16kb 物理连续的内存分配),我相信这个问题在后来的内核中已经得到解决(https://lkml.org/lkml/2016/11/29/618)