我正在运行 ejabberd 机器，用于通过XMPP向应用程序数据发送应用程序，但最近，从 ejabberd 16升级到最新的18.04-0， ejabberd 正在关闭一个消息：Killed 1 process(es) consuming more than 38108 message(s) each。
我研究了这个问题，found在 ejabberd 17.12中，他们优化了oom_killer。
我的机器有12G内存，专用于运行ejabberd，有7G可用内存，但它仍然会杀死进程。
我在第275行查看了source，是罪魁祸首的方法，但我注意到它有一个参数＆＃34; threshold＆＃34;它检查，但我无法在文档中找到任何内容。是否可以配置它？现在我必须设置＆＃34; oom_killer：false＆＃34;为了克服这个问题，但是我会怀疑它会让我回想起来（注意：这是一个坏主意，服务器最终交换到最后）。
我远不是erlang或ejabberd的专家，我们欢迎任何优化内存使用或oom_killer的建议。
=== edit ===
我忘了提到我在Ubuntu 16.04 x64（vmware上的虚拟机）上运行它。
==更新第2天==
我可以从日志中找到： CRASH.LOG：
2018-05-15 15:01:40 =ERROR REPORT====
Killed 1 process(es) consuming more than 15112 message(s) each2018-05-15 15:47:35 =ERROR REPORT====
Killed 1 process(es) consuming more than 27255 message(s) each2018-05-15 17:58:02 =ERROR REPORT====
Killed 1 process(es) consuming more than 11686 message(s) each2018-05-15 18:46:12 =ERROR REPORT====
Killed 1 process(es) consuming more than 42388 message(s) each2018-05-16 07:43:31 =ERROR REPORT====
Killed 1 process(es) consuming more than 47615 message(s) each2018-05-17 13:47:16 =ERROR REPORT====
backend port not found: inotifywait
和ejabberd.log基本上只重复了我之前展示过的那一行，然后就没有了。 事实上，ejabber本身一直在运行，但是有一个非常繁忙的房间在这个崩溃消息之后变得无法访问（可以安全地假设这个房间崩溃了吗？）。 我将在调试中运行ejabberd以希望获得更多信息。
我发现在此期间，ejabberd 17.01或更早版本中没有此内存问题。
我对Ubuntu repo ejabberd没有这个问题，这是16.01或者来自ProcessOne的17.01版本，我测试的版本和17.12（17.12有确认的内存泄漏虽然在18.01修复了）的问题）和18.04。
无论如何我很难过，而且我对如何调试没有想法。
==更新第3天==
我找不到ejabberd 18.04的内存问题的解决方案，但我将在下周试用FreeBSD和Ubuntu 18.04。
我还得出结论，我的整个代码体系结构都存在问题。
为了澄清这种情况，我收集来自不同来源的信息，处理该信息并使用python编写的机器人将数据保存到数据库，并通过xmpp进行通信。 一个机器人读取数据并发送到一个房间，下一个机器人读取数据并添加新信息，下一个验证并发送到收集室。
由于存在许多源，并且所有这些源的终点与归档程序尝试将其保存到mongo的位置相同，这意味着收集室进程每分钟会收到数千条消息。
问题是，所有信息在保存之前都会在一个房间中结束，我想存档过程不能足够快地读取消息并且＆＃34;＆＃34;＆＃34;发生的事情以内存问题和崩溃结束。
Ejabberd有其内部流程，并且能够轻松地处理成千上万的内容，但我想我不是在利用它，而是最终将所有内容都塞进一个流程中。
所以我会看到摆脱这个收集室的过程是否有助于加速一切。
会继续更新，也许我的实验可以帮助别人。