apache+tomcat apache线程占满，单各个服务器cpu利用率均特别低

并发量较高的时候（150+），apache的进程数，会迅速的给占满，导致服务无法访问

此时查看cpu，各个服务器的利用率均特别低

查看apache访问日志，发现有几个接口返回慢！怀疑是接口的问题，就对接口做了优化。

优化完成后，稳定了一段时间（半天不到），很快有出现进程数猛的蹿升。于是就怀疑是不是apache的mod_jk里面有参数没有配置好造成的。

于是查看mod_jk 的日志，发现有类似下面的一段

  ajp_service::jk_ajp_common.c (2543): (205_3) sending request to tomcat failed (recoverable)

红色字体那块，应该是说，这个请求是可以重新获得。我就怀疑，是不是因为当有大量并发产生，有部分请求失败，造成，自动的重新获得，这样几个几个的累计造成实际的并发更大，快速的将apache的进程占满。在网上搜了下，找到了这么一个参数 “recovery_options”

http://tomcat.apache.org/connectors-doc/reference/workers.html 官网的文档里有这样的说明

Recovery options influence, how we should handle retries, in case we detect a problem with Tomcat. How often we will retry is controlled by the attribute  retries .

This attribute is a bit mask. The following bits are allowed:
1: don't recover if Tomcat failed after getting the request
2: don't recover if Tomcat failed after sending the headers to client
4: close the connection to Tomcat, if we detect an error when writing back the answer to the client (browser)
8: always recover requests for HTTP method HEAD (even if Bits 1 or 2 are set)
16: always recover requests for HTTP method GET (even if Bits 1 or 2 are set)

This features has been added in jk 1.2.6. Option 4 has been added in version 1.2.16, options 8 and 16 in version 1.2.24.

也就是说，1.2.24及以后版本，的  recovery_options 参数，支持 1 、2、3、8、16 几个选项

1、2两个选项的大致意思应该是，tomcat相应失败的时候，不要去重新尝试，

8、16应该是在失败的时候，去尝试

4，从上面理解感觉就极端了点，直接断开与tomcat的链接？那后面这个tomcat的服务是不是就中止了？

网上有找到这么一段

http://www.esnsc.com/news460.html

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还不死--没响应,反而使出错的数量比检测恢复之后出错的数量还少，性能还加强了，如果原来用这种的集群78台机器，有一阵就挂掉，改成这个配置只要30台机器，一般在同样的时间段内运行无反应或出错的情况比recovery_options使用默认值的少。

这个估计是比较早的mod_jk 的参数配置？

最后我尝试了下，配置成3（这个项官网上貌似没有），试了试，竟然连续几天都不再出现apache进程被占满的情况了

worker.tomcat.recovery_options=3

后续继续观察。但有些疑问，为什么这个recovery_options=3，在官方文档上里没写是什么意思呢？目前也不知道 recovery_options=3 到底现在还是不是网文中说的作用。继续观察下吧