我有一个erlang集群,其中erlang:memory() 'total‘是从空闲到繁忙时间的2-2.5GB之间,日复一日。ets的内存使用量约为440米,无论发生什么,都会在那里停留。ets中的数据是非常短暂的,整天都在变化。明天的数据与今天的数据没有任何共同性。
Linux说beam正在使用大约10G字节。免费的-m‘使用’同意这一点(机器实际上只运行梁)。系统的总体内存使用量有规律地增长,比如在16 on系统上每天使用1%的内存。节点之间有一些差异,但不是很多,操作系统‘使用的’内存总是比erlang: memory ()总数的几倍多。
erlang:system_info({allocator,ets_alloc})显示20个分配器。大多数数据的情况如下(命令的完整输出为这里):
{mbcs_pool,[{blocks,2054},
{blocks_size,742672},
{carriers,10},
{carriers_size,17825792}]},1)这是否意味着742 K字节(字?)内存中的内存实际上占用了17M的OS内存? 2)正如这个职位所建议的,我们是否应该在VM中添加“+MEas”,以减少开销? 3)我还能做些什么来避免内存实际耗尽?
这是R17.5,但我们将在下一次部署(本周)中迁移到R19.3。我们在当前部署中没有侦察,但将在下一个部署中添加它。而且,无法想象这有什么关系,但是梁在一个高山容器内运行。
发布于 2019-07-15 22:39:27
如果其他人稍后会遇到这样的情况:这实际上并没有泄漏内存。
erlang的默认内存分配策略对于您的使用可能不是最优的,这取决于您所做的事情,以及erlang配置为分配块的方式。在某些情况下,从erlang的角度来看,“释放”内存不一定会因为分配器碎片而立即释放到操作系统。
这里对此作了一些解释:alloc.html
我们当时使用的erlang版本的默认分配器策略是aoffcbf (地址顺序优先匹配载波最佳匹配)。在我们的例子中,这导致了非常高的内存碎片(10+GB开销值)。在排除这些问题时,erlang:system_info(allocator)和erlang:system_info({allocator, Alloc})是您的朋友。更改为aobff (地址顺序最适合)导致了更有效的内存使用。事实上,只要机器没有耗尽物理内存,那就无所谓了,但对我们来说,我们正危险地接近生理极限。而且您不想开始分页。对于aobff,我们从来没有超过4GB,即使在节点上升了18个月之后。有了aoffcbf,几周后我们就会超过10 we。
和往常一样,YMMV,因为这一切都取决于什么类型,大小等。分块,以及它们的寿命。
https://stackoverflow.com/questions/49847782
复制相似问题