运维说「服务器 OOM 了」「CPU 打满了」，需要压测配合排查——测试该做什么？

很多人第一反应是学命令：top、jstack、jmap……但测试往往没有服务器权限，这些命令多是开发/运维在执行。测试的核心价值不在执行命令，而在排查思维：怎么拆解问题、提供什么证据、如何配合定位。本文从测试视角讲排查思维，命令只作附录供有权限时参考。

速览：测试的排查思维

阶段 测试要做的 核心问题
现象确认 压测复现、记录指标 什么场景触发？能否稳定复现？
证据收集 并发曲线、响应时间、错误率、资源趋势 压测停止后内存/连接是否回落？
问题拆解 排除压测工具、排除场景、定位接口 是单接口还是全链路？
协作传递 复现步骤 + 数据 + 时间线 开发/运维需要什么信息才能定位？

思维主线：先搞清楚「是什么问题」，再配合「谁来解决」。测试负责把问题边界画清楚。

一、先搞清楚：测试在排查中的角色

性能排查是协作，不是单打独斗。测试的职责是复现问题、提供证据、缩小范围，而不是替代开发做代码级定位。

测试能做的：设计压测场景、控制并发与时长、记录 QPS/响应时间/错误率、观察 Grafana/APM 上的资源曲线、整理复现步骤。

测试做不了的：没有服务器权限时，无法执行 jstack、jmap 等命令；代码级根因定位属于开发。

所以：排查思维的核心是「我能提供什么信息，让开发/运维更快定位」，而不是「我会多少命令」。

二、资源本质：CPU、内存、IO（建立思维模型）

性能问题本质是资源不够用。理解三大资源，才能看懂监控、判断瓶颈、提出合理假设——即使不跑命令。

资源 本质 打满时的表现
CPU 计算能力 响应变慢、系统卡顿
内存 临时存储 持续上升、OOM、Swap 暴增
IO 磁盘/网络 等待时间长、数据库慢

互相影响：CPU 处理数据依赖内存，内存不足会从磁盘加载（IO 暴增），IO 慢则 CPU 干等。三者任一打满都会连锁反应。

测试要看的：Grafana/APM 上的 CPU、内存、磁盘 IO、网络 IO 曲线。不需要会命令，但要能判断「是哪个资源先出问题」。

三、按问题类型拆解：测试怎么想、怎么配合

3.1 OOM / 内存问题

思维：内存泄漏 vs 瞬时压力。关键区分——压测停止后，内存是否回落。

现象 可能原因 测试要提供的
压测停止后内存回落 瞬时压力大，属正常 并发数、持续时间、内存峰值
压测停止后内存不回落 内存泄漏，需开发定位 复现场景、内存增长曲线、是否可稳定复现
特定接口触发 OOM 该接口或依赖有问题 哪个接口、请求参数、并发数

要问自己的：是单接口还是混合场景？逐步加压到多少时出现？能否在 10 分钟内稳定复现？

3.2 CPU 高

思维：是压测导致的正常打满，还是低并发下就异常高？

现象 可能原因 测试要提供的
高并发下 CPU 100% 可能正常，看是否到瓶颈 并发数、QPS、响应时间曲线
低并发下 CPU 异常高 死循环、热点代码、锁竞争 多少并发时出现、哪个接口
压测停止后 CPU 不降 后台任务或泄漏 停止时间、CPU 回落时长

要问自己的：多少并发时 CPU 开始异常？是某个接口单独压测时出现，还是混合场景？

3.3 连接泄漏 / IO 慢

思维：连接数是否随压测持续增长且不回落？响应时间变慢是接口慢还是数据库慢？

现象 可能原因 测试要提供的
连接数持续增长不回落 连接泄漏 连接数曲线、压测停止后的变化
响应时间随并发线性变慢 IO 瓶颈或慢查询 响应时间 vs 并发曲线、慢接口列表

要问自己的：APM 上有没有慢 SQL、慢接口？是哪个接口拖垮整体？

四、压测配合的思维：可控复现，而非盲目打满

核心：压测的目的是帮助定位，不是证明系统能扛多少。设计压测时要带着问题去压——「我要帮开发缩小范围」。

4.1 压测设计思维

目的 怎么压 观察什么
复现 OOM 逐步加压，找到触发点 内存曲线、压测停止后是否回落
复现 CPU 高 单接口 vs 混合场景对比 多少并发时异常、哪个接口
复现连接泄漏 稳定压力持续 30 分钟 连接数是否持续增长、停止后是否回落
排除压测工具干扰 换工具或降并发重试 现象是否一致

要避免的：一上来就打满、不记录基线、不区分单接口/混合场景、压完没有数据留存。

4.2 证据收集清单

给开发/运维时，尽量带上：

  • 复现步骤：哪个接口、什么参数、多少并发、持续多久
  • 时间线：几点开始压、几点出问题、几点停止
  • 指标截图：Grafana/APM 上的 CPU、内存、响应时间、错误率曲线
  • 对比数据：正常基线 vs 异常时的差异

思维：开发需要的是「可复现 + 有数据」，不是「我们压过了」。

五、协作传递：测试要说什么

开发问「怎么复现的？」时，能清晰回答：

  • 场景：单接口压测还是混合？具体哪个接口？
  • 负载：并发数、持续时间、QPS
  • 现象：内存/CPU/连接数曲线，压测停止后是否回落
  • 排除：是否排除压测工具、网络、环境问题

开发问「有监控截图吗？」时，能提供 Grafana/APM 的曲线图。

思维：测试的价值在于把「模糊的问题」变成「可定位的边界」——开发不需要猜场景，直接按你的复现步骤就能抓到问题。

六、常见问题模式速查（思维对照）

问题模式 测试要判断的 给开发的关键信息
内存泄漏 压测停止后内存是否回落 复现场景 + 内存曲线
CPU 高 低并发是否就异常、哪个接口 并发数 + 接口 + 曲线
连接泄漏 连接数是否持续增长不回落 连接数曲线 + 压测时长
慢查询/IO 响应时间随并发如何变化 慢接口列表 + APM 截图

总结

测试的排查思维：复现问题、收集证据、缩小范围、清晰传递。核心不是会多少命令，而是能把模糊现象变成可定位的边界。

思维主线：现象确认 → 证据收集 → 问题拆解 → 协作传递。Grafana/APM 足够支撑大部分判断，命令是开发/运维的事。

附录：命令速查（供有权限时参考）

测试通常没有服务器权限，以下命令多为开发/运维执行。了解即可，便于看懂对方反馈。

问题类型 常用命令 用途
CPU 高 top -H -p <pid>、jstack <pid> 查线程、热点
OOM/内存 free -h、jmap -histo <pid> 查内存、对象
IO 瓶颈 iostat -x 1、iftop 查磁盘、网络
连接数 netstat -an、ss -s 查连接趋势

监控/压测工具：Grafana、Prometheus、APM（New Relic、Datadog）、JMeter、Locust。

相关文章