我们的设置是Debian lenny上的标准nginx(版本0.7.59)+瘦上游服务器.现在我们在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中还有其他东西(一个变化的指令或其他条件)会导致它将服务器完全从池中取出吗？
我们在nginx的反向代理支持方面遇到了很多问题,最终通过将HAProxy放在Mongrel和nginx之间来实现更好的架构.所以我们的架构是:
web => nginx => haproxy => Mongrels
我们之前看到的(在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只是为了利用它.
请参阅:nginx-ey-balancer
京公网安备 11010802040832号 | 京ICP备19059560号-6 