压测关键在于明确测什么、怎么比、比什么，需用同一指标、负载和环境做ab测试；不同调优方向对应不同核心指标：cpu看cs/%sy/r，内存看page-fault/swap，磁盘看clat_p99，网络看吞吐与抖动。
直接跑对比测试，关键不是“用了什么工具”，而是“测什么、怎么比、比什么”。
压测不是炫技，是量化验证调优是否真的起效。
调优前后的收益，必须用同一套指标、同一套负载、同一套环境来对照。否则数字再好看，也没法说服自己或团队。
明确要验证的调优方向
不同调优目标对应不同压测维度，不能一上来就全量压：
-
CPU类调优（如内核调度器参数、进程优先级、cgroup限制）→ 重点看
CPU利用率分布、运行队列长度(r)、上下文切换(cs)、%sy占比 -
内存类调优（如vm.swappiness、透明大页、OOM策略）→ 关注
page-fault频率、swap-in/out速率、slab分配延迟、memtester稳定性结果 -
磁盘IO类调优（如I/O调度器、RAID缓存策略、ext4挂载选项）→ 看
fio的latency p99、iostat的await/avgrq-sz、iowait占比，而非只盯IOPS -
网络类调优（如net.core.somaxconn、tcp_tw_reuse、RSS队列绑定）→ 测
netperf的TCP_STREAM吞吐、UDP_RR延迟抖动、ss -s的retransmit rate
示例：你刚把
deadline调度器换成mq-deadline，又调了nr_requests=1024。那fio测试就不能只跑一次“randread 4k”，而要固定队列深度（如--iodepth=32）、固定运行时长（--time-based --runtime=60），并记录每次clat_percentile（完成延迟分位值），尤其关注p99和p99.9。
控制变量，做干净的AB测试
-
环境一致：同一台机器（或同型号、同固件版本的机器），重启后清空pagecache/dentries/inodes（
echo 3 > /proc/sys/vm/drop_caches），关闭无关服务（systemctl isolate multi-user.target） -
负载一致：用相同工具、相同参数、相同数据集（fio用同一
--filename，sysbench用同一--file-total-size） -
监控同步：压测同时采集
vmstat 1、sar -u -r -n DEV 1、pidstat -t 1，保存为时间戳文件，便于对齐分析 - 多次取稳态：每组测试至少跑3轮，丢弃首尾各1轮（预热和冷却影响），取中间轮次的中位数作为有效值
注意：不要用
stress --cpu 8 --timeout 60s这种“糊脸式”压测比调优效果。它只能告诉你“能不能撑住”，不能告诉你“为什么撑得更好”。要用能反映业务真实压力模式的工具——比如数据库调优就该用sysbench oltp_read_write，而不是stress --vm。
选对工具，抓准核心指标
| 调优类型 | 推荐工具 | 必看指标（调优前后对比） |
|---|---|---|
| CPU调度/计算 |
sysbench cpu 或 unixbench
|
events/sec、top中%sy变化、vmstat的cs和r值 |
| 内存带宽/延迟 |
mlc（Intel）或 mbw（ARM） |
STREAM Copy/Scale/Transpose带宽（GB/s）、mlc --latency_matrix结果 |
| 磁盘随机读写 |
fio（配--rw=randread --bs=4k --iodepth=16） |
clat_p99（微秒）、iops、read: io_bytes与runtime比值 |
| 网络吞吐/延迟 |
netperf -t TCP_STREAM + ping -c 100
|
Throughput（Mbits/sec）、ping的stddev（抖动） |
| 混合负载稳定性 |
stress + fio + netperf组合 |
uptime三分钟负载走势、dmesg | grep -i "out of memory\|hard lockup"是否新增 |
小技巧：
fio加--output-format=json输出结构化结果，用jq快速提取关键字段比对；sysbench加--report-interval=5可观察性能随时间的变化趋势，判断是否出现热节流或内存碎片恶化。
解读收益，不止看数字升降
- 提升10% IOPS但p99延迟翻倍？ → 实际体验更差，调优失败
-
%sy从35%降到12%，但QPS没变？ → 说明之前内核开销高，现在资源更高效，为后续扩容留出余量 -
load average从8.2降到4.1，而CPU idle从15%升到45%？ → 确实释放了瓶颈，但需确认是否因降频或限频导致（查cpupower frequency-info） -
fio延迟曲线从毛刺状变平滑？ → 可能解决了IO调度抖动或NVMe队列争抢问题，比单纯看平均值更有价值
真正有效的调优收益，往往体现在「稳定性提升」、「长尾延迟下降」、「资源利用率更均衡」上，而不只是峰值数字上涨。
不复杂但容易忽略。
