如果您看到上面的错误，这意味着您的 NodeJS 应用程序内存不足，它消耗的内存超过了分配的内存，最终导致它自行终止。
当应用程序批处理大量数据时，数据处理算法的编写方式使其需要保留堆空间中的对象，直到处理完成。随着处理的进行，应用程序逐渐使用了更多内存，V8也将 将花费更多时间进行垃圾收集以释放未使用的内存，直到最终达到分配给进程的限制并导致了OOM。
Node.js 运行时在内存使的用方面非常高效，因此程序通常使用默认限制运行良好。并且，如果没有主动设置最大堆大小，程序则会使用默认内存限制，并且此默认值也是会根据 Node.js 版本和程序运行的系统架构而有所不同。
下面我们具体了解一下：
JavaScript与Java一样，由垃圾回收机制来进行自动的内存管理。对于性能敏感的服务器端程序，内存管理的好坏、垃圾回收状况是否优良，都会对服务构成影响。而在Node中，这一切与V8引擎息息相关。
网上大都说，Node中通过JavaScript只能使用部分内存（64位约1.4G，32位约0.7G）。V8对内存做了限制。因此这种限制下，将会导致Node无法直接操作大内存对象。但是随着版本升级，这个数据好像不是那么绝对。
关于限制官方也没直接说明（主要不确定是否能通过buffer.constants.MAX_LENGTH直接类比），所以写个小程序大概在64位系统上跑一下。
Node.js （64位实测）版本限制
官方文档buffer.constants.MAX_LENGTH
为了解决 OOM 错误，您需要做的就是显式配置内存限制使用 Node.js 命令行选项
Javascript：
Typescript的 ts-node ：
这就能快速解决 Node.js 内存不足的问题！
建议始终明确设置, --max-old-space-size 而不是依赖 Node.js 的默认值，因为在较新的 Node.js 版本中默认值可能会更改。
在具有 2 GB 内存的机器上，考虑将其设置为 1536 (1.5 GB) 以留出一些内存用于其他用途并避免内存交换。
如果您在小型机器（例如 Raspberry Pi 板）上使用 Node.js 运行简单的 Web 服务器，您可以将 设置 --max-old-space-size 为适当的小值，例如 128 MB，以避免 Node.js 占用过多宝贵的内存。
关于pm2的具体使用请查看我的文章 Node服务与pm2实战
通过我们除了前端项目编译（各种cli等等）可能出现内存不足，node服务端也可能导致此问题。前端编译我们很简单的借助增加默认内存可以解决，但是服务端部署是一个持续过程,我们很少使用node直接启动的方式启动服务。我们通常借助 pm2 工具来进行,它可以在服务因异常或其他原因被杀掉后进行自动重启。 由于Node的单线程特征，自动重启能很大程度上的提高它的健壮性。
因为我们服务端使用pm2的目的之一，是服务出问题自动重启，而万一我们设置的内存不足或者服务考虑不足有些问题，导致服务内存不足崩溃对于生产环境来说很不友好。而 pm2 针对内存不足也有一个重启命令，一旦内存不足，会自动重启服务，防止整个服务卡死。
当内存超过1024M时自动重启。 如果工程中有比较棘手的内存泄露问题，这个算是一个折中方案。
pm2其实也是支持配置文件来启动的，我们也可以借助配置文件来配置命令与参数：
偶然看到一个新近的讨论还在说 node.js 只能 1.x GB 内存，是因为 v8 引擎的 GC 在大内存下有问题什么的，觉得不太可能。于是写了个小程序：
在我的 MBP 上，这个需要 node --max-old-space-size=8574 t.js 才能跑起来。
顺便查了一下，早年确实有这个问题，不过 2011 年就已经修复了( https://bugs.chromium.org/p/v8/issues/detail?id=847 )。TJ 自己就经常开个 15G 内存跑( https://twitter.com/tjholowaychuk/status/480753206301966336 )。
一、定位node.js内存漏洞的工具：工欲善其事必先利其器，在排查时，我们还是需要一些工具来帮忙的。
devTool
这个是今年初出的 Node.js 调试工具，基于 Electron 将 Node.js 和 Chromium 的功能融合在了一起。操作起来比 node-inspector 方便，开放的 Timeline 功能还是比较实用的，虽然不是实时显示。
仅需要 devtool xxx.js，还可以通过 .devtoolrc 来进行参数定制，具体见 GitHub
heapdump + chrome devTool
这个是比较传统的定位内存泄漏的组合。heapdump 可以直接在代码中调用生成内存快照，然后将快照文件导入到 chrome devTool 进行分析，之后操作其实和前者就差不多了。不过，这个方案和前者有一点区别就是，前者实际还是在浏览器环境中，所以生成的内存快照会有一些 DOM 对象的存在，会有一定的干扰。而这个方案，是直接调用底层 V8 的方法，生成的快照只有 Node.js 环境中的对象。
memwatch
这个可以在代码里直接使用，实时检测内存动态，当发生内存泄漏的时候，会触发 ‘leak’ 事件，会传递当前的堆状态，配合 heapdump 有奇效。
二、定位问题：
用 devTool 的可以忽略下面的过程：
打开 Chrome Devtools ，进入到 Profiles 选项卡，点 Load 按钮，加载之前生成的快照。
对于内存快照，有四个视图，Summary，Comparison，Containment，Statistics，这里面常用的是前三个。
在 Summary 视图中，我们可以看到当前快照的全部信息，以及多个快照之间的信息。在列表里显示的都是对象的构造函数名字，可以先忽略被括号包裹的对象，优先观察其他的对象，最后再来看他们。后面的 shallow size 表示的是对象自身的大小，retained size 表示的是对象和它依赖对象的大小，一般是 GC 不可达的。
在 Comparison 视图中，我们可以进行多个快照之间的对比，这个用处比较大，如果我们将前两次快照进行对比，可能比较快速的定位出问题的对象。注意观察 New、Deleted、Delta，如果是内存泄漏的对象，可能是一直在 New，而没有 Deleted。
在 Containment 视图中，我们可以查看整个 GC 路径，当然一般不会用到。因为展开在 Summary 和 Comparison 列举的每一项，都可以看到从 GC roots 到这个对象的路径。通过这些路径，你可以看到这个对象的句柄被什么持有，从而定位问题产生的原因。值的注意的是，其中背景色黄色的，表示这个对象在 Javascript 中还存在引用，所以可能没有被清除。如果是红色的，表示的是这个对象在 Javascript 中不存在引用，但是依然存活在内存中，一般常见于 DOM 对象，它们存放的位置和 Javascript 中对象还是有不同的，在 Node.js 中很少遇见。
