纠正我，如果我错了，但我的理解板可回收持有caching的内核对象，可以释放，如果需要的话。 因此，如果应用程序需要分配更多的空间，即使“空闲”内存不足，操作系统也会从所需的内存量（除非不可能）中删除某些可回收的应用程序和私有应用程序的页面。
这是我的记忆看起来： Memgraphics和/ 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杀手，从而杀死重要的进程（php，clamd，…）。 这怎么可能？ 在调用OOM之前不应该释放slab可用的slab？
我试过的东西
我试着设置
vm.vfs_cache_pressure=10000
认为它会迫使内核放弃更多的caching，但是图表没有改变，甚至在24小时之后。
也许它是一个内核本身的bug https://bugzilla.kernel.org/buglist.cgi?quicksearch=oom&list_id=904801
这可能是一个Linux进程的重复， 尽pipe有足够的内存可用 ，但有相关的链接到这个Ubuntu的错误报告： https ： //bugs.launchpad.net/ubuntu/+source/linux/+bug/1655842