TG咨询服务器性能压测出现异常，先不要急着调整线程数或升级实例。相同接口在不同时间得到完全不同的结果，常见原因并不只有服务器本身，也可能来自压测脚本、客户端容量、缓存状态、数据库连接池或网络链路。更稳妥的做法是固定条件、保留证据，再按由外到内的顺序缩小范围。
第一步：确认异常是否真实存在
先把本次结果与基线放在同一张表中比较，至少记录请求模型、并发数、持续时间、响应状态码、平均延迟、P95延迟、错误率和服务器规格。若只看到平均响应时间，容易掩盖少量请求极慢的问题；若只看吞吐量，又可能忽略大量超时。
- 确认测试地址、端口、协议和请求参数没有变化，避免把预发布环境误当成生产配置。
- 确认压测机与目标服务器的时间一致。Linux 主机可检查 chrony 或 systemd-timesyncd 的同步状态，避免日志时间无法对应。
- 预热应用后再采集正式结果。首次请求可能包含类加载、连接建立、缓存填充或数据库执行计划准备，通常不适合直接与稳定阶段比较。
- 重复至少两轮相同负载。如果只有一轮异常，应优先检查网络、实例迁移、后台任务或压测机状态，而不是立即修改应用。
第二步：排除压测端和请求模型问题
检查客户端是否先到瓶颈
当压测机自身的CPU、文件描述符、出口带宽或临时端口不足时，服务端看到的请求量可能已经失真。可以在压测机上观察 ss -s、文件描述符使用量、网卡丢包和连接建立失败数；如果压测机负载接近上限，应增加压测节点或降低单节点并发，再比较结果。
还要检查压测脚本是否复用了连接、是否正确处理重定向和响应体，以及是否把失败请求自动重试。重试会放大真实流量，使错误率和吞吐量同时失真。对于登录、查询、提交等流程，应确认令牌、Cookie和请求顺序与真实业务一致，不能用单一静态请求代替完整场景。
核对负载曲线
突发并发、阶梯加压和稳定并发会得到不同结果。突发流量更容易触发连接队列和线程池耗尽；阶梯加压适合寻找拐点；稳定并发则适合观察内存增长和连接泄漏。压测脚本中的等待时间、请求比例、数据随机性也应固定，否则两次测试并非同一组条件。
第三步：沿网络链路定位延迟
把端到端耗时拆成 DNS、TCP连接、TLS握手、服务器处理和响应传输几部分。若只有首个请求变慢，可能是连接建立或TLS握手；若所有请求的服务端处理时间正常、总耗时却升高，应检查代理、负载均衡器、出口带宽或丢包。
在反向代理场景中，可对照 Nginx access log 中的 request_time 与 upstream_response_time：前者明显大于后者，问题多在客户端到代理或响应发送阶段；两者都升高，则继续看应用和下游依赖。若同一接口在内网正常、跨公网异常，还需分别测量链路，不能直接归因于应用代码。
第四步：观察应用、数据库和缓存
应用层重点看线程池、连接池、请求队列和超时日志。服务器性能压测中，CPU利用率不高并不代表没有瓶颈：线程可能在等待数据库连接，或者请求被锁竞争阻塞。以 PostgreSQL 为例，可查看活动会话、锁等待和慢查询；如果查询时间突然变长，应检查执行计划、索引命中情况以及测试数据量是否发生变化。
使用 Redis 等缓存时，要区分缓存命中和未命中两种路径。缓存刚清空后的首次访问可能集中打到数据库，形成“压测异常”；缓存全部命中又可能高估系统的持续处理能力。测试前应明确缓存状态，并分别记录两类结果。外部服务超时、消息队列积压或连接池耗尽，也会把下游问题表现为本接口延迟升高。
第五步：确认操作系统资源瓶颈
不要只看CPU平均值。应同时观察每核利用率、负载、上下文切换、内存回收、磁盘等待、网络错误和进程打开文件数。某一个CPU核心满载而总体利用率不高，可能是单线程锁或中断集中；内存使用平稳但延迟突然上升，可能与磁盘交换、垃圾回收或I/O队列有关。
| 异常现象 | 优先检查对象 | 常见判断 |
|---|---|---|
| 吞吐量上不去，CPU单核接近满载 | 线程模型、锁竞争、单线程事件循环 | 增加并发未必有效，应先定位热点 |
| P95突然升高，平均值变化不大 | 慢查询、队列等待、连接池和GC日志 | 少量长请求拉高尾延迟 |
| 错误集中为超时或连接失败 | 文件描述符、端口、队列、代理超时 | 先区分请求未到达还是处理超时 |
| 写入场景延迟持续升高 | 磁盘等待、数据库锁、日志和刷盘策略 | 读请求正常不代表写路径健康 |
一套可复用的收敛步骤
- 保存压测配置、应用版本、服务器规格和完整日志，建立可复现的基线。
- 用低并发请求确认功能正确，再逐级增加负载，记录首次出现延迟拐点的区间。
- 同时采集压测端、代理、应用、数据库和操作系统指标，统一时间窗口。
- 每次只改变一个变量，例如并发数、缓存状态或数据库连接池，避免多个改动互相掩盖。
- 修复后用相同脚本和相同数据重跑，并保留异常前后的差异。
常见问题
服务器CPU很低，为什么响应仍然很慢？
请求可能在等待数据库连接、锁、磁盘或外部服务。应查看线程状态、连接池等待时间和下游调用耗时，而不是只看总CPU。
平均延迟正常，P95却异常升高怎么办？
重点查少量慢请求，通常与队列堆积、慢查询、垃圾回收、网络重传或超时重试有关。应按时间段和状态码拆分数据。
重跑后结果恢复正常，是否可以忽略第一次异常？
不能直接忽略。先确认是否为冷缓存、实例初始化或后台任务；如果真实业务也可能遇到该状态，就应单独记录冷启动或缓存失效场景。
什么时候可以判断是服务器本身的问题？
当压测端容量充足、请求模型稳定，且代理和网络正常，同时应用进程或系统资源在异常时间窗口出现可对应的瓶颈，才适合把服务器或其运行环境列为主要嫌疑。
服务器性能压测的价值不在于得到一个孤立的最高并发数，而在于建立“负载变化—资源表现—用户延迟—错误类型”的对应关系。只要按输入、链路、应用和系统逐层核对，异常数据通常能够收敛到可验证的原因。
