最近生产上遇到一个case,终于想明白了原因,今天周末来整理一下

生产case

最近测试istio mesh的预热功能(调用端最小连接数原则)

来控制调用端进入k8s刚扩出来的容器的流量

因为刚启动的JVM解释执会导致慢请求,如果不控制流量会导致cpu突然飙升等带来的一系列连锁反应!

表像这里我借用github上有个哥们的相类似提问:

image
image

翻译一下:

首先突发流量导致线程突然上升到最大线程(800),

流量下来后还在工作的线程(busy threads)线程就下降到了 10,

但是tomcat的 currentThreadCount 仍然是 800。

根据对于线程池的理解,tomcat的工作线程空闲 60 秒(默认),它就会被回收呀,为啥一直下不来呢?

我和他只是配置有点不一样,表像是一样的,也是同样的疑问

问题重点

  • 为什么流量下来后tomcat的工作线程居高不下迟迟得不到回收?
  • 查文档或者搜google,都说设置maxIdleTime,其实它是有坑的

假设tomcat的配置如下(关键参数):


 <!--The connectors can use a shared executor, you can define one or more named thread pools
   <Executor name="tomcatThreadPool" namePrefix="catalina-exec-"
    maxThreads="150" minSpareThreads="4" maxIdleTime="60000"/>
  -->          
            
<Connector port="8080" 
          protocol="org.apache.coyote.http11.Http11NioProtocol"
          minSpareThreads="20"
          maxThreads="1024"
          maxConnections="10000" 
          connectionTimeout="60000" 
          acceptCount="150"/>

问题排查

根据tomcat源码

我们把上面几个核心参数都理一遍

acceptCount

TCP SYN QUEUE队列的长度 默认 100

image
image

connectionTimeout

image
image

默认 20000ms

对应Socket的SO_TIMEOUT属性 是用于指定 ServerSocket.accept 和 Socket.getInputStream().read 超时的套接字选项,超时会抛出SocketTimeoutException 【60000意味着如果超过1分钟还没有数据到达】

tomcat的核心流程

我们先讲讲下当请求进入,tomcat经历了哪些步骤:

tcp建立相关略

  • 1)Acceptor线程处理 socket accept
  • 2)Acceptor线程处理 注册registered OP_READ到多路复用器
  • 3)ClientPoller线程 监听多路复用器的事件(OP_READ)触发
  • 4)从tomcat的work线程池取一个工作线程来处理socket[http-nio-8080-exec-xx]

maxConnections

accptor线程和clientPoller线程的交互逻辑如下:

image
image
image
image

在这个交互中,每serverSock.accept()会被org.apache.tomcat.util.threads.LimitLatch计数 在closeSocket的时候减少计数!

LimitLatch这个对象的计数初始值就是配置的maxConnections值(默认为10000)

minSpareThreads和maxThreads

  • minSpareThreads 核心线程数
  • maxThreads 最大线程数

ClientPoller线程拿到read或者write事件后进行处理就会从tomcat的线程池拿到一个工作线程去处理

这里的tomcat的Connector在创建工作线程池就会用到这2个参数

image
image

注意 这里的线程池的keepAlivetime=60s

线程池相关知识(参考我之前的文章

用一张图来表达各个参数的起作用点

image
image

梳理一下

当tomcat容器启动后

image
image

根据配置 创建 acceptor线程池(默认1个) poller线程池(默认2个)

工作线程池(20个根据我的配置)

假设突发流量打进来,因为我设置的maxThreads=1024

那么会一直创建新的nio处理线程到1024

等后面流量下去了,由于线程的keepalivetime=60s

只要服务一直都有请求进来,

工作线程会从 queue 中抢任务,只要抢到了一个任务,它的 keepalivetime 就会重置

由于我的服务高峰过后,每分钟的请求数量大约是 3000 ~ 4000 个,也就是说每个线程都有机会抢到任务,这应该就是线程一直存活的原因

(当然了没有机会抢到任务的就回收了,所以也不会一直是1024)

第二个问题,既然这样我有办法修改工作线程的keepalivetime吗

可以的,但是得换成用Executor创建的线程池(如下我改成了10s)


 <!--The connectors can use a shared executor, you can define one or more named thread pools --> 
<Executor name="tomcatThreadPool" namePrefix="catalina-exec-"
    maxThreads="1024" minSpareThreads="20" maxIdleTime="10000"/>
          
            
<Connector port="8080" 
          protocol="org.apache.coyote.http11.Http11NioProtocol"
          executor="tomcatThreadPool"
          maxConnections="10000" 
          connectionTimeout="60000" 
          acceptCount="150"/>

如果你配置了Executor的话,那么Executor的创建线程池逻辑如下:

image
image

确认使用了maxIdleTime值来设置线程的keepalivetime

tomcat7配置解说官网:https://tomcat.apache.org/tomcat-7.0-doc/config/http.html

tomcat8配置解说官网:https://tomcat.apache.org/tomcat-8.0-doc/config/http.html

注意的一点是,一定要却别理解Excutor和Connector两种在创建线程池是有区别的,不能混淆了

如果用Connector创建的线程池是写死60s!

由于tomcat默认都是不推荐使用共享的Executor(被注释的), 但是在Connector里面又不支持设置工作线程的maxIdleTime, 这个有点不理解为什么这么设计!

总结

通过这个case,带着这些参数在tomcat里是怎么起作用的疑问,结合tomcat的源码,是次很有收获的梳理!

作者:|俞正东|,原文链接: https://www.cnblogs.com/yudongdong/p/16320583.html

文章推荐

《Mybatis 手撸专栏》第10章:使用策略模式,调用参数处理器

Go中rune类型浅析

数仓血缘关系数据的存储与读写

基于SqlSugar的开发框架循序渐进介绍(5)-- 在服务层使用接...

K8s Calico网络插件

Nginx分片限流

图解Dijkstra算法+代码实现

python多线程同步售票系统解决思路

TiDB Cloud GA,助力全球企业在云上构建新一代云原生应用

基础设施即代码:你需要知道的一切

秒懂 23 种设计模式!有点污,但真得秒啊...

其实 Gradle Transform 就是个纸老虎 —— Gradl