别再只会用top看CPU了！手把手教你用stress-ng在Linux上模拟真实业务压力

从玩具到武器：用stress-ng构建Linux压力测试的工业级方案

当我们需要验证服务器在高负载下的表现时，大多数人首先想到的是top命令——它确实能告诉我们CPU是否繁忙，但就像用体温计测量发动机温度一样，远远不够。真正的压力测试需要精确模拟生产环境中的各种极端场景：数据库查询风暴、内存泄漏导致的OOM、日志洪峰引发的I/O阻塞...这就是stress-ng的价值所在——它不仅是资源消耗工具，更是构建真实业务场景的瑞士军刀。

1. 压力测试的认知升级：从理论到实践

传统认知中，压力测试就是让CPU跑满、内存耗尽，这种简单粗暴的方式往往与真实业务场景相去甚远。想象一下电商大促时的服务器状态：不是所有CPU核心均匀满载，而是某些核心处理支付网关请求达到100%，其他核心可能只负载30%处理商品展示；内存也不是瞬间耗尽，而是随着用户会话增加缓慢攀升；磁盘I/O更是呈现脉冲式波动——这些复杂场景需要更精细的模拟工具。

stress-ng相比基础版stress的进化体现在三个维度：

1. 压力维度：支持超过60种压力源（CPU缓存争用、分支预测失误、内存总线饱和等）
2. 控制精度：可指定压力波形（阶梯增长、脉冲波动、随机扰动）
3. 监控指标：内置性能计数器采集（L1缓存命中率、TLB缺失等硬件级指标）

安装最新版stress-ng的推荐方式：

# Ubuntu/Debian sudo apt install stress-ng # CentOS/RHEL sudo yum install epel-release sudo yum install stress-ng # 编译安装（获取最新特性） wget https://kernel.ubuntu.com/~cking/tarballs/stress-ng/stress-ng-0.15.06.tar.xz tar -xvf stress-ng-0.15.06.tar.xz cd stress-ng-0.15.06 make && sudo make install

2. CPU压力模拟：超越简单的100%负载

真实业务中的CPU负载从来不是均匀分布的。以MySQL为例，连接风暴可能导致大量时间花费在系统调用上，而计算密集型查询又会造成浮点运算单元饱和。stress-ng的--cpu-method参数可以精确模拟这些场景：

模拟支付网关的突发负载场景：

# 突发性负载：每10秒产生持续2秒的100%负载 stress-ng --cpu 4 --cpu-method syscall --cpu-load-slice 2 --cpu-load-rise 10

配合perf工具观察硬件事件：

perf stat -e cycles,instructions,cache-misses,branch-misses stress-ng --cpu 4 --cpu-method correlate -t 1m

3. 内存压力测试：制造可控的"内存泄漏"

OOM（Out Of Memory）是生产环境中最棘手的故障之一。基础的内存测试往往只是简单分配大块内存，而真实的内存泄漏是渐进式的。stress-ng提供了多种内存压力模式：

• 渐进式分配（--vm-keep）：模拟内存泄漏的线性增长
• 随机访问（--vm-populate）：模拟缓存失效场景
• 混合压力（--vm-madvise）：触发内核内存回收机制

Redis集群内存增长模拟方案：

# 模拟每个实例每小时增长2GB内存，持续12小时 stress-ng --vm 16 --vm-bytes 2G --vm-stride 64 --vm-madvise willneed \ --vm-populate --timeout 12h --metrics-brief

关键参数解析：

• --vm-stride 64：每64字节进行一次内存访问，模拟真实缓存行
• --vm-madvise willneed：提示内核预取内存，模拟预热过程
• --metrics-brief：定期输出内存分配速率和缺页异常统计

监控建议组合：

watch -n 1 "grep -e MemAvailable -e Swap /proc/meminfo" vmstat 1 # 观察si/so（交换区换入换出）

4. 存储I/O风暴：不只是dd的替代品

磁盘I/O性能对数据库系统至关重要，但简单的dd测试只能反映顺序读写的最佳情况。实际业务中更多是随机读写、fsync刷盘、元数据操作等混合负载：

# 模拟MySQL的binlog写入模式 stress-ng --hdd 2 --hdd-bytes 1G --hdd-opts sync,dsync,fsync \ --hdd-write-size 16k --hdd-write-bytes 80% \ --timerfd --iostat 1

参数组合效果：

• sync,dsync,fsync：混合使用不同级别的持久化保证
• --hdd-write-size 16k：模拟InnoDB页大小
• --hdd-write-bytes 80%：保持磁盘80%空间占用
• --iostat 1：每秒输出I/O统计

更真实的Kafka日志目录压力测试：

mkdir -p /kafka/pressure/{data,index} stress-ng --hdd 4 --hdd-dir /kafka/pressure \ --hdd-opts direct,random,keep \ --hdd-write-size 4k-16k \ --hdd-delay-us 100-500 \ --temp-path /kafka/pressure

5. 复合场景：构建全链路压力测试

真正的业务压力从来不是孤立的。一个电商下单流程可能同时涉及：

• CPU计算（优惠券核销）
• 内存操作（库存扣减）
• 磁盘写入（订单落库）
• 网络通信（支付网关）

stress-ng的场景编排功能可以模拟这种复合负载：

# 模拟秒杀场景（持续30分钟） stress-ng --cpu 8 --cpu-method matrix \ --vm 4 --vm-bytes 8G --vm-populate \ --hdd 2 --hdd-bytes 20G \ --io 4 --timer 2 \ --timeout 30m --metrics \ --log-file ./stress.log

配套的监控方案应该包括：

# 系统级监控 sar -A 1 1800 > sar.log & # 进程级监控 pidstat -d -u -r -h 1 1800 > pidstat.log & # 内核事件跟踪 perf record -g -a -o perf.data sleep 1800

6. 结果分析与调优建议

压力测试的价值不在于制造崩溃，而在于发现问题后的优化。stress-ng的--metrics选项会输出丰富的性能计数器：

典型问题诊断模式：

1. CPU饱和度但利用率低

   • 检查perf stat中的stalled-cycles-frontend
   • 可能是内存带宽瓶颈，考虑NUMA优化

2. 内存充足但频繁OOM

   • 观察vmstat中的sr（内存扫描速率）
   • 调整vm.swappiness和透明大页配置

3. 磁盘IPS高但吞吐量低

   • 检查iostat中的avgqu-sz（队列长度）
   • 考虑调整调度器（deadlinevsnoop）

调优前后对比表示例：

记住，最好的压力测试工具也替代不了真实流量测试。在双11前，某电商团队发现虽然stress-ng模拟的CPU/内存负载都达标，但真实流量下网络中断处理成为瓶颈——这提醒我们：任何工具都有局限，关键是用对场景。