压测中吞吐量骤降的诡异问题

[szzadkk]

最近在给服务做压测，出现了一个诡异问题。服务部署在三台机器上，请求链路是 压测机 -> LB -> nginx -> 后端服务，其中 nginx 与后端服务同机部署，LB 将请求转发到 3 台机器的 nginx, 每台 nginx 再将请求转发到 3 台机器的后端服务，并且开启了 HTTP 长连接。服务是基于 Spring 的，server 用的 jetty 。

1. 服务启动后，第一波压测，3500 并发，QPS 接近 5W ，RT 70ms ，此时都是正常的
2. 停止压测机，开启了第二波压测，3000 并发，稳定后 QPS 降到 15000 左右，RT 上升到 200ms
3. 检查后端服务监控，请求耗时正常，jstack 打印堆栈发现，jetty 中大量工作线程空闲. 检查 nginx 日志，耗时也正常
4. 重新压测，QPS 仍然在 15000 左右，没有提升. 压测过程中重启 nginx ，稳定后 QPS 无变化，重启后端服务，QPS 无变化。停止压测后，重启后端服务，再次启动压测，QPS 恢复到 5w

想问下各位有没有遇到过类似的问题，或者有没有什么排查的思路，感激不尽

最后查出来是发压机的问题。有一个发压机的池子，每次压测从里面拿出来空闲的 3 台发压。再次压测的时候按照各位评论的思路检查了，gc ，rt ，服务资源等都是正常的，就怀疑是不是有请求没发过来。最后检查 nginx 的连接数，3000 并发情况下建立的连接数应该是 3000 ，但是实际只有 2000 左右，然后检查之前每次不正常的情况都共同选择了一台发压机，然后把这台换了就正常了

[wy315700]

是不是 timewait 数量很高

[Sezxy]

重启后端能恢复的话，看看进程的 gc 情况，是不是有内存泄漏导致经常 fgc

[Jooooooooo]

先看下系统指标呗, gc, thread count, cpu busy 等等看看有无端倪.

[szzadkk]

@wy315700 是的，这也是我不理解的一个点，开启了长连接，按理说 TW 应该很少才对

[zizon]

jetty 工作线程空闲说明是业务逻辑繁忙呗.
压测过程重启无影响,停止压测 full cold restart 恢复说明可能是请求涉及的服务有外部抢占 /依赖资源之类的呗.

比如分布式锁 /队列,且看 1,2 描述可能跟 session 数相关(3500 -> 3500+3000 performance degraded)

[szzadkk]

各位的排查思路都尝试了一遍，检查服务没问题，最后发现是发压机的问题，三台机器有一台没工作....................