node服务器响应超时,Node.js应用有周期性的缓慢和/或超时（不接受传入的请求）...

这个问题正在破坏我的生产服务器的稳定性。

概括地说，基本思想是我的节点服务器有时会间歇性地减慢速度，有时会导致网关超时。 尽我所能从日志中得知，有什么东西阻塞了节点线程(这意味着传入的请求不被接受)，但是我一生都无法找出原因。

该问题的严重程度不同。 有时，小于100ms的请求应该花费大约10秒才能完成； 有时它们甚至根本不会被节点服务器接受。 简而言之，似乎某个随机任务正在工作并阻塞节点线程一段时间，从而减慢(甚至阻止)传入的请求； 我可以肯定地说的一件事是，需要修复的症状是“网关超时”。

问题来来往往，没有警告。 我无法将其与CPU使用率，RAM使用率，正常运行时间或任何其他相关统计信息相关联。 我已经看到服务器可以处理较大的负载，然后在较小的负载下出现此错误，因此它似乎与负载无关。 在太平洋标准时间凌晨1点左右看到错误，这是一天中最小的加载时间，这并不罕见！ 重新启动节点应用程序似乎可以使问题暂时消失，但这并不能告诉我很多。 我确实想知道这是否可能是node.js中的错误...考虑到它正在杀死我的生产服务器，因此不是很令人欣慰。

我要做的第一件事是确保已将node.js以及我的所有模块(都放在此处)升级到最新版本(0.8.12)。 当然，我也有很多错误捕获器。 我没有做任何时髦的事情，例如将大量内容打印到控制台或写入大量文件。

最初，我认为这是阻止传入套接字的出站HTTP请求，因为快速中间件甚至没有处理入站请求，但是我放弃了理论，因为它看起来像节点线程本身变得很忙。

接下来，我使用JSHint遍历了所有代码，并逐字修正了每个警告，包括一些意外的全局变量(忘记写“ var”)，但这无济于事

在那之后，我以为我可能内存不足。 但是，我现在通过nodetime看到的堆快照看起来不错(如下所述)。

仍然认为内存可能是一个问题，我看了看垃圾回收。 我启用了--nouse-idle-notification标志，并在不需要空对象时对NULL对象进行了更多代码优化。

仍然确信内存是问题所在，我添加了--expose-gc标志并执行了gc();。 每分钟命令。 这没有改变任何东西，只是偶尔使请求变慢了一点。

在一次绝望的尝试中，我将“集群”模块设置为使用2个工作程序，并每30分钟自动重新启动一次。 仍然没有运气。

我将ulimit增加到10,000以上，并关注打开的文件。 每个node.js应用程序似乎有<300个打开的文件(或套接字)，因此增加ulimit不会产生影响。

我一直在用节点时间记录我的服务器，这是要点：

在Amazon Cloud(m1.large实例)上运行的CentOS 5.2

始终大于5000 MB的可用内存

始终小于150 MB的堆大小

CPU占用率始终低于60％

我还检查了我的MongoDB服务器，这些服务器的CPU使用率低于5％，没有任何请求要花费100毫秒以上的时间才能完成，因此我高度怀疑是否存在瓶颈。

我已经(几乎)使用Q-promises(请参见代码示例)包装了所有代码，并且当然避免了像瘟疫一样的Sync()调用。 我曾尝试在测试服务器(OSX)上复制该问题，但运气不佳。 当然，这可能仅仅是因为生产服务器正以许多无法预测的方式被许多人使用，以至于我无法通过压力测试进行复制...