这是一个创建于 914 天前的主题，其中的信息可能已经有所发展或是发生改变。
最近在给服务做压测，出现了一个诡异问题。服务部署在三台机器上，请求链路是 压测机 -> LB -> nginx -> 后端服务，其中 nginx 与后端服务同机部署，LB 将请求转发到 3 台机器的 nginx, 每台 nginx 再将请求转发到 3 台机器的后端服务，并且开启了 HTTP 长连接。服务是基于 Spring 的，server 用的 jetty 。
- 服务启动后，第一波压测，3500 并发，QPS 接近 5W ，RT 70ms ，此时都是正常的
- 停止压测机，开启了第二波压测，3000 并发，稳定后 QPS 降到 15000 左右，RT 上升到 200ms
- 检查后端服务监控，请求耗时正常，jstack 打印堆栈发现，jetty 中大量工作线程空闲. 检查 nginx 日志，耗时也正常
- 重新压测，QPS 仍然在 15000 左右，没有提升. 压测过程中重启 nginx ，稳定后 QPS 无变化，重启后端服务，QPS 无变化。停止压测后，重启后端服务，再次启动压测，QPS 恢复到 5w
想问下各位有没有遇到过类似的问题，或者有没有什么排查的思路，感激不尽
第 1 条附言 · 2022-06-12 09:45:45 +08:00
最后查出来是发压机的问题。有一个发压机的池子，每次压测从里面拿出来空闲的 3 台发压。再次压测的时候按照各位评论的思路检查了，gc ，rt ，服务资源等都是正常的，就怀疑是不是有请求没发过来。最后检查 nginx 的连接数，3000 并发情况下建立的连接数应该是 3000 ，但是实际只有 2000 左右，然后检查之前每次不正常的情况都共同选择了一台发压机，然后把这台换了就正常了
 |
1
wy315700 2022-06-11 12:02:26 +08:00 via Android
是不是 timewait 数量很高
|
 |
2
Goooooos 2022-06-11 14:00:49 +08:00 via Android
重启后端能恢复的话，看看进程的 gc 情况，是不是有内存泄漏导致经常 fgc
|
 |
3
Jooooooooo 2022-06-11 14:06:26 +08:00
先看下系统指标呗, gc, thread count, cpu busy 等等看看有无端倪.
|
 |
5
zizon 2022-06-11 18:01:42 +08:00
jetty 工作线程空闲说明是业务逻辑繁忙呗.
压测过程重启无影响,停止压测 full cold restart 恢复说明可能是请求涉及的服务有外部抢占 /依赖资源之类的呗. 比如分布式锁 /队列,且看 1,2 描述可能跟 session 数相关(3500 -> 3500+3000 performance degraded) |
 |
6
szzadkk OP 各位的排查思路都尝试了一遍，检查服务没问题，最后发现是发压机的问题，三台机器有一台没工作....................
|
Select Language