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

Question

在 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 杀手，进程被杀死，并且问题开始出现即使-/+ 缓冲区/缓存行中的“空闲”仍然有大约 1.4 GB 的“空闲”。

我已经调整了关键进程的 oom_adj 值，所以它不会使系统陷入困境，但即使如此，重要的进程也会被杀死，我们永远不想达到那个点。特别是当理论上 1.4GB 仍然是“免费的”时，如果它只会驱逐磁盘缓存。

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

我脑海中浮现的第一件事是交换已关闭。我们有一个坚定不移的系统管理员；如果他们得到支持，我愿意接受解释。这会导致问题吗？

运行后这里是免费的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

Answer 1

我已经找到了我自己问题的答案 - 感谢 womble 的帮助（如果您愿意，请提交答案）。

lsof -s 显示正在使用的文件句柄，结果发现有几 GB 的 mmap 日志文件占用了缓存。

实现 logrotate 应该可以完全解决问题并让我能够利用更多内存。

我还将重新启用交换，这样我们将来就不会出现 OOM 杀手的问题。谢谢。