首页
学习
活动
专区
圈层
工具
发布
社区首页 >问答首页 >Erlang内存碎片

Erlang内存碎片
EN

Stack Overflow用户
提问于 2018-04-15 23:31:33
回答 1查看 424关注 0票数 1

我有一个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个分配器。大多数数据的情况如下(命令的完整输出为这里):

代码语言:javascript
复制
    {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。我们在当前部署中没有侦察,但将在下一个部署中添加它。而且,无法想象这有什么关系,但是梁在一个高山容器内运行。

EN

回答 1

Stack Overflow用户

回答已采纳

发布于 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,因为这一切都取决于什么类型,大小等。分块,以及它们的寿命。

票数 0
EN
页面原文内容由Stack Overflow提供。腾讯云小微IT领域专用引擎提供翻译支持
原文链接:

https://stackoverflow.com/questions/49847782

复制
相关文章

相似问题

领券
问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档