当内存需求上升时，Linux无法释放大磁盘缓存

在2.6.31-302 x86-64内核上运行Ubuntu。总体问题是我的“高速缓存”类别中的内存一直在增加，即使我们的应用程序需要它也不会被释放或使用。

这就是我从“免费”命令中得到的东西。乍一看，这些都与众不同。

# free
             total       used       free     shared    buffers     cached
Mem:       7358492    5750320    1608172          0       7848    1443820
-/+ buffers/cache:    4298652    3059840
Swap:            0          0          0

有人要说的第一件事是：“不用担心，Linux自动管理该内存。” 是的，我知道内存管理器应该如何工作；问题在于它没有做正确的事。这里的“缓存” 1.4 GB似乎是保留的，无法使用。

我对Linux的了解告诉我3 GB是“免费”的。但是系统的行为则相反。在高峰使用期间用完1.6 GB的实际可用内存后，一旦需要更多内存（第一列的“可用”接近0），就会调用OOM杀手，杀死进程，并开始出现问题。即使 -/ + buffers / cache行中的“ free”仍然具有约1.4 GB的“ free”。

我已经调整了关键流程的oom_adj值，因此它不会使系统崩溃，但是即使那样，重要的流程也将被杀死，我们永远也不想达到这一点。尤其是从理论上讲，如果仅驱逐磁盘缓存，则1.4GB仍“可用”。

有人知道这里发生了什么吗？互联网上充斥着关于Linux“免费”命令和“为什么我没有任何可用内存”的愚蠢问题，因此我找不到关于此问题的任何信息。

首先出现在我脑海中的是交换已关闭。我们有一个坚定的系统管理员。如果有备份，我可以公开解释。这会引起问题吗？

运行后免费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

如您所见，实际上释放了少量的高速缓存，但是大约“ 1.4 GB”似乎被“卡住了”。另一个问题是该值似乎随着时间的推移而上升。在另一台服务器上，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 显示正在使用的文件句柄，结果表明有数GB的mmap日志文件占用了缓存。

实施logrotate应该可以彻底解决问题，并让我利用更多的内存。

我还将重新启用交换功能，以便将来我们不会遇到OOM杀手。谢谢。

显然，postgres shared_buffers可以显示在中cached，而实际上却不容易丢弃... 尽管有可用的内存（缓存），请参阅OOM