Spring Boot Starter Web应用高负载下崩溃问题排查咨询

一、连接池配置排查 #

• 核对HikariCP与RDS连接数匹配度
  • 检查spring.datasource.hikari.maximum-pool-size配置：若设置过大，会导致RDS连接排队；过小则工作线程等待连接阻塞。建议设置为Undertow工作线程数的1_{1.2倍（比如4核实例可先设为32}40）。
  • 查看连接超时配置spring.datasource.hikari.connection-timeout：超时过短会直接抛出连接获取失败，过长则导致线程堆积，建议设为3000~5000ms。
  • 实时监控RDS连接数：执行SELECT count(*) FROM pg_stat_activity;，负载高峰时确认是否接近RDS最大连接数（800+），或存在大量空闲未释放的连接。

二、Undertow服务器瓶颈排查 #

• 检查线程模型配置
  • 核对server.undertow.io-threads（默认等于CPU核数，4核为4）和server.undertow.worker-threads（默认8*核数=32）：若工作线程数不足，55QPS即可占满线程池，导致后续请求排队无响应。可尝试调高worker-threads至64或128，重新压测验证。
  • 检查请求队列大小server.undertow.queue-size：队列过小会直接拒绝新请求，建议设为1024或更高。
  • 查看应用日志：搜索是否存在Too many open connections或线程池耗尽的报错信息。

三、数据库层性能排查 #

• 定位慢查询与锁等待
  • 开启Postgres慢查询日志：设置log_min_duration_statement = 100（记录超过100ms的查询），排查是否存在JPA生成的N+1查询、未加索引的复杂SQL。
  • 检查锁等待情况：执行SELECT * FROM pg_locks WHERE NOT granted;，查看是否有大量等待行锁/表锁的会话，导致请求阻塞。
  • 分析连接等待事件：执行SELECT wait_event_type, wait_event, count(*) FROM pg_stat_activity WHERE state = 'active' GROUP BY wait_event_type, wait_event;，若出现大量IO类等待，需排查RDS存储IO瓶颈（如磁盘IOPS不足）；若为ClientRead/Write，则可能是应用端处理缓慢。

四、JVM线程与GC排查 #

• 分析线程阻塞与死锁
  • 负载测试时导出线程dump：执行jstack <应用进程ID>或jcmd <应用进程ID> Thread.print，检查是否有大量WAITING（等待连接/锁）或BLOCKED状态的线程。
  • 排查死锁：查看线程dump中是否存在Found one Java-level deadlock提示，或用jconsole实时监控线程状态。
  • 检查GC情况：开启GC日志（添加JVM参数-Xloggc:/var/log/gc.log -XX:+PrintGCDetails -XX:+PrintGCDateStamps），分析是否存在频繁Full GC导致的应用暂停，即使内存使用率未超50%，也可能因新生代分配不合理引发频繁YGC。

五、Docker资源限制排查 #

• 确认容器资源分配
  • 查看容器资源限制：执行docker inspect <容器ID>，检查HostConfig.CpuShares、HostConfig.Memory等配置，避免容器被限制的CPU/内存远低于EC实例（比如只分配2核8G），导致容器内资源耗尽而实例整体使用率未超标。
  • 实时监控容器资源：执行docker stats <容器ID>，负载高峰时确认容器内CPU/内存是否触及限制阈值。

六、JPA与ORM层优化排查 #

• 修复低效ORM操作
  • 检查批量操作：是否存在大量单条插入/更新，未使用JPA批量提交（需开启spring.jpa.properties.hibernate.jdbc.batch_size），导致数据库连接频繁占用。
  • 排查N+1查询：开启spring.jpa.show-sql=true，查看是否存在循环调用关联对象触发的多余查询，可通过@Fetch(FetchType.JOIN)或实体图优化。
  • 验证二级缓存：是否开启二级缓存（如Ehcache），避免重复查询数据库。

七、网络与系统限制排查 #

• 检查网络与文件句柄
  • 测试EC与RDS的网络延迟：用ping、tcpping验证跨AZ或区域的网络是否存在高延迟或抖动，导致请求响应缓慢。
  • 检查文件句柄限制：执行ulimit -n，若默认值过低（如1024），负载高峰时会出现Too many open files错误，需修改/etc/security/limits.conf将软/硬限制调高至65535。

内容的提问来源于stack exchange，提问作者Arun Prasan