Erlang的“系统”内存部分不断增长
我有以下模式的应用程序：
问题在于“系统”部分不断增长（大约1GB /周）。
我的问题是，如何调试那里存储的内容或谁在该区域分配内存，而不是释放它。
我已经测试了列表：keysearch / 3，它似乎没有泄漏内存，因为这是我使用的唯一本地东西（没有端口，没有驱动程序，没有NIF，没有BIF，没有）。 Erlang版本是R15B03。
这里是目前的erlang：memory（）输出（轻微的流量，应用程序从03年2月开始）：
[{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）。
看来我发现了这个问题。
我有一个“process_killer”gen_server，其中进程可以订阅定期GC或杀死。 它的订阅功能在某些进程收到的每个消息上被调用，以推迟GC / kill（类似于重新设置）。
这个过程执行一个erlang：monitor，如果这个监视器没有被监控，就会捕获一个死进程并将其从监视列表中删除。 如果我评论我们对每个处理消息的重新订阅行，“系统”区域似乎表现正常。 这意味着这是我的process_killer中的一个漏洞，它监控ref（请记住，您可以多次调用erlang：monitor并且每次调用都会创建一个引用）。
我引导了这个想法，因为我测试了一个简单的模块，它在一个循环中调用了erlang：monitor，并且在每次调用中我看到了〜13字节的“系统”区域。
工人们自己也没问题，因为他们无论如何都会带着监视器一起死去。 有一个长时间的运行（从应用程序开始，停止使用应用程序），将所有消息分发给调用GC重新接收每条消息的工作人员，所以我们讨论的是每个成千上万个监视器小时，从未发布。
我在这里写这个答案供将来参考。
TL; DR; 确保你在长时间运行的过程中不泄漏监控参考。
链接地址: http://www.djcxy.com/p/69165.html