我正在为一个门户网站调整我们的生产服务器,我们有 4 台服务器,2 台用于 Web,2 台用于应用程序,并且 Web 服务器之前和之后都有防火墙(所以应用程序和 Web 服务器之间确实有防火墙),这里的问题始于防火墙断开应用程序服务器和 Web 服务器之间的空闲连接,尝试了很多解决方案,现在似乎问题已经从防火墙断开导致应用程序中的卡住断开连接转移,这个问题发生在门户网站的负载较低时,为了解决这个问题,我需要重新启动所有应用程序服务器,但现在我却遇到了高负载问题,紧急的解决方案只是快速重启 Apache Web 服务器,如何解决这个问题呢。
我在 Jboss 负载平衡配置生成器的帮助下做出了更改:http://lbconfig.appspot.com/?lb=mod_jk&mjv=1.2.28&nca=64&ncj=64&nai=2&nji=2&njips=6&f=true&c=false&lr=false&lrl=&mpm=Prefork
使用 netstat 命令和 google analytics 实时概览监控两个服务器的连接,我上次重启 3 天后获得了以下统计数据,大约有 40 位访问者:
Web 端(有 2 台服务器,但每台的连接数不是总数):
ESTABLISHED ~700 - 750
TIME_WAIT: 100-200 (big jumbs for one second 150 another 200 another 170 and then 120 and so)
应用程序端(这里我计算了所有的连接,每次检查时,大多数都是 ESTABLISHED,还有少数 CLOSE_WAIT 0 - 5):
S1 (4 instances running) : 900-950
S2 (5 instances running) : 1000-1100
服务器详细信息:
- 在 web 2x 服务器上:Apache 2.2.14 / mod_jk 1.2.37
- 在应用程序 2x 服务器上:带有 ajp13 的 Clustered Glassfish 2.1.1(每个服务器 6 个实例)
- 所有服务器均为 Solaris SPARC 64 V-CPU 32GB RAM。
我的配置: 大部分内容就像生成器给我的一样(你可以看到链接):
httpd.conf:
KeepAlive On
ServerLimit 12800
StartServers 5
MinSpareServers 5
MaxSpareServers 20
MaxClients 12800
MaxRequestsPerChild 5000
ExtendedStatus Off
工人.属性:
worker.maintain=30
worker.template.type=ajp13
worker.template.session_cookie=JSESSIONID
worker.template.lbfactor=1
worker.template.ping_timeout=10000
worker.template.connection_pool_timeout=10
worker.template.socket_keepalive=True
worker.template.socket_timeout=600
worker.template.connect_timeout=10000
worker.template.prepost_timeout=10000
worker.template.connection_ping_interval=20
worker.template.ping_mode=A
worker.template.socket_connect_timeout=600000
来自glassfish方面从集群配置方面来看超时10秒,我有:
HTTP 服务属性:
- 连接超时= 10000
请求处理:
- 主题数:2133
- 初始线程数:20
- 线程增量:10
保持活动(启用):
- 线程数:400
- 最大连接数 256
- 超时:10秒
连接池:
- 最大待处理连接数 4096
所以:
- 那么我的配置正确吗?
- 如何解决建立连接数过多的问题或其安全性如何?如果负载再次升高,我不希望 Apache 再次停机。
答案1
关于 mod_jk / mod_ajp:我们使用了一个稍大一些的设置,时不时地会遇到错误和故障,连接会断开,但始终找不到任何问题的真正解决方案(但我们发现了一些仍然存在的错误)
我的建议:进行备用设置并进行性能测试:mod_jk vs proxy_http,如果 proxy_http 在可接受范围内,则跳过 mod_jk。我现在在 2 个不同的设置中完成了此操作(此外,能够用 nginx 替换 apache -> BIG WIN)并且并不后悔。
优点
- 更容易调试
- 更多可能的 lb/前端网关(haproxy、nginx、varnish)
- 更少的海森堡错误
缺点
- 没有找到一些