记一次nodejs 服务密集访问造成内存泄漏处理经历
发布于 2 个月前 作者 cnlile 1356 次浏览 来自 分享

压力测试,模式真实场景,需要调用外部API 2次,数据库写操作2次,读3次位单位的一次请求,测试工具Jmeter,300线程,200组,每次共计6万次请求,服务器为8核8G nodejs api 服务。 1、在8核cpu跑到80~100%,时候,发生延迟,日志显示接受消息比发送端延迟3秒。经过分析,Linux OS是一个文件服务系统,表示CPU处理任务压力导致处理网络请求变慢,而不是网络延迟。发现,日志写存在问题,Jmeter 接受到全部返回后,服务器Log4js 日志还在不停写,内存上看有内存没有释放的问题。 2、memwatch, 和 heapdump 加载后,发现只有在CPU压力达到一定比率时候,才会跳出来memwatch leak,而且近似随即。 heapdump文件,随着时间增加,文件容量不断扩大,文件里面system /JSArrayBufferData 增加最快,里面有大量sequelize 名字,则怀疑数据库问题,则做了数据库测试,对30万条数据库记录进行读写。。发现偶尔只有1-2次的memwatch leak 事件发生,觉得数据库方面问题不大,估计还是其他因素。 3、降低服务器压力,50%左右强度测试压力,memwatch leak 事件没有发生,但是内存还是没有完全释放。表示还是存在程序方面或者软件系统问题,考虑到日志问题,则取消日志输出,恢复正常压力测试,问题消失,判断为日志问题。 4、有群友表示log4js 写不好,很容易出现内存泄漏,则重新写了log4js 相关程序代码,并且在pm2 上引入了pm2-intercom , 利用IPC机制,将日志都集中到主进程读写,降低日志写竞争的问题。重新测试后,一切正常,CPU 跑到了40%上下,每个进程内存消耗120M上下。。一切都是日志问题,程序写的日志处理部分有bug,这个bug只有在高密度访问cpu 时候,才会造成内存泄漏无法释放。 5、吐槽以下node V 8.2.1 版本实在太烂了,不如node V8.1.3, 同样硬件配置机器 V8.2.1 CPU会比 V8.1.3 高20%,造成在pm2 里面看到loop delay 一个是0.34 , 一个是0.62 。。。。估计是 GCC 4.9.4 版本东西没做好。 觉得V 8.2.1 机器更容易测出问题来。。。。。。 nodejs 的内存问题,如果不上压力测试,估计还有时候还真看不出来啊。。。。代码一定要严谨 啊,严谨,不能太随意,能运行并不一定正确,编码完成后,真的只完成了10%的开发。。。。

5 回复

已经出8.3了, 试试8.3有没有问题😂

密集访问可能不是内存泄露,可能是事件队列的增长速度快于执行速度,导致队列堆积

来自酷炫的 CNodeMD

log4js我在它github提过一个issue,它会有背压

这个时候需要 alinode 啊。

你肯定是用了cluster吧,log4js是有针对cluster的处理。 本质就是把写日志文件的事情放到cluster master上去做。

回到顶部