可用 RAM 消失 - 内存泄漏？

Question

在新启动的系统上，free报告使用了大约 1.5G 的 RAM（总共 8G RAM，带有 lightdm 和等离子桌面的 Ubuntu 12.04，一个 konsole 窗口已启动）。运行我使用的应用程序，它仍然消耗不超过 2G。但是，让系统运行几天后，我的可用 RAM 越来越多消失了——没有出现在使用过的应用程序列表中：虽然smem --pie=name报告使用率低于 20%（并且 80%​​ 可用），但其他一切都说不同。free -m例如大约第 7 天的报告：

             total       used       free     shared    buffers     cached
Mem:          7459       7013        446          0        178        997
-/+ buffers/cache:       5836       1623
Swap:         9536        296       9240

（所以你可以看到，它不是缓冲区或缓存）。今天，这最终以系统完全崩溃而告终：Windows 管理器消失了，应用程序“悬而未决”（无框架）——以及一个弹出窗口，通知我“打开的文件太多”。系统日志报告：

kernel: [856738.020829] VFS: file-max limit 752838 reached

所以我关闭了那些我能够关闭的应用程序，并使用 Ctrl-Alt-backspace 杀死了 X。之后 X 尝试使用 failsafeX 再次启动，但无法这样做，因为它无法再检测到其配置。所以我使用 Ctrl-Alt-F2 切换到控制台，捕获我能想到的所有信息（vmstat、free、smem、... proc/meminfo、lsof、... ps aux），最后重新启动。X 再次提出了 failsafeX；这次我告诉它“从我备份的配置中恢复”，然后切换到控制台并成功用于调startx出图形环境。

我不知道是什么导致了这个问题——尽管它必须与 X 本身有关，或者与 X 上运行的一些用户进程有关——在杀死 X 之后，free -m输出看起来像这样：

             total       used       free     shared    buffers     cached
Mem:          7459       2677       4781          0         62        419
-/+ buffers/cache:       2195       5263
Swap:         9536         59       9477

(~ 3.5GB 被释放) -- 与重新启动后的输出进行比较：

             total       used       free     shared    buffers     cached
Mem:          7459       1483       5975          0         63        730
-/+ buffers/cache:        689       6769
Swap:         9536          0       9536

提供了两个更有帮助的输出memstat -u。坠机前不久：

User     Count     Swap      USS      PSS      RSS
mail         1        0      200      207      616
whoopsie     1      764      740      817     2300
colord       1     3200      836      894     2156
root        62    70404   352996   382260   569920
izzy        80   177508  1465416  1519266  1851840

X被杀后：

User     Count     Swap      USS      PSS      RSS
mail         1        0      184      188      356
izzy         1     1400      708      739     1080
whoopsie     1      848      668      826     1772
colord       1     3204      804      888     1728
root        62    54876   131708   149950   267860

重新启动后，回到 X：

User     Count     Swap      USS      PSS      RSS
mail         1        0      212      217      628
whoopsie     1        0     1536     1880     5096
colord       1        0     3740     4217     7936
root        54        0   148668   180911   345132
izzy        47        0   370928   437562   915056

编辑：刚刚从我的监控系统中添加了两个图表。有趣的是：每次当内存消耗出现“跳跃”时，CPU 也会达到峰值。现在刚发现这个——它让我想起了另一个指向 X 本身的指示器：通常在返回我的机器并解锁屏幕时，我发现一些东西在我的 CPU 上做繁重的工作。查了一下top，结果总是这样/usr/bin/X :0 -auth /var/run/lightdm/root/:0 -nolisten tcp vt7 -novtswitch -background none。

所以经过这么长时间的解释，最后我的问题是：

1. 可能的原因是什么？
2. 我怎样才能更好地识别涉及的流程/应用程序？
3. 可以采取哪些步骤来避免这种行为——短于 X 天重启机器？

我在我的旧机器上运行 8.04 (Hardy) 大约 5 年，从来没有经历过类似的事情（总是超过 100 天的正常运行时间，然后重新启动以进行内核更新）。现在这是一台全新安装 12.04 的全新机器。如果重要，一些规格：

AMD A4-3400 APU 配备 Radeon(tm) HD Graphics，使用开源 ati/radeon 驱动程序（因此未安装 fglrx）、8GB RAM、WDC WD1002FAEX-0 hdd (1TB)、Asus F1A75-V Evo 主板。带有 KDE4/Plasma 的 Ubuntu 12.04 64 位。通常会或多或少永久打开的应用程序包括 Evolution、Firefox、konsole（内部运行 Midnight Commander，大约有 4 个选项卡）和 LibreOffice——偶尔还有 Calibre、Gimp 和 Moneyplex（我已经使用了近 20 年的银行软件，在一个在 Hardy 上做得很好的版本中）。

编辑： 今天我发现了一个“邪恶的家伙”：KDE4s 等离子桌面。当我执行killall plasma-desktop && plasma-desktop. 这释放了 1.3GB RAM！ps说：

                             RSS    SIZE   VSZ
plasma usage before restart  120988 526472 1300816
plasma usage after restart   92352  495972 1263632

那么那些 1.3GB 去哪儿了？这些值之间的差异（如果加起来）为 96MB——而不是 1.3GB。

这只能是一部分，因为还有 3.7GB 正在使用中（应该小于 2GB）。在过去的 6 天里，我使用多种工具对此进行了监控：已用内存（不是谈论缓存和缓冲区）缓慢但稳定地增加。即使我不在办公桌前运行任何东西...

至于使用打开文件监控进程，我目前使用以下 1-liner（我喜欢 shell，尤其是 bash）来获得前 5 名：

echo "$(for pid in $(ls -a /proc|egrep '^([0-9])*$'|sort -n 2>/dev/null); do \
if [ -e /proc/$pid/fd ]; then FHC=$(ls -l /proc/$pid/fd|wc -l); \
if [ $FHC -gt 0 ]; then PNAME="$(cat /proc/$pid/comm)"; \
echo "$FHC files opened by $pid ($PNAME)"; fi; fi; done)"|sort -r -n|head -n5

在这里用 4 行命令以提高可读性。还没有什么——除了 Skype 不喜欢互联网连接中断。每次断开连接都会导致其打开的文件略有增加，但没有什么戏剧性的。另一方面，似乎等离子也对此负责：

看到最后的文件句柄了吗？那是等离子重启。

Answer 1

1. 大量打开的文件是出现问题的好线索。我的猜测是一些 KDE 系统守护进程。

2. 打开控制台并运行“top”。然后使用<和>将排序列改为VIRT或RES，看看哪些程序使用的内存最多。内存泄漏将表现为大量膨胀的虚拟内存使用，因为一旦指向泄漏内存的指针丢失，它将不会被使用并将被换出。还运行“lsof”并查找具有大量打开文件的进程，因为这似乎确实是文件描述符泄漏。

3. 跟踪程序并报告错误。