Erlang ETS内存碎片

Question

我有一个erlang集群，其中erlang：memory（）“总”每天从空闲到繁忙时间在2-2.5GB之间。 ets的内存使用量约为440M，无论如何都保持不变。 ets中的数据是高度瞬态的，全天都在变化。 明天的数据可以保证与当今没有共同点。

Linux负责人说Beam正在使用10 GB的数据。 free -m'used'同意这一点（机器实际上仅运行横梁）。 系统的整体内存使用量有规律地增长，例如在16GB系统上每天增加1％。 节点之间存在一些差异，但不是很多，并且操作系统“已用”内存始终是erlang：memory（）总数的几倍。

erlang：system_info（{allocator，ets_alloc}）显示20个分配器。 大部分数据看起来像这样（命令的完整输出在此处 ）：

    {mbcs_pool,[{blocks,2054},
   {blocks_size,742672},
   {carriers,10},
   {carriers_size,17825792}]},

1）这是否意味着实际上742K字节（字？）的内存占用了17M的OS内存？ 2）正如这篇文章所暗示的，我们是否应该在VM args中添加“ + MEas bf”，以减少开销？ 3）我还能做些什么来避免实际用完内存？

这是R17.5，但是我们将在下一个部署（本周）中迁移到R19.3。 我们在当前部署中没有侦察功能，但是将在下一个部署中添加它。 同样，无法想象这很重要，但是光束正在高山容器内运行。

Answer 1

万一以后有人遇到：这实际上不是泄漏的内存。

erlang的默认内存分配器策略可能对您的使用不是最佳的，具体取决于您的操作以及取决于erlang配置为分配块的方式。 事实证明，在某些情况下，由于分配器碎片，从erlang角度来看，“可用”内存不一定会立即释放到OS。

这里对此做了一些解释： http : //erlang.org/doc/man/erts_alloc.html

我们当时使用的erlang版本的默认分配器策略是aoffcbf（地址顺序优先适合的载体最适合）。 在我们的案例中，这导致了很高的内存碎片（相当于10 + GB的开销）。 对这些问题进行故障排除时， erlang:system_info(allocator)和erlang:system_info({allocator, Alloc})是您的朋友。 更改为aobff（最适合地址顺序）可提高内存使用效率。 实际上，只要机器没有物理内存用完就没关系，但是对我们来说，我们正接近物理极限，这很危险。 并且您不想开始分页。 使用aobff，即使节点运行了18个月，我们也从未超过4GB。 使用aoffcbf，我们将在几周内通过10GB。

与以往一样，YMMV取决于分配的块的类型，大小等以及它们的生存时间。