nginx代理服务器的keepalive引发的思考

使用一个nginx做全局的代理负载均衡集群时遇到了一点问题。主要是前面的nginx集群机器很多(M个),每个nginx机器的进程也很多(N个),然后设置的keepalive数量和upstream里的机器数量相同。

这个时候如果后端机器的连接数限制比较小就杯具了,平时每个后端机器的长链接数差不多是M*N +XX ,因此链接的利用率(XX)/(M*N+XX) 。当前面的机器和单机进程数很多的时候链接的利用率就会非常低。造成健康检测时后端的机器检查失败,直接被踢掉了,引发雪崩效应。

这个时候如果后端的应用不改,那么唯一的2种方案:

1、改成短链接。可能整体的响应时间有所增加。
2、适当降低keepalive的值,但是降低的太多会使得和短链接差不多的效果。很难定量的衡量这个值的最佳性,只能不断测试。

其实在apache的mod_jk模块里也是统一存在这样的问题
[text]

Timeout 180
KeepAlive On
MaxKeepAliveRequests 1000
KeepAliveTimeout 360

<IfModule worker.c>
StartServers 10
ServerLimit 50
MaxClients 1500
MinSpareThreads 50
MaxSpareThreads 200
ThreadsPerChild 50
MaxRequestsPerChild 10000
</IfModule>

worker.local.type=ajp13
worker.local.host=localhost
worker.local.port=7001
worker.local.lbfactor=50 # 多个woker的时候这个的权重
worker.local.cachesize=100 #每个进程的连接池大小,最好和apache里每个进程的最大线程数一致
worker.local.cache_timeout=600
worker.local.socket_keepalive=1 #是否开keepalive
worker.local.recycle_timeout=300 #空闲连接的回收时间

参考 http://tomcat.apache.org/connectors-doc/reference/workers.html
[/text]

如果前面的很容易造成的情况是apache的jk把后端tomcat的链接数(400)撑爆了,但是实际上很多链接又闲着。主要是每个进程的信息是独立的,
每个进程最多能有100个连接,整体的量就很难控制,尤其是上面这个空闲连接的回收时间设置的不合理。实际测试就是把这个回收的时间缩短,改成1,然后把cachesize降低到50 效果就好了很多。

此条目发表在Web server分类目录。将固定链接加入收藏夹。

发表评论