标签：node RETRY nodejs process 占用 问题 内存 考虑 页面

　　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之间，问题得到解决。

　　记录一下主要是为了复盘一下解决问题的思路，因为解决问题的思路比解决问题的方法更重要：应该是从底层往上层，层层筛选，底层没问题，应该考虑紧邻它的上一层会不会有问题，这样就能快速定位，而我就是因为没有继续往上考虑一层，所以导致走了不少弯路。

标签：node,RETRY,nodejs,process,占用,问题,内存,考虑,页面
来源： https://www.cnblogs.com/goloving/p/11441054.html

本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享；
2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关；
3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关；
4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除；
5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。