嗯...我回到第一方。我这辈子都想不通。
我收到以下错误：
FATAL ERROR: JS Allocation failed - process out of memory
我可以列举几十个（是的，几十个）我试图找到这个问题的根源的事情，但真的太多了。所以这里是关键点：
我的假设是（由于第二点）泄漏可能不是原因；相反，似乎可能有一个非常大的 SINGLE 对象。以下线程支持这一理论：：在 Node.js 中使用 JSON.stringify 会导致“进程内存不足”错误
我真正需要的是某种方法来找出应用程序崩溃时内存的状态，或者可能是导致致命错误的堆栈跟踪。
根据我上面的假设，10 分钟前的堆转储是不够的（因为对象不会驻留在内存中）。
仅仅因为这是目前谷歌上的最佳答案，我想我会为我刚刚遇到的一个案例添加一个解决方案：
我在使用带有 ejs 模板的 express 时遇到了这个问题 - 问题是我未能关闭 ejs 块，并且文件是 js 代码 - 如下所示：
var url = '<%=getUrl("/some/url")'
/* lots more javascript that ejs tries to parse in memory apparently */
这显然是一个超级具体的案例，大部分时间都应该使用 OP 的解决方案。但是，OP 的解决方案对此不起作用（ejs 堆栈跟踪不会由 浮出水面ofe）。
我必须在这个问题上向Trevor Norris 提供巨大的支持，以帮助修改 node.js 本身，以便在发生此错误时自动生成堆转储。
不过，最终为我解决了这个问题的方法要平凡得多。我编写了一些简单的代码，将每个传入 API 请求的端点附加到日志文件中。我等待收集约 10 个数据点（崩溃）并比较崩溃前 60 秒运行的端点。我发现在 9/10 案例中，只有一个端点在崩溃前被击中。
从那里开始，只需深入挖掘代码即可。我削减了所有内容——从我的 mongoDB 查询中返回更少的数据，只将必要的数据从对象传递回回调等等。现在我们已经比平均时间长了 6 倍，没有任何服务器上发生过一次崩溃，这让我希望它得到解决......现在。
这个问题没有单一的解决方案。
我阅读了不同的案例，其中大多数与 JS 相关，但在我的案例中，例如，只是一个损坏的玉模板循环，由于代码错误而无限。
我猜这只是节点管理不善的语法错误。
检查您的代码或发布它以查找问题。
就我而言，我通过 cap production deploy (capistrano) 部署 Rails 4.2.1，并且在收到的资产预编译期间：
rake 标准输出：rake 中止！ExecJS::RuntimeError: FATAL ERROR: Evacuation Allocation failed - process out of memory (execjs):1
我之前通过 active_admin 运行了十几个数据导入，它似乎已经用完了所有 RAM
解决方案： 服务器重新启动并首次运行部署......
这可能是您正在序列化的对象的递归问题，它刚开始就很大，并且在递归成为问题之前内存不足？
出于这个原因，我创建了安全克隆深度npm 模块......基本上你会想要执行以下操作。
var clone = require('safe-clone-deep');
...
return JSON.stringify(clone(originalObject));
这将允许您克隆几乎任何将安全序列化的对象。此外，如果其中一个对象继承自Error它将序列化继承name的message和stack属性，因为这些通常不会序列化。
在我们的例子中，我们不小心分配了一个巨大的（稀疏）数组，导致 util.format 崩溃：
http://grahamrhay.wordpress.com/2014/02/24/fatal-error-js-allocation-failed-process-out-of-memory/
在我的例子中，我使用 [] 初始化了一个关联数组（对象）。一旦我将其初始化为 {}，问题就消失了。
就我而言，我在开发过程中用来播种数据库的文件导致了泄漏。由于某种原因，节点不喜欢我在文件末尾的多行注释。我看不出它有什么问题，但消除过程意味着我知道这是该文件的这一部分。
分析多个案例，最常见的问题是死循环。这在复杂的应用程序中很难解决，这就是测试驱动开发派上用场的地方！
分享这里发生的事情：
我因这个问题失去了几天，直到我发现在某个文件中我从一个静态文件导入一个类，一个构建的文件。它使构建过程永无止境。就像是：
import PropTypes from "../static/build/prop-types";
修复到真实来源解决了所有问题。
在 AWS 实例上使用 npm 5.0.3，我们在 npm 全局文件夹本身上遇到了权限问题，这可能导致我们发生这种情况。我们跑了：sudo chown -R $(whoami) $(npm config get prefix)/{lib/node_modules,bin,share}
现在它工作正常
我花了几天时间才找到问题的根本原因。仅在 AWS EC2 实例中的 webpack 构建期间开始出现“JS - 进程内存不足”错误。不过，在我的本地系统中构建是成功的。
原因是以下代码：
上一个：
import { ShoppingCartOutlined } from "@material-ui/icons/ShoppingCartOutlined";
它被修复：
import ShoppingCartOutlined from "@material-ui/icons/ShoppingCartOutlined";
它可能会帮助使用 material-ui/icons 的人并最终出现此错误。
我有同样的问题。所以我尝试了这个： node --max-old-space-size=4096 index.js 这行得通。
在使用npm i.
FATAL ERROR: Committing semi space failed. Allocation failed - process out of memory
1: node::Abort() [npm]
2: 0x556f73a6e011 [npm]
3: v8::Utils::ReportOOMFailure(char const*, bool) [npm]
4: v8::internal::V8::FatalProcessOutOfMemory(char const*, bool) [npm]
5: v8::internal::Heap::PerformGarbageCollection(v8::internal::GarbageCollector, v8::GCCallbackFlags) [npm]
6: v8::internal::Heap::CollectGarbage(v8::internal::AllocationSpace, v8::internal::GarbageCollectionReason, v8::GCCallbackFlags) [npm]
7: v8::internal::Heap::CollectAllGarbage(int, v8::internal::GarbageCollectionReason, v8::GCCallbackFlags) [npm]
8: v8::internal::StackGuard::HandleInterrupts() [npm]
9: v8::internal::Runtime_StackGuard(int, v8::internal::Object**, v8::internal::Isolate*) [npm]
10: 0x159539b040bd
Aborted
我的解决方案是添加额外的标志
node --max-old-space-size=250 `which npm` i
希望它可以为某人节省时间
可能是节点版本的问题。在运行反应应用程序时，我经常遇到同样的问题。我在使用节点版本 14.7.2 时遇到了这个问题。尝试了很多解决方案，例如增加堆内存、清除缓存、重新安装节点模块。它都没有解决问题。最后，将 Node 版本降级到 10.24.1，这停止了错误消息。