Node.js的RSS(Resident Set Size)与每个请求一起增长是否正常,直到达到某个上限?

我注意到,我的node.js应用程序的RSS(驻留集大小)随着时间的推移而增长,考虑到我的服务器上有一个“JS对象分配失败 – 内存不足”的错误,这似乎是一个可能的原因。

我设置了以下非常简单的Node应用程序:

var express = require('express'); var app = express(); app.get('/',function(req,res,next){ res.end(JSON.stringify(process.memoryUsage())); }); app.listen(8888); 

通过简单地按住“刷新”热键@ http:// localhost:8888 /我可以观看RSS /堆/等。 直到RSS达到50MB以上(在我感到无聊之前)。 等待几分钟,然后回来,RSS下降 – 大概GC已经运行。

我试图弄清楚这是否解释了为什么我的实际节点应用程序崩溃了…我的产品应用程序迅速达到100Mb的RSS大小,当它崩溃时,一般在200Mb-300Mb之间。 尽我所知,这应该不会太大(节点应该能够处理1.7Gb左右,我相信),但是我担心我的生产服务器上的RSS大小向上趋势(衰退代表崩溃):

在这里输入图像描述

这个问题已经很老了,但没有答案,所以我会扔在我的,从2013年至2014年的Jay Conrod谁已经“优化V8 JavaScript引擎的手机的工作”的博客文章 。

V8试图在收集垃圾的时候保持高效,并且使用增量标记和懒惰扫描

基本上,增量标记负责跟踪您的物体是否可以收集。

增量标记从堆到达某个阈值大小时开始。

懒惰的清扫负责收集标记为垃圾的物体在增量标记和执行其他耗时的任务。

一旦增量标记完成,懒惰扫描开始。 所有对象都被标记为活的或死的,堆确切地知道可以通过扫描释放多less内存。 所有这些记忆都不一定要被马上释放,推迟清扫并不会真正伤害任何东西。 因此,垃圾收集器不是同时扫描所有页面,而是根据需要扫描页面,直到所有页面都被扫描。 此时,垃圾收集周期已经完成,并且增量标记可以再次开始。

我想这解释了为什么你的服务器分配这么多的内存,直到达到一定的上限。 为了更好地理解,我推荐阅读Jay Conrod的博客文章“V8游览:垃圾收集” 。