Linux性能压测需围绕业务场景，明确目标指标（如QPS、延迟、I/O瓶颈），分层使用工具（wrk/stress-ng/sysbench），执行基线→加压→观测→分析标准化流程，并通过拐点分析与perf/flame graph定位根因。
Linux 性能压测不是单纯跑满 CPU 或打爆网络，而是围绕业务场景，有目标、有基准、有对比地验证系统在高负载下的稳定性、响应能力与资源瓶颈。关键在于“测什么”和“怎么解读”，而非一味追求峰值数字。
明确压测目标与核心指标
压测前必须定义清楚：是测 Web 服务吞吐量（QPS/TPS）？API 平均延迟与 P95/P99？数据库连接池耗尽点？还是磁盘 I/O 成为瓶颈？不同目标对应不同监控维度：
- CPU：关注 user/sys/iowait，iowait 持续 >20% 往往暗示 I/O 等待严重
- 内存：看 free -h 中 available 值是否持续下降，swap 是否被触发（/proc/swaps 非空即风险）
- 磁盘：用 iostat -x 1 观察 %util（接近 100% 不代表满载，需结合 r_await/w_await 和 svctm 判断真实延迟）
- 网络：ss -s 查连接数，netstat -s 看丢包重传，iftop 或 nethogs 定位进程级流量
选择合适工具并分层施压
单点工具无法覆盖全链路，应按层级组合使用：
- 应用层：wrk（高并发 HTTP）、ab（简单 GET 测试）、locust（支持复杂用户行为脚本）
- 系统层：stress-ng（模拟 CPU/内存/IO/磁盘压力）、fio（精准控制块设备读写模式、队列深度、IOPS）
- 数据库层：sysbench（MySQL/PostgreSQL 标准化压测）、pgbench（专用于 PostgreSQL）
建议先用 stress-ng 摸清单机极限（如 4 核机器能否稳定承受 300% CPU 负载），再用 wrk 或 sysbench 模拟真实请求路径，避免“假瓶颈”干扰判断。
执行标准化流程：基线 → 加压 → 观察 → 分析
跳过基线直接压测等于无锚点航行。标准流程如下：
- 基线采集：空载下运行 5 分钟，记录 top、vmstat 1、iostat -x 1 的典型值，作为健康参照
- 阶梯加压：从 20% 预估负载开始，每次增加 20%，每档维持 2–3 分钟，观察指标突变点（如延迟陡升、错误率跳变）
- 稳态观测：在目标负载下持续运行 10–15 分钟，重点抓取 /proc/ 目录下进程级数据（如 /proc/PID/status、/proc/PID/io）
- 故障注入：在高负载时手动 kill -STOP 某个 worker 进程，观察系统自愈能力与降级表现（非必须但强推）
结果分析不只看峰值，更要看拐点与异常模式
一份有效压测报告必须回答三个问题：
- 系统在哪个负载档位出现性能拐点？（例如 QPS 从 1200→1300 时平均延迟从 80ms 跳到 320ms）
- 拐点前后，哪个资源指标率先越界？（如 iowait 从 5% 突增至 65%，而 CPU user 仍仅 40%）
- 是否存在隐蔽异常？（如 dmesg 出现 “TCP: time wait bucket table overflow”，或 journalctl 报 “oom-killer invoked”）
用 perf record -g -p PID + perf report 可定位热点函数；用 flame graph 可视化调用栈耗时分布——这些比 top 数字更有诊断价值。
