代码之家 › 专栏 › 技术社区 › mritalian

Erlang ETS内存碎片

ets erlang

1

mritalian · 技术社区 · 6 年前

我有一个erlang集群,其中erlang:memory()“total”从空闲到繁忙时间每天都在2-2.5GB之间。ets内存使用量约为440M,无论发生什么情况,都会保持在440M左右。ets中的数据是非常短暂的,全天都在变化。Tomorrows数据保证与今天的数据没有共性。

Linux top表示beam的使用量大约为10GB。free-m“used”同意这一点(机器实际上只运行梁)。系统的总体内存使用率有规律地增长,在16GB系统上每天增长1%。节点之间有一些差异,但不是很大,操作系统“使用”的内存总是比erlang:memory()总数多出几倍。

erlang:system\u info({allocator,ets\u alloc})显示20个分配器。大多数都有类似这样的数据(命令的完整输出是 here ):

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

1) 这是否意味着742K字节(字?)的内存占用了1700万操作系统内存? 2) 作为 this post 建议,我们是否应该在VM参数中添加“+MEas bf”,以减少开销? 3) 我还能做些什么来避免实际内存不足?

这是R17。5但我们将迁移到R19。3在下一次部署中(本周)。我们在当前部署中没有侦察,但将在下次部署中添加侦察。此外,无法想象这有什么关系,但beam正在阿尔卑斯山的一个集装箱内运行。

1 回复 | 直到 6 年前

1

0

mritalian 5 年前

万一后来有人遇到这种情况:这实际上不是泄漏的内存。

erlang的默认内存分配器策略可能并不适合您的使用,这取决于您所做的工作以及erlang配置为分配块的方式。事实证明,在某些情况下,由于分配器碎片,从erlang的角度来看,“空闲”内存不一定会立即释放到操作系统。

这里有一些解释: http://erlang.org/doc/man/erts_alloc.html

我们当时使用的erlang版本的默认分配器策略是aoffcbf(address order first fit carrier best fit)。在我们的例子中,这导致了非常高的内存碎片(10 GB以上的开销)。在排除这些故障时, erlang:system_info(allocator) 和 erlang:system_info({allocator, Alloc}) 是你的朋友。更改为aobff(地址顺序最佳匹配)可以提高内存使用效率。事实上,只要机器没有耗尽物理内存,这没关系,但对我们来说,我们正危险地接近物理极限。并且您不想开始分页。使用aobff,我们从未超过4GB,即使在节点运行了18个月之后。使用aoffcbf,我们将在几周内通过10GB。

像往常一样,YMMV,因为它完全取决于什么类型、大小等。。分配的块数,以及它们的寿命。