过程 3.1. 排查过程：

1. 检查 kubernetes 确认重启的原因

   检查 k8s 限额配置，确认给足了资源，不是因为资源不足导致导应用无响应。

   K8S 检查项：

   • 确认 CPU 资源
   • 确认 内存 资源
   • 确认 健康检查时间是否合理，很多情况是因为健康检查导致 k8s 强行重启 pod

   排查的思路是要搞清楚重启的原因是资源不够，还是因为被健康检查时间设置不合理。

2. 排查应用

   排查应用是否因资源配额不足引起的应用崩溃

   排查 Springboot 配置项

   监控 Jvm 各项指标

   结果排查发现，CPU/内存配合没有问题，重启主要原因有两个：

   JDBC 分表，启动时会检查 meta 数据，耗时有时超过 1 分钟，此时 k8s 健康检查以为应用已死，便重启了应用。

   问题出在 Springboot Tomcat 线程数，系统默认 200，也就是 Springboot 同时只能处理200个 restful 请求（包括了健康检查接口 /actuator/health），再有请求尽量只能排队，当排队的链接超过了 60 秒便超时，导致 k8s 杀死应用重启。

   				 
   neo@MacBook-Pro ~ % curl -s http://www.netkiller.cn:8080/actuator/health | jq
   {
     "status": "UP"
   }				
   				
   				

3. 优化配置

   综合前面收集的信息，做出判断，并给出优化解决方案。调整 tomcat 线程数即可解决。

   				 
   server.tomcat.max-threads
   				
   				

   注意：此配置仅对 springboot web 起作用，这个线程数，并不会影响 hikari，redis 等链接池的最大线程数。