最近有一个erlang的服务因为oom被kernel kill掉了, 由于从监控来说这个服务确实是内存不断增长。所以这个服务应该在哪里有内存泄漏才对。于是我又一次开始定位这个问题。
定位到底哪个进程占用了最多的内存
由于在另一个节点有一个没有crash,但是内存仍旧很高的节点,所以这个问题处理起来很简单。erlang提供了完整的运行时系统debug环境。这里我们用etop,根据memory排序,查看具体哪个线程占用了最多的内存。
erl -sname etopnode -hidden -s etop -output text -sort memory \
-lines 20 -tracing false -node 'node_name@host_name' -setcookie your_cookie
在有erlang的机器上执行这个命令,即可连接到具体的节点,通过etop得到所有线程信息,按内存排序,显示最多内存的20条线程。etop记录里的memory使用KB做单位。
在这次问题里,我定位到的内容包括
- 最大内存占用来自一个每月跑一次的统计线程。该线程为一个gen_server,用于生成一个信用分排行榜。这个线程占用超过50%内存。大概900M左右的内存。
- 第二大内存占用者是mysql线程。该线程占用超过25%内存。大概500M内存
进一步代码分析
已经定位到了75%以上内存占用了。肯定是先分析第一内存占用的线程的具体逻辑了。
- 启动之后,就定时触发一个检查请求
- 该请求检查当前时间是否为每月月初。
- 如果是,获取一个分布式锁。
- 如果分布式锁获取成功,一次性从sql数据库加载所有用户的信用记录,生成一个排行,写回数据库。
- 处理结束
这个代码很简单,而且很确定,没有任何数据被

文章讲述了作者在排查Erlang服务因内存泄漏导致OOM的过程中,发现问题是由于垃圾回收机制导致的。通过etop定位到一个每月运行一次的统计线程和MySQL线程占据了大部分内存。经过代码分析和远程shell验证,确认为Erlang的垃圾回收策略导致内存未被及时释放。通过深入理解Erlang垃圾回收机制,提出了三种优化方案,最终选择通过调整SQL语句避免一次性加载大量数据,成功解决了内存泄漏问题。
最低0.47元/天 解锁文章
482

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



