Spring Boot+Undertow在K8s压测报too many open files配置咨询

一、"too many open files"报错根因 #

你观测到的容器ulimit是进程全局限制，本次报错大概率是其他层面的触顶导致：

• 你当前Undertow仅配置了IO线程和工作线程，未配置max-connections（最大连接数）参数，默认Undertow单实例最大连接数为1000，压测时并发连接上来很容易触达上限，每个TCP连接对应一个文件句柄，触达上限就会抛出too many open files错误。
• NodePort流量需要经过宿主机kube-proxy转发，你统计的lsof数值仅覆盖容器内进程的句柄占用，未统计宿主机节点、kube-proxy组件的句柄占用，200线程压测时节点层面句柄占满也会触发502报错。

二、单实例承载能力评估 #

你150线程压测已经达到15000QPS的吞吐量，说明单实例基础处理能力足够：

• 只要配置调整正确，单实例完全可以承载5000并发请求，甚至可以支撑到10000级别的并发，不需要直接按25副本的标准扩容。
• 你当前的工作线程配置worker: 128偏低，工作线程是负责处理业务逻辑的线程，IO线程16对应2核CPU是合理配置（常规标准为CPU核心数*2），但工作线程数可以根据业务属性调整，IO密集型业务可以调整到500~1000区间。

三、优化配置参考 #

调整Undertow配置如下：

server:
  undertow:
    threads:
      worker: 800 # 可根据后续压测结果调整，IO密集型业务可继续上调
      io: 16 # 2核CPU下该配置合理，无需调整
    max-connections: 20000 # 远高于目标5000并发，预留冗余
    no-request-timeout: 60000
    # 短连接场景下开启TCP复用优化
    socket-options:
      TCP_NODELAY: true
      SO_REUSEADDR: true
      SO_KEEPALIVE: true

同时补充两项底层配置检查：

• 检查K8s节点层面的ulimit配置，执行ulimit -n确认节点句柄限制不低于65535，很多默认环境节点ulimit仅为1024或65535，压测时会先占满节点句柄，导致容器内统计的句柄数值还很低就报错。
• 若集群kube-proxy使用ipvs模式，调整ipvs连接超时时间，避免大量TIME_WAIT连接占用端口和句柄资源。

四、扩容建议 #

调整完配置后先做压测验证：

• 若单实例压测到5000并发无报错、CPU使用率稳定在70%以下，仅需部署2~3个副本做高可用即可，无需扩容到25副本。
• 若单实例CPU已经打满，再按照实际负载做水平扩容。

内容的提问来源于stack exchange，提问作者Wi-Al