Linux下常用压测工具推荐系统性能测试方法-LINUX-PHP中文网

真正有效的系统性能测试必须分层选工具、带监控跑、看拐点而非峰值：cpu用stress或sysbench，内存用stress--vm或vmtouch，磁盘用fio，网络用iperf3/tc/wrk；需先采集基线，关注突变点，避免stress参数混用干扰，并同步底层监控定位真实瓶颈。

linux下常用压测工具推荐系统性能测试方法

直接说结论：别只用 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，这往往比应用层错误码更早暴露问题