JMeter压测时Spring Boot应用超55QPS无响应的排查咨询

一、Undertow服务器配置排查 #

• 检查核心线程配置：确认server.undertow.io-threads（IO线程，默认等于CPU核心数）和server.undertow.worker-threads（工作线程，默认8*CPU核心数）是否匹配当前4vCPU的ECS规格，若工作线程数不足，会导致请求排队阻塞。
• 验证请求队列大小：检查server.undertow.threads.queue-size配置，若队列满后未设置合理拒绝策略，会导致新请求无法被处理，应用表现为无响应。
• 查看访问日志：检查Undertow访问日志中是否有大量5xx状态码或请求超时记录，定位服务器层面的请求处理瓶颈。

二、HikariCP连接池排查 #

• 检查连接池核心参数：确认spring.datasource.hikari.maximum-pool-size是否合理（4vCPU环境建议设置为10-20），若连接池过小，请求会因等待数据库连接而阻塞；若过大，会增加数据库端的连接开销。
• 开启连接泄漏检测：设置spring.datasource.hikari.leak-detection-threshold=3000（单位毫秒），查看应用日志中是否有连接泄漏警告，未关闭的连接会耗尽连接池资源。
• 检查连接超时配置：确认spring.datasource.hikari.connection-timeout是否过短，若请求等待连接超时，会导致请求失败或阻塞蔓延。

三、Postgres RDS数据库排查 #

• 实时监控连接数：执行SELECT count(*) FROM pg_stat_activity;，查看负载测试时实际连接数是否接近RDS最大连接数或应用连接池上限，连接耗尽会导致新请求无法获取数据库连接。
• 排查慢查询：执行SELECT queryid, query, total_time, calls FROM pg_stat_statements ORDER BY total_time DESC LIMIT 10;（需提前开启pg_stat_statements扩展），找出耗时最长的查询，慢查询会长期占用连接资源，拖垮整体请求处理速度。
• 监控RDS资源使用率：查看RDS控制台的CPU、内存、磁盘IO指标，若负载测试时CPU使用率接近100%或磁盘IO饱和，会导致数据库响应缓慢，进而阻塞应用请求。

四、ECS服务器与Docker容器排查 #

• 监控服务器资源：使用top、vmstat工具查看负载测试时的CPU、内存使用率，若4vCPU被跑满，会导致应用无法及时处理请求；内存不足会触发频繁GC或内存溢出。
• 检查容器资源限制：执行docker stats查看后端容器的CPU、内存占用情况，确认是否给容器设置了不合理的资源限额（如CPU核数限制过低），导致容器无法利用ECS的全部资源。
• 排查网络瓶颈：使用iftop查看服务器网络带宽使用情况，确认是否存在带宽耗尽；用netstat -an | grep ESTABLISHED查看活跃连接数，大量连接堆积会占用系统资源，导致请求处理延迟。

五、应用代码与JVM排查 #

• 抓取线程栈分析：在应用无响应时，执行jstack <pid>（pid为后端应用进程ID），查看是否有大量线程处于BLOCKED或WAITING状态，定位锁竞争或阻塞调用点（如未优化的同步方法、IO操作）。
• 监控GC情况：使用jstat -gcutil <pid> 1000（每1秒输出一次GC指标），查看是否存在频繁Full GC（FGCT持续升高），Full GC会导致应用停顿，无法处理新请求。
• 检查错误日志：查看后端应用的error.log，是否有数据库连接超时、事务超时、空指针等异常，这些异常可能导致请求处理中断或线程阻塞。

六、负载测试场景验证 #

• 确认JMeter配置合理性：检查JMeter的线程数、循环次数、Ramp-Up时间是否设置正确，避免因JMeter自身性能瓶颈（如本地机器资源不足）导致无法达到更高QPS，误判应用问题。
• 验证请求一致性：确认超过55QPS时的请求与低QPS时的请求是否一致，是否存在大Payload请求、批量操作等复杂请求，这类请求会占用更多资源，导致QPS上限降低。

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