Ari*_*Git 6 spring-boot spring-boot-actuator
我们使用 Spring Boot 执行器在 Kubernetes 集群中运行时公开活动和就绪端点。默认情况下,spring-boot 执行器在默认标准 HTTP 服务器端口上公开端点,其中请求由 Tomcat/Jetty 服务器接受器和工作线程池提供服务。最近,我们在压力测试期间遇到了一个问题,工作池中的所有线程都很忙,并且新请求正在排队。由于活性探针开始失败,这导致 Kubernetes 集群中的 Pod 崩溃。
我正在考虑在管理端口上公开执行器。我想检查以下内容
a) 管理端口上的请求是否由单独的工作线程池(与标准服务器端口的请求线程池不同)提供服务?
b) 如果 a) 的答案是否定的,有没有办法可以配置 spring boot 以使用单独的线程池作为管理端口(我们在不同的微服务中使用 tomcat/jetty 和反应式 netty 服务器)
是的,如果您指定不同的管理端口,Spring/Tomcat 将使用单独的线程池来处理该端口上的请求。
例如,如果您指定这样的内容就是您的配置:
server.port=8080
management.server.port=8081
server.tomcat.threads.max=10
Run Code Online (Sandbox Code Playgroud)
端口 8080 上的常规请求将由标准线程池中的线程提供服务,该线程池总共有 10 个线程 ( server.tomcat.threads.max)。您将在日志中看到线程名称,如下所示:
... nio-8080-exec-<number from 1 to 10>..
Run Code Online (Sandbox Code Playgroud)
管理/运行状况检查线程将由来自不同线程池的线程提供服务,该线程池的总大小也为 10。您将在日志文件中看到这些线程,如下所示:
... nio-8081-exec-<number from 1 to 10>..
Run Code Online (Sandbox Code Playgroud)
注意:这样做可能会解决运行状况检查失败导致 Pod 重新启动的问题,但它可能无法解决流量激增时所有工作线程被占用的根本原因。也许您需要研究速率限制之类的东西来处理这种情况,这样您的服务就不会获得超出其处理能力的流量。
| 归档时间: |
|
| 查看次数: |
1999 次 |
| 最近记录: |