问题

接上篇文章 K8S集群中高并发应用undertow线程数不足引起的重启，产生的原因则是使用的undertow的系统默认配置，undertow线程数不足引起的问题。

建议

undertow默认配置情况下，官方默认配置的是 CPU核数*8，比如8核CPU，实际工作线程数也就8*8=64，这个配置对于高并发场景来看，一台8核CPU的机器一般内存都会32G或以上，即使跑满64线程，占用的资源远远无法充分利用该机器的性能。

当然啦，官方也是建议工作线程数的配置，取决于你机器的负载情况，其实也就是跟你的具体业务有关，我们现在的业务场景，64线程跑满的情况，CPU利用率仅仅百分之十几、CPU内存远远没利用完，再有请求过来，undertow则直接阻塞队列中，无法正常处理，资源浪费严重，还导致了服务中断的情况。

因此，从实际情况来看，一定不要采用undertow的官方默认配置。像我们线上业务来看，每个API接口业务耗时大多数在10ms以内，少部分耗时30-50ms时间，单接口耗用资源不大。 修改undertow配置 worker-threads=256，单节点可以承载256的并发任务，剩下的就是根据实际业务情况动态扩展节点数量即可。

　　 io-threads：IO线程数, 它主要执行非阻塞的任务，它们会负责多个连接，默认设置每个CPU核心一个线程，不可设置过大，否则启动项目会报错：打开文件数过多。

　　worker-threads：阻塞任务线程池，当执行类似servlet请求阻塞IO操作，undertow会从这个线程池中取得线程。它的值取决于系统线程执行任务的阻塞系数，默认值是 io-threads*8，这里我们手动指定相应的值。


server: port: 1112 undertow: io-threads: 8 worker-threads: 256


常見配置：

# Undertow 日志存放目录
server.undertow.accesslog.dir=
# 是否启动日志
server.undertow.accesslog.enabled=false 
# 日志格式
server.undertow.accesslog.pattern=common
# 日志文件名前缀
server.undertow.accesslog.prefix=access_log
# 日志文件名后缀
server.undertow.accesslog.suffix=log
# HTTP POST请求最大的大小
server.undertow.max-http-post-size=0 
# 设置IO线程数, 它主要执行非阻塞的任务,它们会负责多个连接, 默认设置每个CPU核心一个线程
server.undertow.io-threads=4
# 阻塞任务线程池, 当执行类似servlet请求阻塞操作, undertow会从这个线程池中取得线程,它的值设置取决于系统的负载
server.undertow.worker-threads=20
# 以下的配置会影响buffer,这些buffer会用于服务器连接的IO操作,有点类似netty的池化内存管理
# 每块buffer的空间大小,越小的空间被利用越充分
server.undertow.buffer-size=1024
# 每个区分配的buffer数量 , 所以pool的大小是buffer-size * buffers-per-region
server.undertow.buffers-per-region=1024
# 是否分配的直接内存
server.undertow.direct-buffers=true