来自运行 Node.js 的 EC2 上的 nginx 的 504 导致 ELB 出现 503答案

【问题标题】：504s from nginx on EC2 running Node.js causing 503s at ELB来自运行 Node.js 的 EC2 上的 nginx 的 504 导致 ELB 出现 503
【发布时间】：2016-02-04 09:04:54
【问题描述】：

问题

我有一个 Node.js 应用程序在 6 个带有 nginx 的 EC2 实例上运行，所有这些实例都在 ELB 后面。我从 EC2 实例上的 nginx 收到的 504 Gateway Time-out 错误增加了，这导致不健康的主机从 ELB 中停止服务，最终导致 ELB 返回 503 Service Unavailable: Back-end server is at capacity。

问题

EC2 实例中 nginx 的 504s 增加可能是由于查询速度慢或吞吐量增加，这显然是这里要解决的优先事项，但我在这里提出的主要问题是：

Nginx、ELB 等的最佳超时配置是什么，以使它们能够很好地协同工作并防止这些多米诺骨牌效应破坏 ELB？

我遇到的大多数解决方案都更多地处理 Apache 或 PHP 设置，或者我不确定我发现的 nginx 设置是否真的适用于我当前的设置（我应该关心 fastcgi 还是代理设置？） .

当前配置

这是我当前配置的细分，任何其他指导将不胜感激。

在nginx.conf，我有这个：

http {
    ...
    keepalive_timeout 95;
    ...
}

Amazon says 以“确保您为保持活动时间设置的值大于负载均衡器上的空闲超时设置”，所以我在这里介绍，因为 ELB 空闲超时设置为 90秒。不确定我是否应该在nginx.conf 中使用更多设置来不依赖默认值，或者在其他地方寻找其他非默认值。

我还在 Node.js 中使用默认值，我认为它有 120000 毫秒的请求超时。

ELB 有以下Connection Settings:

Idle Timeout: 90 seconds

ELB 具有以下运行状况检查设置：

Ping Protocol: HTTP
Timeout: 59 seconds
Interval: 60 seconds
Unhealthy Threshold: 3
Healthy Threshold: 2

再次，非常感谢这里的任何指导。

【问题讨论】：

标签： node.js nginx amazon-ec2 amazon-elb

【解决方案1】：

这个问题可能与 ELB 和 Nginx 的关系不大，而更多地与您的 Node.js 应用程序有关。

如果应用程序阻塞了事件循环，Nginx 将检测到 Node.js 应用程序已关闭，然后 ELB 将认为主机已关闭。

您可以做一些事情来提供帮助：

确保您正在使用每个实例上的所有核心。您可以使用cluster 模块，或者运行多个节点进程并使用 Nginx upstream 模块在它们之间进行 Nginx 负载平衡。
使用 Node.js 工具监控事件循环阻塞，发现事件循环被阻塞的程度和责任。将长时间运行的任务移到单独的进程中。
努力实现无状态应用，避免 Nginx 和您的应用之间的粘性会话，并且不要在 ELB 设置中启用粘性。使用粘性会话，客户端可能会“卡住”被路由到无响应的 Node.js 进程。采用有状态、非粘性的设计，客户端将更快地路由到健康的节点进程。
使用 Nginx 提供静态资产，而不是 Node.js。这将减少 Node.js 上的负载，这可能是瓶颈。同样，尽可能在 Nginx 级别启用缓存，甚至在有意义的情况下为动态响应启用简短缓存。

如果您仍然觉得 Nginx 配置存在问题，那么有趣的部分是您用于将流量从 Nginx 转发到 Node.js 的配置。

您也没有为这 6 个 EC2 实例指定您使用的实例类型。不同类型具有不同级别的 CPU 和网络吞吐量。根据您的情况，您最好使用更少的更强大的盒子，每个盒子有更多的核心。

【讨论】：