杜绝假死,Tomcat容器做到自我保护,设置最大连接数
该文章来自阿里巴巴技术协会( ATA )精选集前提说明
为了确保服务不会被过多的http长连接压垮,我们需要对tomcat设定个最大连接数,超过这个连接数的请求会拒绝,让其负载到其它机器。达到保护自己的同时起到连接数负载均衡的作用。
动手去做
一开始根据故障todoList提供的参数MaxKeepAliveRequests,进行验证,我们将tomcat配置server.xml修改为:
同时,启动客户端模拟30个长连接。
预期应该只有10个连接能保持住。
结果与预期不符,30个连接都连上了,而且正常。
这由此怀疑提供的配置参数是否是真正限制最大连接数的含义了。
KeepAlive是在HTTP1.1中定义的,用来保持客户机和服务器的长连接,通过减少建立TCP Session的次数来提高性能。常用的配置参数有{KeepAlive, KeepAliveTimeout, MaxKeepAliveRequests}。逐个说来:
KeepAlive是决定开启KeepAlive支持;
KeepAliveTimeout决定一 个KeepAlive的连接能保持多少时间,Timeout就尽快shutdown链接,若还有数据必须再建立新的连接 了;
MaxKeepAliveRequests于KeepAliveTimeout相似,意思是服务多少个请求就shutdown连接。
显然与我们想到的要求不符,再搜索其它配置参数:
maxConnections
根据字面意思觉得就应该是这个了。
去验证吧,
!
最大连接数为10,我们启动30个长连接,
预期应该是只有10个长连接,实际结果却是远超过10个。这个有点不应该啊。
实验验证
maxThreads:tomcat起动的最大线程数,即同时处理的任务个数,默认值为200
acceptCount:当tomcat起动的线程数达到最大时,接受排队的请求个数,默认值为100
这两个值如何起作用,请看下面三种情况
情况1:接受一个请求,此时tomcat起动的线程数没有到达maxThreads,tomcat会起动一个线程来处理此请求。
情况2:接受一个请求,此时tomcat起动的线程数已经到达maxThreads,tomcat会把此请求放入等待队列,等待空闲线程。
情况3:接受一个请求,此时tomcat起动的线程数已经到达maxThreads,等待队列中的请求个数也达到了acceptCount,此时tomcat会直接拒绝此次请求,返回connection refused
原来tomcat最大连接数取决于maxConnections这个值加上acceptCount这个值,在连接数达到了maxConenctions之后,tomcat仍会保持住连接,但是不处理,等待其它请求处理完毕之后才会处理这个请求。
源码分析
tomcat的最大连接数参数是maxConnections,这个值表示最多可以有多少个socket连接到tomcat上。BIO模式下默认最大连接数是它的最大线程数(缺省是200),NIO模式下默认是10000,APR模式则是8192(windows上则是低于或等于maxConnections的1024的倍数)。如果设置为-1则表示不限制。
在tomcat里通过一个计数器来控制最大连接,比如在Endpoint的Acceptor里大致逻辑如下:
while (running) {
...
//if we have reached max connections, wait
countUpOrAwaitConnection(); //计数+1,达到最大值则等待
...
// Accept the next incoming connection from the server socket
socket = serverSock.accept();
...
processSocket(socket);
...
countDownConnection(); //计数-1
closeSocket(socket);
}
计数器是通过LimitLatch锁来实现的,它内部主要通过一个java.util.concurrent.locks.AbstractQueuedSynchronizer的实现来控制。
我们将最大连接数设置为10,同时启动超过30个长连接,
然后通过jstack可以看到acceptor线程阻塞在countUpOrAwaitConnection方法上:
http-nio-8080-Acceptor-0" daemon prio=10 tid=0x00007f9cfc191000 nid=0x1e07 waiting on condition [0x00007f9ca9fde000]
java.lang.Thread.State: WAITING (parking)
at sun.misc.Unsafe.park(Native Method)
- parking to wait for <0x000000076595b688> (a org.apache.tomcat.util.threads.LimitLatch$Sync)
at java.util.concurrent.locks.LockSupport.park(LockSupport.java:156)
at java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:811)
at java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedInterruptibly(AbstractQueuedSynchronizer.java:969)
at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireSharedInterruptibly(AbstractQueuedSynchronizer.java:1281)
at org.apache.tomcat.util.threads.LimitLatch.countUpOrAwait(LimitLatch.java:115)
at org.apache.tomcat.util.net.AbstractEndpoint.countUpOrAwaitConnection(AbstractEndpoint.java:755)
at org.apache.tomcat.util.net.NioEndpoint$Acceptor.run(NioEndpoint.java:787)
at java.lang.Thread.run(Thread.java:662)
代码层面也解释了这种现象。
总结
tomcat能支持最大连接数由maxConnections加上acceptCount来决定。同时maxThreads如何设定?
以下部分结论引用自:http://duanfei.iteye.com/blog/1894387
一般的服务器操作都包括两方面:1计算(主要消耗cpu),2等待(io、数据库等)
第一种极端情况,如果我们的操作是纯粹的计算,那么系统响应时间的主要限制就是cpu的运算能力,此时maxThreads应该尽量设的小,降低同一时间内争抢cpu的线程个数,可以提高计算效率,提高系统的整体处理能力。
第二种极端情况,如果我们的操作纯粹是IO或者数据库,那么响应时间的主要限制就变为等待外部资源,此时maxThreads应该尽量设的大,这样 才能提高同时处理请求的个数,从而提高系统整体的处理能力。此情况下因为tomcat同时处理的请求量会比较大,所以需要关注一下tomcat的虚拟机内 存设置和linux的open file限制。
现实应用中,我们的操作都会包含以上两种类型(计算、等待),所以maxThreads的配置并没有一个最优值,一定要根据具体情况来配置。
最好的做法是:在不断测试的基础上,不断调整、优化,才能得到最合理的配置。
acceptCount的配置,我一般是设置的跟maxThreads一样大,这个值应该是主要根据应用的访问峰值与平均值来权衡配置的。
如果设的较小,可以保证接受的请求较快相应,但是超出的请求可能就直接被拒绝
如果设的较大,可能就会出现大量的请求超时的情况,因为我们系统的处理能力是一定的。