我有一个erlang集群，其中erlang：内存（）'总计'从空闲到繁忙时间在2-2.5GB之间，日复一日。ets内存使用量大约在440M左右，并且无论如何都保持在那里。ets中的数据非常短暂，全天都在变化。明天的数据保证与今天的数据没有共性。
Linuxtop表示，Beb的使用量大约为10 GB。free-m'use'同意这一点（机器实际上只运行Beb）。系统的整体内存使用量有规律地增长，就像16GB系统上每天增长1%。节点之间存在一些差异，但不是很多，OS“使用”的内存总是比erlang：内存（）总量多几倍。
erlang：system_info（{allocator，ets_alloc}）显示了20个分配器。大多数的数据看起来像这样（命令的完整输出在这里）：
{mbcs_pool,[{blocks,2054},
{blocks_size,742672},
{carriers,10},
{carriers_size,17825792}]},
1）这是否意味着742K字节（单词？）的内存实际上17M了OS内存？2）正如这篇文章所建议的，我们应该在VMargs中添加“MEas bf”，以减少开销吗？3）我还能做些什么来避免实际运行的内存溢出？
这是R17.5，但我们将在下一次部署（本周）中迁移到R19.3。我们在当前部署中没有recon，但将在下一次部署中添加它。此外，无法想象这很重要，但光束正在高山容器中运行。
以防以后有人遇到这种情况：这实际上不是泄露的内存。
erlang的默认内存分配器策略可能不适合您的使用，这取决于您做什么，以及erlang如何配置分配块。事实证明，在某些情况下，从erlang的角度来看，由于分配器碎片，“释放”内存不一定会立即释放到OS。
这里有点解释：http://erlang.org/doc/man/erts_alloc.html
我们当时使用的erlang版本的默认分配器策略是aoffcbf（地址顺序优先匹配载体最佳匹配）。在我们的例子中，这导致了非常高的内存碎片（10 GB开销）。在对这些事情进行故障排除时，erlang：system_info（分配器）和erlang：system_info（{allocator， Alloc}）是您的朋友。更改为aobff（地址顺序最佳匹配）会导致更有效的内存使用。事实上，只要机器没有耗尽物理内存，这并不重要，但对我们来说，我们正危险地接近物理限制。你不想开始分页。使用aobff，即使在节点运行了18个月之后，我们也从未超过4GB。使用aoffcbf，我们将在几周内超过10GB。
像往常一样，YMMV，因为这一切都取决于什么类型，大小等。
