嗯......我回到原点.我无法想象我的生活.
我收到以下错误:
FATAL ERROR: JS Allocation failed - process out of memory
我可以列举几十个(是的,几十个)我试图找到这个问题根源的东西,但实际上它太过分了.以下是关键点:
我的假设是(因为第二点),泄漏可能不是原因; 相反,似乎可能有一个非常大的SINGLE对象.以下线程支持这个理论:: 在Node.js中使用JSON.stringify导致'进程内存不足'错误
我真正需要的是一些方法来找出应用程序崩溃时内存的状态,或者可能是导致FATAL ERROR的堆栈跟踪.
基于我上面的假设,一个10分钟的堆转储是不够的(因为该对象不会驻留在内存中).
Jes*_*sse 49
仅仅因为这是目前谷歌的最佳答案,我想我会为刚遇到的案例添加一个解决方案:
我有这个问题使用express与ejs模板 - 问题是我没有关闭一个ejs块,文件是js代码 - 像这样:
var url = '<%=getUrl("/some/url")'
/* lots more javascript that ejs tries to parse in memory apparently */
这显然是一个超级特定的情况,OP的解决方案应该在大多数时候使用.但是,OP的解决方案对此不起作用(ejs堆栈跟踪不会浮出水面ofe).
Zan*_*aes 21
我必须为Trevor Norris提供巨大的道具,以帮助修改node.js本身,以便在发生此错误时自动生成堆转储.
最终,为我解决这个问题的是更平凡的事情.我写了一些简单的代码,将每个传入的API请求的端点附加到日志文件中.我等待收集~10个数据点(崩溃)并比较在崩溃前60秒运行的端点.我发现在9/10的情况下,一个端点在崩溃之前就被击中了.
从那里开始,只需要深入研究代码.我把所有东西都减少了 - 从我的mongoDB查询中返回更少的数据,只将必要的数据从一个对象传递回回调等等.现在我们已经比平均时间长了6倍而没有任何服务器上的单一崩溃,导致我希望它现在已经解决了.
Xav*_*iju 11
这个问题没有单一的解决方案.
我阅读了不同的案例,其中大多数都与JS有关,但在我的情况下,例如,由于代码错误,它只是一个破碎的玉模板循环.
我想这只是节点管理不好的语法错误.
检查您的代码或发布它以找到问题.
小智 7
在我的情况下,我通过cap生产部署(capistrano)和收到的资产预编译期间部署Rails 4.2.1:
rake stdout:rake aborted!ExecJS :: RuntimeError:致命错误:疏散分配失败 - 进程内存不足(execjs):1
我之前通过active_admin运行了十几个数据导入,它似乎耗尽了所有的RAM
解决方案: 服务器重启和部署第一次运行....
| 归档时间： |
|
| 查看次数： |
66121 次 |
| 最近记录： |