我们构建了一个始终运行的系统 - 它收集并显示数据图表。如果我们在足够长的时间内不进行任何更改，我们最终会发生 oom-killer 事件。这会杀死我们的主进程（它的 oom 分数很高）并且我们的软件会重新启动。
基础知识：系统是CentOS 6，内核是2.6.32.26。该系统有 2G 内存和 4G 交换空间。该应用程序是用 C++ w/Qt 3 编写的。
我设置了一个 cron 作业来每分钟抓取 /proc/meminfo 和 /proc/slabinfo 的内容。以下是我从 meminfo 数据中发现的最有趣的痕迹（最新的 oom-killer 位于图表的右侧）：
注意 SUnreclaim 会一直增长，直到 oom-killer 出现为止。 SUnreclaim 上斜率的变化是我切换显示的地方。
以下是labinfo 数据中的一些有趣的痕迹：
在我看来，这就像有东西正在泄漏或破碎。当我的进程终止时，无论它是什么似乎都会被清理掉，但老实说我不知道这里发生了什么。
我怎样才能知道泄漏的是什么？
更新：在此过程的早期，我从 ps 输出开始（此处未显示）。我们所有流程的 RSS 值都会快速上升到“正常”水平，然后保持不变。如果这是一个使用正常内存运行的进程，我就不需要帮助。相反，我们正在做的一些事情会导致分配不可交换的内存。
至于升级建议：代码库对旧库有很多依赖，我现在甚至无法过渡到 3 系列内核。
答案1
你问了两个问题。
1) 如果 OOM Killer 运行并且您没有交换，这可能与您的 vm.swappiness 设置有关。尝试将其设置为 1。在您过时的+高度可破解的内核（不寒而栗）上，设置为 0（我记得），完全禁用交换，这可能不是您想要的。
2) 确定您的泄漏程序可能就像反复运行 ps auxww 寻找不断增加的 RSS 值或其他一些指标一样简单。
这一切都说...
你的内核很旧了。 PHP 的上限为 5.3（高度可破解）。 OpenSSL 有问题。许多相关库都很旧+可能是内存泄漏的根源。
最好升级到最新的发行版。简单的升级可能会安装更新的代码，从而解决内存泄漏问题。