如何快速定位ssr服务端内存泄漏问题

背景

ssr服务和纯后端服务有些不一样，服务端需要去解析模板，生成HTML。解析模板的过程中，可能存在内存泄漏问题（前端代码部分造成的）

排查的困难点

1. 不太容易从最近上线的代码中找到泄漏点
   • 因为帮其他组的伙伴看内存泄漏问题，所以代码不太熟悉，代码提交有点多，时间线也比较长，不太好一个一个的去看
2. ssr服务和纯后端服务有些不一样，ssr服务造成的泄漏点，很可能在前端代码部分
   • 这样造成，不容易像纯后端代码一样，做单元压测，看内存情况
3. 本地起dev会有个问题，会直接把node内存打满，导致根本没法测
   • Node.js的代码在运行的时候，默认情况下最大能用的内存空间大概是1.4GB左右（受到v8引擎的限制）。dev环境的代码是没压缩的，而且有很多source map代码，导致很容易打满1.4G，导致直接卡死，没法测
   • 并且dev代码会有很多噪声，导致不好排查泄漏问题（并且dev代码可能本身就有内存泄漏）
4. 公司内部的平台能生成内存快照，但那个平台很不好用，生成一次快照的速度极慢。

解决方法

还是得本地用node --inspect，借助google的开发者工具，去看内存泄漏情况，也方便后续压测（不知道怎么用的话，可翻我以前的文章）

1. 用build后的代码，直接build可能会不能用，要控制好环境变量，并且丑化压缩要关掉
   • 比如，让一些环境变量（CDN域名等）指向本地，因为打的包在本地，没上传到CDN
2. 本地模拟线上环境
   • 比如本地起node服务（类似线上环境），去跑SSR
   • （这个项目用的nuxt，可以直接nuxt start）
3. 内存监控

解决过程

1. 本地用node起服务，和 build 打包代码，就因项目而异了

2. 内存如何监控？

   • 用memory页签内的，第二个profiling type

3. 去请求你本地起的服务，并查看泄漏情况，找到泄漏对象

4. 代码内去找到对应对象

• eventBus会留在node内存里

5. 解决之后，在压测一下，看看内存回收情况

总结一下如何快速定位内存泄漏问题

1. 最好每次发版都要监控好内存的变动情况，这样可以第一时间确定好代码变动的范围，从而更容易找到内存泄漏的点
2. 打build线上包，并且丑化压缩要关掉。去掉dev包的噪音
3. 在本地用node --inspect把build包跑起来
4. 压测，看内存回收情况

码字不易，点赞鼓励！