nodejs内存溢出 FATAL ERROR: CALL_AND_RETRY_0 Allocation failed – process out of memory
内容导读
互联网集市收集整理的这篇技术教程文章主要介绍了nodejs内存溢出 FATAL ERROR: CALL_AND_RETRY_0 Allocation failed – process out of memory,小编现在分享给大家,供广大互联网技能从业者学习和参考。文章包含1979字,纯文字阅读大概需要3分钟。
内容图文
spa项目整体迁移转为ssr后,改动之后部署一切还好,就是突然有一天访问人数太多,node进程很容易就挂了自动重启。
最后经过压力测试,考虑到是堆内存溢出的问题,就报错误:FATAL ERROR: CALL_AND_RETRY_0 Allocation failed – process out of memory
1、复现结果:
采用Jmeter做压力测试,1s50次,持续请求,观察node进程占用内存情况
经过观察发现持续请求,node进程占用内存一直升高,最后达到1.4G左右,就不会再升,因为64位系统默认分配给node进程的上线就是1.4G,32位系统好像是0.7G。
达到1.4G之后,持续1/2分钟左右,进程就挂,报错堆内存溢出:FATAL ERROR: CALL_AND_RETRY_0 Allocation failed – process out of memory
2、解决过程
起初一直不知道原因,由于之前一直有上篇报错:connect ECONNREFUSED 127.0.0.1:80错误解决,的问题,所以刚开始以为是这个拒绝导致大量连接堆积导致,所以先解决了上述问题。
但是解决了上述问题之后,依然没有用,还是会报错。考虑到是页面的问题,所以换了一个纯静态页面请求,看是否因为页面代码的问题导致内存溢出,结果请求纯静态页面也是一样情况,这就不知道什么原因了。
注意:其实这时候应该考虑到往上一层,去层层筛选,应该考虑进页面之前会有那些处理,比如nuxt里plugins,进页面之前就需要实例化这些东西。应该去考虑这些处理里面会不会导致内存泄漏。
而我当时就是没有考虑到这一层,所以陷入了处理问题的盲区,只能考虑到使用工具去查询内存快照,然后再找那些地方出现内存泄漏点。
后来考虑到上一层,所以就往plugins里去找,发现的确有内存泄漏的点,同样是因为整体迁移ssr,不是从0到1搭建重构,所以代码结构没有过多注意。我发现全局拦截器是引入的三方axios,那么每次拦截都会引入一次,导致大量的引用占用资源。问题找到,改掉之后,改为引用同一个三方资源,就没有问题了。然后把所有plugins里重复引用的资源都改为同一份引用,这样也可以减少一部分占用。
改好之后,build,然后用Jmeter做压测,监控了100多万次样本检测,异常率很低0.1%,并且node进程不会上升了,占用内存稳定在200-250M之间,问题得到解决。
记录一下主要是为了复盘一下解决问题的思路,因为解决问题的思路比解决问题的方法更重要:应该是从底层往上层,层层筛选,底层没问题,应该考虑紧邻它的上一层会不会有问题,这样就能快速定位,而我就是因为没有继续往上考虑一层,所以导致走了不少弯路。
内容总结
以上是互联网集市为您收集整理的nodejs内存溢出 FATAL ERROR: CALL_AND_RETRY_0 Allocation failed – process out of memory全部内容,希望文章能够帮你解决nodejs内存溢出 FATAL ERROR: CALL_AND_RETRY_0 Allocation failed – process out of memory所遇到的程序开发问题。 如果觉得互联网集市技术教程内容还不错,欢迎将互联网集市网站推荐给程序员好友。
内容备注
版权声明:本文内容由互联网用户自发贡献,该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容, 请发送邮件至 gblab@vip.qq.com 举报,一经查实,本站将立刻删除。
内容手机端
扫描二维码推送至手机访问。