erlang 服务器崩溃bug

问题描述:
服务器测试时,在正常运行2-3天之后直接挂掉了.
解决过程:
工作一年多了,之前遇到的都是一些报错和数据错误的bug,然后erlang就自动将那个进程重启了.erlang本身容错就做的很好,像这种服务器直接挂掉了的情况还没遇到过.吓得我赶紧百度一波导致erlang 挂掉的原因.
网上学习一波之后还是有点感觉,至少不像一开始一样一点思路都没有(http://blog.sina.com.cn/s/blog_96b8a1540100zn1q.html)
然后在日志里看到:
eheap_alloc: Cannot allocate 529782288 bytes of memory (of type “heap”).
serial read: Broken pipe
那么假如是内存耗尽了该怎么处理呢?
这里有篇博客:http://erlangdisplay.iteye.com/blog/1214167
因为测试的地方只有局域网,我这边也没办法去现场,就在util模块里添加几个方法,方便现场的直接进行运行:
spawn(fun() -> etop:start([{output, text}, {interval, 10}, {lines, 20}, {sort, memory}]) end).
这段代码会在终端每10秒一次,以memory大小排序显示.在现场运行的时候,发现里面有个MsgQ一直在增加,数字大的吓人,因为这个进程的信箱嘛,那么应该就是这个原因了:mailbox耗尽了系统的内存.
问题找到了,那么是什么导致的这个问题呢,这边就用到了eprof这个分析工具:http://blog.csdn.net/huang1196/article/details/38660325
通过eprof分析了那个进程后,发现一个方法使用频率很高,而且花费的时间非常多,去相应的模块找到这个方法,我滴个乖乖.
这个方法是把整个二进制数据,按照每八位切分。然后它每取一个数直接++到了末尾,如果数据很小的话这对性能的影响不大,但是数据稍微大点的话,效率就非常的低.恰好有个数据每分钟传了20k左右的大数据过来,于是….
最后就稍微改了以下,++到了左边,最后在调用list:reverse().
ok,把修改后的beam发过去测试,发现MsgQ没增长了,搞定.完结
jj思密达,跑了2天之后出现了一大堆报错日志,然后每半天还会出现一次没有数据的情况,怎么回事,一脸懵逼.难道我的修改出问题了?? 观察报错日志,发现全是timeout,像一个简单的call得到也是timeout错误.
不知道怎么办,但是必须得办啊,项目是用的emysql插件,因为看到有个emysql的错误connection_wait_timeont,想到会不会是和数据库打交道出了问题哦,后面证明我的思路完全偏了,不过http://blog.csdn.net/aaaajw/article/details/51774775 这个博客讲了一个emysql的错误,好像确实时这样的,比如连接太多超过5s后就会堆积起来了,大家可以看下学习一波.
最后实在不知道怎么办了,在erlang群里面问了一波,一个大大让我给出详细的消息啊,至少要说明一下出现timeout时cpu的负载是怎么样的,所有系统进程的cpu负载时怎么样的.我当时想的是什么鬼,完全没浑头,但不可能让别人详细给你讲这是个什么东西吧,所以呀,先感谢大大的帮助,然后准备先去看下这个东西.其实很简单,怪我当初没好好学习….
不过虽然还是很蒙b的状态,但是有条路可以走了嘛,这里也有一个博客可以了解 http://www.cnblogs.com/Security-Darren/p/4685629.html.
ok,先在linux终端输入top,然后可以看到cpu这些数据的具体的情况了,但是不可能一直在这望着吧,鬼知道这东西什么时候出问题哦.
所以要把top的消息存到一个文件里面,问了一下运维的朋友怎么搞,很简单.
top -d 60 -b -n 1440 > /data/top.txt
60s一次,把top出来的数据存到top.txt中,存1440次,就是24小时哈.好滴,让那边运行一下,休息休息,等会儿看情况是咋样的.
vim打开进去,然后搜索CPU,一路看下去发现,里面有个程序占用的内存一直在增加,最后到达一个限度后,又减少重来一波.(ps:那个程序是一个c写的可执行程序,然后在erlang中通过open_port调用它)
那么事情终于明了了,c写的可执行程序可能有点问题,同样导致了内存的泄露,在不断的堆积中,系统着不住了,各种问题就来了,erlang就timeout,然后启动那个程序的进程就挂掉后重启,这个时间段会关闭掉那个c程序,之后又通过open_port启动,这就导致了中间那几分钟没数据的情况出现.最后bug转移之术,不该我管了,联系c的同事解决.
这个问题其实也不是很复杂,但是进入了我不知道的领域,也算是因为自己的知识太缺乏,不过还好现在的网络很发达,有啥不懂的就去百度,gogole,还是不懂就去对应的技术群问人,如果发现他们说的超出了你的能力,就去了解相应的知识点.进步就是这么一点一点的来的.下次遇到这种问题,说不定我还可以去指点别人一波,完美.

    原文作者:hrcx
    原文地址: https://blog.csdn.net/weixin_40341185/article/details/78354281
    本文转自网络文章,转载此文章仅为分享知识,如有侵权,请联系博主进行删除。
点赞