查询QPS（每秒查询数）对应的服务器，最直接的方法是登录负载均衡或网关的监控后台，按域名或接口维度筛选QPS指标，再下钻到后端各节点IP的实时流量，谁的数据曲线在飙升，谁就是罪魁祸首。 但如果你们没有统一的监控平台，或者流量没走网关，那就要靠系统命令和日志一层层剥开，下面这套排查逻辑适用于绝大多数中小团队。
先搞懂QPS到底卡在哪一层
很多人一上来就挨个服务器跑命令,效率极低，QPS高或异常，本质上是一个“流量分配”问题，得先判断流量是从哪个入口进来的，流量入口通常有三种：Nginx/OpenResty网关、SLB/负载均衡（云厂商）、DNS轮询，你首先要确认应用架构用的是哪一种。
- 如果域名解析到云SLB,那SLB的监控面板里就有每台后端ECS的QPS数据，这是最省事的路径。
- 如果用的是自建Nginx做反向代理,那
ngx_http_stub_status_module模块的监控页面，或者接入Prometheus后暴露的nginx_http_requests_total指标，都能按节点拆出QPS。 - 如果压根没网关,客户端直连业务服务器，那只能逐台登录机器用命令看，同时检查防火墙或安全组规则，看最近是否有异常来源IP在集中请求。
一个常见误区是混淆“并发数”和“QPS”，并发是同一时刻的活跃连接数，QPS是每秒完成的请求数，很多运维在排查时盯着ss -s看连接数，结果发现连接数高的机器未必QPS高，因为可能存在慢请求占用连接不释放，定位服务器，必须先明确你要找的是“处理请求量最大的”，还是“导致延迟飙升的”，这两个目标指向的机器可能不一样。
从监控平台反查节点，比登服务器快十倍
如果你有Prometheus + Grafana这类开源监控组合，查询逻辑非常简单，在Grafana的Dashboard里找到对应服务的QPS面板，编辑查询语句，按instance标签拆分，例如PromQL可以写成sum by (instance) (rate(http_requests_total[1m]))，返回的图例里会直接列出每台服务器的IP和对应的QPS曲线，一眼就能看出哪台机器的柱子最高。
很多云厂商的监控产品也支持类似操作,简米云、酷番云的负载均衡控制台里，在“监听详情”或“后端服务器组”页面，能看到每台RS的“QPS”和“活跃连接数”两列数据，按QPS降序排列即可，这里有个小技巧：
不要只看当前值，要看15分钟到1小时的时间趋势，有些服务器是定时任务触发的高QPS，比如每小时整点跑批，你刚好在非整点查，数据就正常，容易漏判。
如果监控平台里没有按节点拆分的QPS数据,那就要回到服务器本身。
Linux命令行逐台定位的实操套路
用ss和netstat看瞬时连接分布
执行ss -n | awk '{print $4}' | awk -F: '{print $1}' | sort | uniq -c | sort -rn | head -20，这条命令统计当前TCP连接数最多的本地IP（即各网卡或VIP），能粗略判断流量是否集中在某台机器，但注意，这只反映连接数，不是QPS，适合先圈定怀疑范围。
用nettop或iftop抓实时流量
在流量高峰期,登录疑似高负载的机器，执行iftop -n -P -N，按流量大小排序，观察哪个端口和哪个来源IP的吞吐量异常，不过这种方式只适合短时间观察，且需要root权限，生产环境慎用，更稳妥的是用nettop -J tcp -L 1持续输出连接排名，找出占据带宽的进程PID，再通过ps -fp <PID>确认是哪个业务进程。
从Nginx访问日志精确统计单机QPS
Nginx的access.log是最可靠的证据来源，执行下面的awk命令，统计最近1000条日志里的每秒请求数：
tail -n 1000 access.log | awk '{print $4}' | cut -d: -f2-4 | uniq -c | awk '{print $2" 每秒QPS约:"$1}'
这里$4是日志里的时间戳字段（如[10/Oct/2026:13:55:01），按秒去重计数，结果就是该Nginx节点在当前时间段的QPS，如果你想确认是不是某台后端机器扛下了大部分请求，就在Nginx配置里打开log_format的$upstream_addr变量，日志会记录每个请求转发到了哪台后端IP，再用grep统计后端IP出现次数，次数最多的就是高QPS服务器。
业务代码里的“慢SQL”也可能是伪QPS元凶
有相当一部分场景,表面看是某台服务器QPS高，实际是因为这台机器上连接的数据库实例出现了慢查询，应用线程卡在数据库等待上，前端请求不断重试，导致该机器的请求堆积量虚高，排查时别光盯着Web层，要顺手看一眼数据库连接池监控。
- 登录疑似高QPS机器,执行
top -Hp <业务进程PID>，看是否有大量线程处于D（不可中断睡眠）状态，如果是，大概率是在等磁盘I/O或网络I/O。 - 执行
cat /proc/<PID>/status | grep Threads，对比线程数和正常时期的基线，线程数激增往往意味着请求排队。 - 如果业务用的是MySQL,登录数据库执行
SHOW PROCESSLIST;，看是否有大量来自同一台应用服务器IP的连接在执行相似的慢查询，这会直接暴露问题根源。
各排查手段的适用场景对比
| 排查方式 | 适用场景 | 速度 | 精准度 |
|---|---|---|---|
| 云SLB/QPS监控面板 | 流量经过负载均衡，有控制台权限 | 最快 | 高 |
| Prometheus按instance拆指标 | 已有监控体系，且暴露了请求指标 | 快 | 高 |
| Nginx日志按$upstream_addr统计 | 自建Nginx代理，无监控平台 | 中等 | 高 |
| ss/iftop命令实时抓取 | 临时应急，无任何监控数据 | 中等 | 中 |
| 数据库连接池状态反查 | 疑似慢SQL导致请求堆积 | 中等 | 中 |
行业共识认为,规范的监控体系建设成本远低于故障排查成本，平时花半小时把Nginx的vhost_traffic_status模块开了，或者接入Node Exporter，排查时间能从小时级压缩到分钟级，业内专家指出，大多数QPS定位难题都源于日志格式不完整或监控指标未按节点打标，补上这两个基础项，比学习任何高级技巧都管用。
查完QPS之后，顺手要做的三件事
定位到具体服务器只是第一步,后续动作决定了这次排查有没有意义。
- 核对机器规格和业务权重：确认这台高QPS服务器是否承载了核心业务，如果是边缘业务却占了高QPS，可能是有爬虫在刷接口，用
fail2ban或WAF规则拦截。 - 检查自动扩缩容策略：如果用了云上弹性伸缩组，这台高QPS机器是否触发了扩容阈值，有没有新实例自动加入分担流量，如果没有，检查伸缩组冷却时间和阈值设置。
- 对比前后端链路日志：用
traceId串起一整条请求链路，确认高QPS是真实业务流量还是异常攻击，如果请求集中在某个特定URL且无Referer，大概率是恶意刷量。
服务器QPS查看方法的常见疑问解答
问：有没有一条命令能直接显示所有服务器的QPS排名？
没有,QPS本身是统计概念，依赖日志或代理层数据，单条命令只能看单机状态，最接近“一条命令看全部”的用法是写好脚本循环ssh到所有机器执行tail access.log统计，但生产环境不推荐批量免密登录操作，更实际的做法是统一接入监控系统，在Grafana里用一个面板展示所有节点的QPS热力图。
问：QPS和服务器性能之间是什么关系，QPS高就代表服务器有问题吗？
不一定,QPS高只是说明每秒请求量大，如果服务器CPU和内存占用率都在健康范围（比如CPU低于70%），那它只是“忙”而非“病”，你需要关注的异常是：某台机器QPS不高但CPU跑满，或者QPS突然翻倍且错误率同步上升，这两种情况才是真正的故障信号，判断标准是QPS与资源消耗、错误率三者是否匹配。
问：如何区分是业务高峰导致的正常高QPS，还是代码死循环导致的异常高QPS？
对比同时间的平均响应时间,正常业务高峰伴随高QPS时，RT（响应时间）通常保持稳定或略有上升，但死循环或资源竞争导致的请求堆积，会出现RT呈指数级恶化，你可以在监控面板上把QPS曲线和RT曲线叠加，如果两条线同步上升且RT斜率更大，基本可以判定为代码逻辑问题，需要立刻抓线程栈分析，而不是单纯扩容就能解决。
图片来源于AI模型，如侵权请联系管理员。作者：酷小编，如若转载，请注明出处：https://www.kufanyun.com/ask/735455.html
