我们的设置是标准的nginx（版本0.7.59）+ Debian lenny上的瘦上游服务器。现在我们在1个健壮的盒子上用于web / app和1分贝的盒子。最近我们开始注意到最终会开始“挂起”，即他们将不再接收来自nginx的请求。我们有15个星期在运行，10-15分钟后，第一个或第2个将被挂起。如果整天离开，那些相同的几个加上几个也将保持挂起。到目前为止我们看到的唯一修复是重启nginx。重新启动后，挂起的thins立即开始再次接收请求。因此，看起来这些可能已被从上游池中取出。
如果我正确理解文档（http://wiki.nginx.org/NginxHttpUpstreamModule#server），使用默认值（我们有），如果nginx在10秒内无法与后端服务器“通信”3次，则会设置该上游服务器到“不工作”的状态。然后等待10秒，然后再次尝试该服务器。这是有道理的，但我们无限期地看到了薄薄的悬念。我尝试将每个thins的max_fails设置为0，但这没有帮助。我无法找出导致上游服务器永久“失效”的原因。
我们最近看到了很大的增长率，因此我们不确定它是否与此相关，或者由于在较短时间内获得更多流量而更加明显。
nginx中还有其他东西（一个变化的指令或其他条件）会导致服务器完全脱离池吗？
答案 0 :(得分：5)
我们在nginx的反向代理支持方面遇到了很多问题，最终通过在Mongrel和nginx之间放置HAProxy来实现更好的架构。所以我们的架构是：
web =＆gt; nginx =＆gt; haproxy =＆gt;杂种
我们之前看到的（在HAProxy之前）是nginx会使Mongrels泛滥请求太多而且Mongrel的请求队列不稳定，很快就会遇到太多排队请求。 HAProxys队列更加稳定，它更好地平衡了后端之间的所有请求，而不是nginx。 nginx只提供循环平衡，而真正像最少连接的算法更好。我不知道Thin是否会遇到与Mongrel相同的问题。
在我们的新设置中，nginx只代理一个haproxy实例，而haproxy已经配置了所有已注册的Mongrels。 HAProxy对上游的ok / fail检测有更好的支持，并且还可以将每个app server限制为1个连接（maxconn指令），这对于Mongrel来说是关键，不确定Thin。
maxconn指令是如此关键，以至于EngineYard有一个nginx补丁，使其成为nginx的原生，所以你不需要部署HAProxy只是为了利用它。