真正有效的系统性能测试必须分层选工具、带监控跑、看拐点而非峰值：CPU用stress或sysbench，内存用stress--vm或vmtouch，磁盘用fio，网络用iperf3/tc/wrk；需先采集基线，关注突变点，避免stress参数混用干扰，并同步底层监控定位真实瓶颈。
直接说结论：别只用 stress 跑满 CPU 就算压测完了——它只能暴露“能不能扛住”，但看不出“为什么扛不住”或“哪里先崩”。真正有效的系统性能测试，必须分层选工具、带监控跑、看拐点而非峰值。
怎么选压测工具：按目标场景而不是名气
工具不是越多越好，关键匹配你要验证的问题：
- CPU 计算瓶颈 → 优先用
stress --cpu N或sysbench cpu；前者轻量易上手，后者能控制线程数+指定计算类型（如 prime、fibonacci），更适合对比不同编译器或内核参数的影响 - 内存分配/释放压力 →
stress --vm N --vm-bytes 1G --vm-keep比单纯--vm更贴近真实泄漏场景；vmtouch则适合验证 page cache 行为，比如预热或驱逐特定目录 - 磁盘 I/O 瓶颈 →
fio是事实标准，stress --hdd只能模拟粗粒度写入；fio支持控制队列深度、IO 类型（randread/randwrite）、direct/ioengine，能复现数据库随机读写或日志刷盘模式 - 网络吞吐/延迟敏感 →
iperf3测带宽，tc配合ping/curl测弱网行为（如 100ms 延迟 + 2% 丢包），wrk才是测 HTTP 服务真实 QPS 的主力
为什么不能跳过基线：空载数据决定你是否在测“系统”还是“噪音”
没采集基线就开压，等于蒙眼开车。常见错误是看到 top 里 CPU 95% 就断言“CPU 瓶颈”，但可能只是压测机自身网卡中断占了 30% softirq。
- 基线至少要跑 5 分钟：
sar -u 1（CPU）、sar -r 1（内存）、iostat -x 1（磁盘）、ss -s（socket 统计） - 重点关注非零但稳定的值：比如
iostat中%util持续 15%，await在 2ms 左右，这说明磁盘空闲时也有后台活动（可能是 journal、logrotate） - 压测中突变点比绝对值重要：比如
vmstat的cs（上下文切换）从 1000/s 突增到 15000/s，大概率是锁竞争或频繁唤醒，不是 CPU 不够
组合压测时最容易踩的坑：参数混用不等于真实负载
stress --cpu 4 --vm 2 --io 2 --timeout 60 看似全面，实际可能掩盖关键问题：
- CPU 和内存进程互相干扰：sqrt() 运算触发大量 cache miss，同时 vm 进程又在刷 TLB，结果
perf stat -e cycles,instructions,cache-misses显示 IPC 降到 0.3，但这不是业务代码的问题，是 stress 自身的副作用 -
--io和--hdd完全不同：--io调sync()，基本不产生磁盘写入；--hdd才真写文件，但默认会清理临时文件，想保留用于iostat对比就得加--hdd-noclean - 超时时间不够长：60 秒可能刚过 GC 周期或 page reclaim 阶段，建议稳态观测至少 10 分钟，尤其对 Java/Go 等带运行时的程序
监控必须和压测同步：只看应用返回码等于没测
压测时开着 top 就收工？远远不够。真实瓶颈往往藏在更底层：
- CPU 高但 QPS 上不去 → 查
perf record -e sched:sched_stat_sleep -p $(pgrep -f your_app)看线程是不是长期 sleep，再结合/proc/PID/stack确认是否卡在锁或 syscall - iowait 高 → 先
iotop -o定位进程，再cat /proc/PID/io看 rchar/wchar，区分是读多还是写多；如果是写多，fio --name=randwrite --ioengine=libaio --rw=randwrite --bs=4k --size=1G --runtime=60单独复现 - 连接数上不去 →
ss -s看inuse和orphan，netstat -s | grep -i "listen\|overflow"查是否有 listen queue overflow，这往往比应用层错误码更早暴露问题
复杂点在于：同一组参数在不同内核版本、不同 CPU 微架构、甚至不同 BIOS 设置下，表现可能差异极大。最容易被忽略的是压测机自身资源隔离——如果和被测服务共用同一台物理机，stress 一开，宿主机调度器就开始抢资源，测出来的根本不是目标服务的真实能力。
