Erlang“系统”内存部分不断增长答案

【问题标题】：Erlang "system" memory section keeps growingErlang“系统”内存部分不断增长
【发布时间】：2013-01-23 05:37:01
【问题描述】：

我有一个具有以下模式的应用程序：

2 个长时间运行的进程在一些空闲时间后进入休眠状态并且它们的内存消耗按预期下降
N (0
在夜间，当没有活动时，进程内存几乎恢复到与应用程序启动时的值相同，预期为所有工人都死了。

问题是“系统”部分不断增长（大约 1GB/周）。

我的问题是如何调试那里存储的内容或谁在该区域分配内存并且没有释放它。

我已经测试过 lists:keysearch/3 并且它似乎没有泄漏内存，因为这是我使用的唯一原生的东西（没有端口，没有驱动程序，没有 NIF ，没有 BIF，什么都没有）。 Erlang 版本为 R15B03。

这是当前的 erlang:memory() 输出（少量流量，应用于 2 月 3 日启动）：

[{total,378865650},
{processes,100727351},
{processes_used,100489511},
{system,278138299},
{atom,1123505},
{atom_used,1106100},
{binary,4493504},
{code,7960564},
{ets,489944},
{maximum,402598426}]

这是一个 64 位系统。如您所见，“系统”部分有大约 270MB，“进程”大约有 100MB（夜间下降到大约 16MB）。

【问题讨论】：

注意到类似的行为。我相信它与使用分代垃圾收集的 Erlang 有关，但我无法确认。
如果是这种情况，在所有 erlang PID 上重复 erlang:garbage_collect() 或garbage_collect(Pid) 应该可以修复它。它所做的只是释放一些“进程内存”，而不是“系统”。这是 IT 中如此常见的词，以至于无法找到有关存储在那里的数据类型的文档。另外，顺便说一下，操作系统报告使用的常驻内存增加了大约 70%。
你能定期运行 memsup:get_memory_data/0 吗？它显示了节点上最大的 Erlang 进程的 Pid 和分配的字节数。可能会提供一些见解
几个问题：内存增长会持续到崩溃吗？如果您执行显式 GC，内存会减少吗？增长的只是系统区域吗？
GC 减少 process_memory 部分。 “系统”部分保持不变。是的，那是一直在增长的领域，这就是我想以某种方式调试的领域。我不知道它是否会崩溃，因为这是一台实时机器，并且应用程序不会丢失飞行中的数据。我每周左右重新启动应用程序。 memsup:get_memory_data() 似乎不可用，因为它返回：(agstats@agentlogin-statistics)3> memsup:get_memory_data()。 {0,0,{,0}}

标签： debugging memory-leaks erlang

【解决方案1】：

我好像找到了问题。

我有一个“process_killer”gen_server，其中进程可以订阅定期 GC 或终止。它的订阅函数会在某些进程收到的每条消息上调用，以推迟 GC/kill（类似于重新武装）。

如果尚未监视此进程，则执行 erlang:monitor 以捕获死进程并将其从监视列表中删除。如果我在每条处理的消息上评论我们的重新订阅行，“系统”区域似乎表现正常。这意味着它是我的 process_killer 中的一个错误，它确实泄漏了监视器引用（请记住，您可以多次调用 erlang:monitor 并且每次调用都会创建一个引用）。

我之所以产生这个想法，是因为我测试了一个简单的模块，它在循环中调用 erlang:monitor，并且我看到每次调用都会增加约 13 字节的“系统”区域。

工人们自己还好，因为无论如何他们都会带着显示器死去。有一个长时间运行（从应用程序开始，从应用程序停止）进程将所有消息发送给在收到的每条消息上调用 GC re-arm 的工作人员，所以我们谈论的是每个产生的数以万计的监视器小时，从未发布。

我在这里写下这个答案以供将来参考。

TL;DR;确保您没有在长时间运行的进程中泄漏监视器引用。

【讨论】：