我正在使用内核 4.3.3-hardened-r4 运行 Gentoo Hardened AMD64。由于我的系统只运行一些基本的守护进程，如 wpa_supplicant、cron 或 DHCP，并且 X 会话仅打开 Windowmaker、GKrellM 和 xterm，随着时间的推移，Linux 开始消耗越来越多的 RAM，直到大约 8-12 小时后才结束RAM 耗尽并引发内核恐慌。这与 Linux 报告用于缓冲区和文件系统缓存的 RAM 占用情况无关，因为 top、htop 和 GKrellM 都考虑了这些情况并显示进程实际占用了多少 RAM。直到最近，我还以为它链接到了我的 Bitcoin Core 客户端，但事实并非如此（我只是在我的 Linux 系统启动时偶然运行了该应用程序）。
在某些情况下，我能够看到我的 RAM 使用情况在发布完整世界更新 ( emerge -NDu --with-bdeps=y @world) 时突然恢复正常，但我无法重现此解决方法。
到目前为止，我已经尝试了以下修复：
- 在我的内核上编译 NUMA 支持（默认情况下 Gentoo 的 genkernel 不启用）并添加
vm.zone_reclaim_mode=1到我的 sysctl 中。没用。 - 添加
vm.drop_caches=1到我的 sysctl.没用。 - 检查 tmpfs 安装是否已满。我的 tmpfs 挂载几乎没有记录超过 1 MB 的文件系统使用情况。
这种行为的证据可以在这些屏幕截图中看到：
附件一：其中正在运行的唯一消耗内存的进程是 Firefox、GKrellm 和 X，而 Linux 却消耗了近 3 GB 的核心。 笔记：我没有在这里启用交换空间（它位于 USB 3.0 外部硬盘上，因为我的内部硬盘又旧又慢），但即使启用了交换空间，在保留 Bitcoin Core 8 个多小时后，我仍然会遇到 OOM 内核恐慌跑步。
附件B：为了防止 htop 和 GKrellm 有缺陷，我用 top 进行了仔细检查。相同的结果。
附件C：我的 tmpfs 挂载使用情况统计信息、我的输出free和我的内容/proc/meminfo 可以在这里找到。
这篇文章经过大量编辑，以反映我最近的发现。旧帖子可以在这个Pastebin在这里。
答案1
您是否有基于 SHM 的安装，例如内存支持/tmp或/var/tmp？即使进程退出后，也可能会生成临时文件，这些文件也会消耗内存。这些文件将保留在内存中，直到它们被删除或系统重新启动。检查您的挂载/etc/fstab以及mounttmpfs 条目。
另请检查您的日志轮换，因为它可能会在临时目录中创建大文件。如果您使用 systemd，可能值得清除日志。例如：
journalctl --vacuum-size=500M
答案2
把它们加起来：
- 使用比特币客户端后，它开始吞噬你的内存，直至崩溃
- 它不会返回记忆（直到你做了一些奇怪的事情）
第一个看起来像是典型的内存泄漏。您可以使用 检查程序的性能和内存管理valgrind，但它会大大减慢程序的速度。
第二个问题可能是第一个问题的后代。我不知道为什么会发生这种情况，但我只能猜测是因为内存问题（或大量内存消耗，或者可能是其他一些错误 - 例如进程卡在 D 状态？）。由于其他应用程序没有显示相同的行为，我猜问题是比特币软件，而不是您的系统。
因此，我们为解决这个问题所做的一切都将是一种黑客行为。可能会有成功的黑客攻击，但这仍然不是最好的方法。如果您可以访问源代码，并且了解一些编程知识，则可以尝试运行一些静态代码分析器来查看是否有任何“简单”的错误需要修复。您可以尝试使用 调试其内存管理valgrind。如果您没有这些（代码/技能），您能做的最后一件事就是向开发人员提供反馈 - 可能是一些错误跟踪器、论坛或邮件列表。这样有人就会调查它，并确认（并希望解决）问题。
答案3
因此，在对这个问题进行了近两个月的困惑之后，我决定询问如何启用vm.zone_reclaim_modesysctl 选项并使用不同的值进行一些操作，你瞧，问题解决了。
解决方案：
- 启用
CONFIG_NUMA我的内核配置并重建它。 - 放在
vm.zone_reclaim_mode = 7sysctl.conf 上
现在我的系统终于可以保持完整超过 24 小时了。
我有点担心性能下降，因为内核文档说 NUMA 和如此激进的区域回收设置可能会减慢速度，但现在我的系统终于可以工作了。