在2.6.31-302 x86-64内核上运行Ubuntu。 总体问题是，我在“caching”类别中有内存不断上升，即使在我们的应用程序需要它时也不会被释放或使用。
所以这里是我从“免费”命令中得到的。 乍一看，这一切都不寻常。
# free total used free shared buffers cached Mem: 7358492 5750320 1608172 0 7848 1443820 -/+ buffers/cache: 4298652 3059840 Swap: 0 0 0 有人想说的第一件事就是“别担心，linux会自动pipe理这个内存”。 是的，我知道内存pipe理员应该如何工作。 问题在于它没有做正确的事情。 这里“caching”的1.4 GB似乎是保留和不可用的。
我的Linux知识告诉我，3 GB是“免费”的; 但系统的行为却另有说法。 当1.6GB的真实可用内存在高峰使用期间用完时，只要需要更多的内存（并且第一列中的“空闲”接近0），调用OOM杀手，处理被终止，并且问题开始出现即使 – / + buffers / cache行中的'free'仍然有大约1.4 GB的空闲空间。
我已经调整了关键进程的oom_adj值，所以它不会使系统陷入瘫痪，但即使如此，重要的进程也将被杀死，而我们也不希望达到这一点。 特别是当理论上，如果只驱逐磁盘caching，则1.4GB仍然是“免费”的。
有没有人知道这里发生了什么？ 互联网充满了关于Linux“自由”命令的愚蠢问题，“为什么我没有任何可用的内存”，因此我找不到任何关于这个问题的信息。
我的脑海里浮现的第一件事就是换掉了。 我们有一个系统pipe理员是坚决的， 如果他们备份，我愿意解释。 这会导致问题吗？
在运行echo 3 > /proc/sys/vm/drop_caches之后，这里是免费的：
# free total used free shared buffers cached Mem: 7358492 5731688 1626804 0 524 1406000 -/+ buffers/cache: 4325164 3033328 Swap: 0 0 0
正如你所看到的，一些微不足道的caching实际上被释放了，但是大约1.4GB似乎被“卡住”了。 另一个问题是，这个价值似乎随着时间的推移而上升。 在另一台服务器上2.0 GB卡住了。
我真的很喜欢这回忆…任何帮助将不胜感激。
这里是cat /proc/meminfo如果它是值得的任何东西：
# cat /proc/meminfo MemTotal: 7358492 kB MemFree: 1472180 kB Buffers: 5328 kB Cached: 1435456 kB SwapCached: 0 kB Active: 5524644 kB Inactive: 41380 kB Active(anon): 5492108 kB Inactive(anon): 0 kB Active(file): 32536 kB Inactive(file): 41380 kB Unevictable: 0 kB Mlocked: 0 kB SwapTotal: 0 kB SwapFree: 0 kB Dirty: 320 kB Writeback: 0 kB AnonPages: 4125252 kB Mapped: 42536 kB Slab: 29432 kB SReclaimable: 13872 kB SUnreclaim: 15560 kB PageTables: 0 kB NFS_Unstable: 0 kB Bounce: 0 kB WritebackTmp: 0 kB CommitLimit: 3679244 kB Committed_AS: 7223012 kB VmallocTotal: 34359738367 kB VmallocUsed: 7696 kB VmallocChunk: 34359729675 kB DirectMap4k: 7340032 kB DirectMap2M: 0 kB
我已经发现了自己的问题的答案 – 感谢womble的帮助（如果你喜欢提交一个答案）。
lsof -s显示正在使用的文件句柄，结果表明有数千兆字节的mmap'd日志文件占用了caching。
实现一个logrotate应该完全解决这个问题，并允许我利用更多的内存。
我也会重新启用swap，所以我们在将来不会遇到OOM杀手。 谢谢。
显然，postgres的shared_buffers可以显示在cached ，而不是真的很容易丢弃… 尽pipe有可用的内存（caching）