我注意到我们的节点应用程序在一天左右的时间内耗尽了内存。 内存被每分钟运行的工作所消耗，因为这是目前唯一正在进行的工作。 当我在我的机器上本地运行应用程序时，我可以看到应用程序触及内存天花板，然后垃圾收集跳入。
在heroku上，似乎超出了我们的1G内存实例的内存限制，而GC没有踢入。我不知道是否因为节点configuration了更高的内存限制，然后实际的Dyno。
换言之：node.js的内存限制在绑定到Dyno内存限制的herkou上吗？
这是来自heroku的回应。 看起来你需要进行configuration更改，不能使用开箱即用的configuration。
你好，
感谢链接到这些文档; 我将需要更新terminal示例，因为我最近已经使聊天的WEB_CONCURRENCY输出变得无声无息。 当我们添加了这个function的时候，我们添加了日志function，所以人们不会惊讶于这些新的variables侵入他们的环境。
要查看您的应用程序的值，您可以运行：
$ heroku运行'echo $ WEB_MEMORY，$ WEB_CONCURRENCY'但是，让我清楚 – 这些值仅用于确定群集节点应用程序应该运行多less个并发进程，即使如此，也只有当您select使用WEB_CONCURRENCY值你的代码。 它们完全不影响节点二进制文件或其默认的内存分配或垃圾回收，它们是完全标准的，从nodejs.org/dist下载的vanilla版本：
https://devcenter.heroku.com/articles/node-concurrency#tuning-the-concurrency-level V8使用贪婪和懒惰的方式来进行垃圾回收。 此外，V8默认假定您有大约1.5 GB的工作量（超过2X测功机的1 GB限制）。 如果您对更改节点的默认内存行为感兴趣，可以select一些选项：
内存超过设定限制时手动触发GC（ https://simonmcmanus.wordpress.com/2013/01/03/forcing-garbage-collection-with-node-js-and-v8/ ）
将max_old_space_size设置为低于默认值（例如，节点–max_old_space_size = 960）。 v8源代码中的几个指标与max_old_space_size绑定，所以这可以使gc更具侵略性。 缺点是如果你甚至超过一个字节的值，你的程序将崩溃。
将gc_global设置为true以强制always-global收集（默认情况下为false – 请记住全局收集比默认的多阶段收集慢）。
将nolazy_sweeping设置为true，这也使gc更具侵略性。
请记住，如果在单个节点进程中超过大约1 GB的内存，最佳做法是将该进程拆分为多个工作者：
https://github.com/joyent/node/wiki/FAQ#what-is-the-memory-limit-on-a-node-process干杯，猎人