好吧..。我又回到起点了。我这一生都搞不懂这件事。
我得到以下错误:
FATAL ERROR: JS Allocation failed - process out of memory
我可以列举出我试图解决这个问题的几十件事(是的,几十件事),但实际上这太多了。所以这里有一些关键点:
我的假设是(因为第二点),泄漏可能不是原因;相反,看起来可能有一个非常大的对象。下面的线程支持这个理论::In Node.js using JSON.stringify results in 'process out of memory' error
我真正需要的是找出应用程序崩溃时内存的状态,或者可能导致致命错误的堆栈跟踪。
根据我上面的假设,10分钟前的堆转储是不够的(因为对象不会驻留在内存中)。
发布于 2012-12-04 02:26:47
我必须给Trevor Norris on this one for helping to modify node.js itself很大的支持,这样当这个错误发生时,它会自动生成一个堆转储。
然而,最终为我解决这个问题的是更平凡的东西。我编写了一些简单的代码,将每个传入API请求的端点附加到日志文件中。我等待收集了大约10个数据点(崩溃),并比较了在崩溃前60秒运行的端点。我发现在9/10的情况下,单个端点在崩溃之前就被击中了。
从那时起,只需更深入地挖掘代码即可。我削减了一切--从我的mongoDB查询返回更少的数据,只将必要的数据从对象传递回回调函数,等等。现在,我们在任何服务器上的运行时间都比平均时间长了6倍,没有一次崩溃,这让我希望这个问题得到了解决……就目前而言。
发布于 2013-01-30 13:39:56
就因为这是目前谷歌上最热门的答案,我想我应该为我刚刚遇到的一个案例添加一个解决方案:
我在使用带有ejs模板的express时遇到了这个问题-问题是我无法关闭一个ejs块,文件是js代码-类似于:
var url = '<%=getUrl("/some/url")'
/* lots more javascript that ejs tries to parse in memory apparently */
这显然是一个非常特殊的情况,OP的解决方案应该在大部分时间内使用。但是,OP的解决方案不适用于此(ofe
不会显示ejs堆栈跟踪)。
发布于 2014-06-05 16:15:34
这个问题没有单一的解决方案。
我阅读了不同的案例,其中大多数与JS有关,但在我的案例中,例如,由于代码错误,只是一个损坏的jade模板循环。
我猜这只是一个语法错误,节点不能很好地处理。
检查您的代码或发布它以找到问题所在。
https://stackoverflow.com/questions/13616770
复制相似问题