tomcat的acceptCount、maxThreads、connectionTimeout参数调整

最新推荐文章于 2024-04-17 02:34:51 发布

WWWWWWWWolf

最新推荐文章于 2024-04-17 02:34:51 发布

阅读量319

点赞数

CC 4.0 BY-SA版权

文章标签： java 网络操作系统

原文链接：https://my.oschina.net/go4it/blog/821742

本文探讨了Tomcat服务器性能调优的关键参数，包括acceptCount、maxThreads及connectionTimeout等，详细介绍了这些参数的合理设置范围及其对系统性能的影响。

摘要生成于 C知道，由 DeepSeek-R1 满血版支持，前往体验 >

为什么80%的码农都做不了架构师？>>>

###acceptCount值调整(默认100) acceptCount的经验值的范围为50-300，当tomcat的处理能力不够快的时候，可以调整该值，比较有用。

当系统的并发量比较大的时候，关闭keep alive，然后适当调整该值
当连接建立之后，经常得不到worker线程处理时，可以适当降低该值，开启keep alive

当该值设置为比较大的时候，请求的突增，会很快填满accept队列(完成三次握手建立连接，等待工作线程处理响应，如果一直没得到service，则client得不到响应，出现read timeout，最糟糕的情况是连接在accept队列等待了很久，等到能得到worker线程服务的时候，已经超时了，这样其实浪费了很多连接)，让woker线程非常繁忙，当超过系统的承受能力的时候，请求不断堆积，然后导致工作线程cpu饿死(starvation)。因此需要系统进行自我保护，当超出负载能力的时候，迅速fail fast，返回503。

因此要合理评估系统高峰的时候，worker线程池的大小。假设server平均每个请求耗时5ms，那么1个线程每秒rps可以有200，假设有4核cpu，那么每秒最大可以有800rps。现在假如有4个请求同时进来，那么4个线程将繁忙起来，也就是接下来的5ms中，这些线程时繁忙的。那么对于这个4核cpu的系统来说，最大的rps就是800.

当acceptCount的值设置的太小的时候，当请求量大的时候，操作系统无法给tomcat建立更多的连接(无法完成三次握手)，client端出现很多connect timeout，而这些被拒绝掉的请求可能是在worker线程的处理能力之内的。

当开启http keep alive的时候，client端可能没有那么及时地关闭连接，那么server端的worker线程会一直被这些实际上可能不活跃的连接给占用了，导致worker线程没能重复利用起来。但是关闭http keep alive的时候，频繁的地进行tcp连接和端口，这样会造成很多TIME_WAIT的socket，给服务端增加压力。

##maxThreads值调整(默认200)