Node.js应用程序有周期性的缓慢和/或超时（不接受传入的请求）
这个问题正在破坏我的生产服务器的稳定性。
回顾一下，基本思想是我的节点服务器有时会间歇性地减速，有时会导致网关超时。 就像我从日志中可以看出的那样，有些东西阻塞了节点线程（意味着传入的请求不被接受），但是我不知道是什么原因。
问题的严重程度不一 。 有时应该是<100ms请求需要10秒钟完成; 有时他们甚至从来没有被节点服务器接受。 简而言之，就好像一些随机任务正在工作并阻塞节点线程一段时间，从而减缓（甚至阻塞）传入的请求; 我可以肯定的一件事是，需要修复的症状是“网关超时” 。
这个问题来不加警告 。 我无法将其与CPU使用率，RAM使用率，正常运行时间或任何其他相关的统计数据相关联。 我已经看到服务器处理大负载罚款，然后有一个小负载这个错误，所以它甚至不会是负载相关的。 在太平洋标准时间上午1点左右发现错误并不罕见，这是一天中最小的加载时间！ 重新启动节点应用程序似乎可能会让问题消失一段时间 ，但是这并不能说明问题。 我不知道是否它可能是node.js中的错误 …不是很让人安慰，考虑到它正在杀死我的生产服务器。
- 我做的第一件事是确保我已经升级node.js到最新的（0.8.12），以及我所有的模块（ 在这里 ）。 当然，我也有很多错误捕捉器。 我没有做任何事情，比如打印出大量的控制台或写入大量的文件。
- 起初， 我认为这是出站HTTP请求阻塞传入的套接字，因为expression中间件甚至没有收到入站请求，但我放弃了理论，因为它看起来像节点线程本身变得繁忙 。
- 接下来，我使用JSHint检查了所有的代码，并逐字修改了每一个警告，包括一些意外的全局variables（忘记写“var”），但是这并没有帮助
- 之后，我认为也许我的记忆力已经耗尽。 但是，我通过nodetime的堆快照现在看起来相当不错（如下所述）。
- 仍然认为内存可能是一个问题，我看了一下垃圾收集 。 我启用了–nouse-idle-notification标志，并在不需要的时候对NULL对象做了一些代码优化。
- 仍然相信内存是问题，我添加了–expose-gc标志并执行了gc（）; 每分钟命令。 这并没有改变任何东西，除了偶尔提出要求稍微慢一些。
- 在绝望的尝试，我设置“群集”模块使用2名工人，并自动重新启动，每30分钟。 但是，没有运气。
- 我把ulimit增加到了10,000以上，并且关注了打开的文件。 每个node.js应用似乎有<300个打开文件（或套接字），因此增加ulimit没有影响。
我一直使用nodetime来logging我的服务器，下面是它的主题：
- 在Amazon云上运行的CentOS 5.2（m1.large实例）
- 任何时候都大于5000 MB的可用内存
- 在任何时候小于150 MB的堆大小
- CPU使用率始终低于60％
我也检查了我的MongoDB服务器，这些服务器的CPU使用率小于5％，没有任何请求花费大于100ms来完成，所以我非常怀疑这是一个瓶颈。
我用Q-promises（ 见代码示例 ）包装（几乎）所有的代码，当然也避免了像鼠疫这样的Sync（）调用。 我试图在我的testing服务器（OSX）上复制这个问题，但运气不大。 当然，这可能只是因为生产服务器被许多人以无法预料的方式被使用，我根本无法通过压力testing来复制…
我的猜测是mongoose。 如果您在Mongo中存储大量的有效载荷，Mongoose可能会很慢，因为它如何构buildMongoose对象。 有关该问题的更多详细信息，请参阅https://github.com/LearnBoost/mongoose/issues/950 。 如果这是问题，你不会看到它在Mongo本身，因为查询返回很快，但对象实例化可能需要75倍的查询时间。
尝试在创buildMongoose对象之前和之后设置定时器（ process.hrtime() ），看看是否可能是问题所在。 如果这是问题，我将直接使用节点Mongo驱动程序而不是通过Mongoose。
我第一次问这个问题几个月后，我find了答案。
简而言之，问题在于当我从一台服务器转移到另一台服务器时，我没有提供很大的资产。 换句话说，我是从一台服务器下载一个镜像，然后上传到S3存储桶。 我没有将下载stream式传输到上传文件中，而是将文件下载到内存中，然后上传。
我不知道为什么这不会显示为记忆秒杀，或在我的统计其他地方。
你正在大量泄漏内存，只要你不需要它，就尽量将每个对象设置为null！ 阅读这个 。
有关寻找内存泄漏的更多信息可以在这里find。
要特别注意对同一个对象有多个引用，并检查是否有循环引用，这是一个很难debugging，但会帮助你非常。
尝试每分钟手动调用垃圾收集器（我不知道你是否可以在node.js中这样做，因为我更像是一个c ++和php编码器）。 从我多年使用c ++的经验中，我可以告诉你，随着时间的推移，应用程序的最可能的原因是内存泄漏，find它们并将它们插入，你会没事的！
另外假设你没有caching和/或处理图像，内存中的audio或video或类似的150M堆是很多！ 那些可能是数十万甚至数百万的小物件。
您不必为内存不足而导致应用程序的运行速度变慢……仅仅使用已分配的许多对象来search可用内存对于内存分配器来说是一项巨大的工作，需要花费大量的时间来分配每个新的内存对象，当你泄漏越来越多的内存时间只增加。
是“ – nouse-idle-connection”错误吗？ 你真的是指“–nouse_idle_notification”。
我认为这可能是一些关于gc的问题，太多的小东西。 节点是单进程的，所以看最繁忙的cpu核心比负载重要得多。 当你的程序很慢的时候，你可以执行“gdb node pid”和“bt”来查看哪个节点正在忙着做什么。
我要做的是在同一台服务器上设置一个并行节点实例，并使用某种回声服务来testing该实例。 如果运行良好，则将问题缩小到程序代码（而不是调度程序/操作系统级别的问题）。 然后，一步一步地，包含模块并再次testing。 当然这是很多的工作，需要很长时间，我不知道你的系统是否可行。
如果你现在需要这个工作，你可以去NASA冗余路线：
调出生产服务器的第二个副本，并在它们前面放置一个代理，将每个请求路由到这两个堆栈并返回第一个响应。 我不build议这是一个完美的长期解决scheme，但它应该有助于显着减less生产中的问题，并帮助您收集日志数据，以便在非生产服务器上重新创build问题。
显然，对于读取请求来说，这是直接的，但是对于写入数据库的命令更复杂。
我们的Node.js服务器也有类似的问题。 它几周没有好的规模，我们已经尝试了几乎所有的东西。 我们的问题是在高并发环境下隐含的积压值被设置得非常低 。
http://nodejs.org/api/http.html#http_server_listen_port_hostname_backlog_callback
将积压工具设置为一个更高的值（例如10000）以及调整内核中的networking（Linux上的/etc/sysctl.conf），这在手册部分中有所帮助。 从现在开始，我们在Node.js服务器中没有任何超时。
