apache+tomcat 集群高负载性能问题

李斯特

　　在用apache+tomcat做负载均衡的时候，遇到服务器问题，apache的日志如下：
　　写道
==ajp_process_callback::jk_ajp_common.c (1945): Writing to client aborted or client network problems
==ajp_service::jk_ajp_common.c (2607): (tomcat2) sending request to tomcat failed (unrecoverable), because of client write error (attempt=1)
==service::jk_lb_worker.c (1400): service failed, worker tomcat2 is in local error state
==service::jk_lb_worker.c (1419): unrecoverable error 200, request failed. Client failed in the middle of request, we can't recover to another instance.
==jk_handler::mod_jk.c (2671): Aborting connection for worker=controller
　　网上找了一些解决办法，这里贴出只是为了备注一下，方便以后查找。
写道
1现象
当然能报这个错的原因很多，配置不对连不上的，二者版本不对，不兼容的,这里不讨论这些入门的事。只说配置成功，在有较高负载的情况下出现这种情况。这种情况还伴随着apache的文件正常访问，单独访问tomcat的端口也正常。只是访问apache+tomcat的端口出事。

2解决方案
在workers.properties里设置相应的负载机器的recovery_options=3

3解释
recovery_options属性说明了web server在检测到Tomcat失败后如何进行恢复工作。默认情况下，web server将转发请求给处于负载平衡模式中的另一个Tomcat。属性值为0，说明全部恢复；属性值为1，说明如果在Tomcat接到请求后出现失败状况，则不进行恢复；属性值为2，说明如果在Tomcat发送http头给客户端后出现失败状况，则不进行恢复；属性值为3，说明如果在Tomcat接到请求后出现失败状况或者在Tomcat发送http头给客户端后出现失败状况，则不进行恢复。此属性在jk 1.2.6版本被增加进来，以求避免Tomcat的死机和在支持ajp13的servlet引擎上发生的问题。此属性默认为全部恢复。
因在默认的情况下，JK检测tomcat的工作情况，所以浪费了很多资源，这个资源多到比tomcat正常工作所需的资源的1.6倍还多--通过后来的满足更多请求使用更少机器的情况估计出来的保守值。如果不检测恢复，则效率高了，处理的请求数可以是原来的2.6倍多，而且tomcat还不死--没响应,反而使出错的数量比检测恢复之后出错的数量还少，性能还加强了，如果原来用这种的集群100台机器，有一阵就挂掉，改成这个配置只要40台机器，一般在同样的时间段内运行无反应或出错的情况比recovery_options使用默认值的少得多。
recovery_options的最新参考
http://tomcat.apache.org/connectors-doc/reference/workers.html

4思考过程和方法
具体说是具体问题具体分析，这里主要是观察和思考矛盾现象。
矛盾现象:负载高时，机器僵死，CPU和IO都不怎么用，只处理少量请求，tomcat单独访问没问题，apache单独访问没问题。现象很矛盾，负载高反而不做什么事。
观察这种矛盾现象用到了查看机器网络流量，CPU占用，全局共享文件，使用内存，IO使用情况，apache和tomcat使用的文件、socket、线程。综合上面的现象和一些观察的结果看，问题出现在apache连接tomcat上，当然就去找那个上面提到过的配置文件参考。几乎试用了所有参数，最终找到这个参数，起初没觉得这个错误恢复功能会使性能下降这么大，不过仔细想想这个功能确实会占用大量的资源，一个程序监控另一个程序里的连接数据还要根据这些数据判断一堆东西显然要比一个只往自己的网络连接里收发数据的程序占用的资源大，以至性能下降很大。改了它之后解决了一半高负载的问题。还有可能会出现的另一个问题。

5可能出现的问题
在服务器管理的实践中遇到过经改完配制后，有的机器还有上面的报错，但已经不是不用CPU和IO了，看样子是正常工作了。有的机器现象较好，一个apache+4个tomcat,一晚上可以处理1000万的请求。用jmeter开50个线程狂压都死不了。起初认为是新旧机器的事，因旧机器性能本身是差，并且旧机器中出现以上报错的也多。但是也有一两台旧机器运行良好，一两台新机器一两天就会出现上面的报错。为此，又分析了一下这个矛盾现象。
从监控新机器处理的流量开始,这些新机器每天处理的流量都是差不多的，配制基本上一样。上面说过一台运行好的机器12小时处理1000万请求还轻松，而正常运营的每台机器24小时处理不超过150万请求，还有报错的现象。显然性能差别巨大不是新旧机器性能上的而是本质上的。
于是在新机器中选出性能好和不好的，全面对比，还算是比较顺利，因用CPU多的只有tomcat，而用ps看程序时，发现二者的java路径不一样，很容易让人想到是jre的事。把性能不好的机器换上的jrocket的jre，问题解决了。
原因为普通的jre总是回收内存，做了回收内存的日志，一秒钟最少回收一次，一台机器4个tomcat则每秒至少回收4次，回收期间使用CPU高--1个tomcat占500多兆内存，而且垃圾回收期间是暂停请求的，所以CPU狂用，而处理的量也不比其它机器多。而jrocket的jre测试用了一两个小时竟然没垃圾回收，网上查了一下有人说那个大约一天才回收一次，不过回收一次可能要几分钟到十几分钟，这就是为什么用apache加一个jrocket的NIO的tomcat不如用apache加4个tomcat好的原因，只要一垃圾回收一个tomcat十几分钟没响应肯定是不行的，虽然单个的NIO的tomcat的性能比4个tomcat的好。

出自：http://blog.sina.com.cn/s/blog_54394f910100p52t.html