1、问题发现
在一次压测中,发现erlang VM使用内存超出预期,其中process使用内存在正常范围内,system使用内存超出预期很多,具体占到整个内存使用量的80%,其中binary一项占用了system的绝大部分使用量,很明显,系统存在binary泄漏。
2、问题追踪
问题发生后,首先想到的就是到底binary在erlang VM中是怎么创建和回收的。众所周知,binary分为两种,小于64bytes存在进程私有堆中,大于64bytes的存在共享堆中,进程私有堆gc策略为分代gc,共享堆gc策略是引用计数Refc,也就是说当一个binary没有任何一个进程引用的时候才会被gc,具体机制不再赘述,相关问题可以参考https://www.cnblogs.com/yunba/p/4816384.html?utm_source=tuicool&utm_medium=referral
什么进程在引用了binary?erlang:process_info/2有个未公开的选项可以查看一个进程引用的所有binary,利用这个我们可以查看到大量引用binary的进程,具体可以参考http://blog.yufeng.info/archives/2882
topN(N)->
[{M, P, process_info(P, [registered_name, initial_call,current_function, dictionary]), B} ||
{P, M, B} <- lists:sublist(lists:reverse(lists:keysort(2,processes_sorted_by_binary())),N)].

本文详细复盘了一次Erlang虚拟机(VM)内存泄漏问题,重点在于binary的管理和回收。在压测中发现system内存使用异常,尤其是binary部分。通过追踪,了解到binary在VM中的生命周期及GC机制。代码分析揭示,TCP连接进程因处理网络IO导致大量binary引用,引发泄漏。解决方案包括调整网络IO模式和遵循《Stuff Goes Bad: Erlang In Anger》中的建议,如定时手工GC、避免大量binary使用等。最终通过改变网络读写模式解决了问题,强调了监控和有效管理binary的重要性。
最低0.47元/天 解锁文章
189

被折叠的 条评论
为什么被折叠?



