从零到精通：使用stress-ng对Linux系统进行全方位压力测试
1. 认识stress-ng：你的Linux系统压力测试神器
第一次接触stress-ng是在三年前的一个深夜，当时我正在为公司的云服务器做上线前的最后测试。突然意识到：如果这台机器在业务高峰期扛不住压力怎么办？这时一位老运维扔给我一行命令："stress-ng --cpu 8 --io 4 --vm 2"，从此打开了系统稳定性测试的新世界。
stress-ng是stress工具的增强版，就像瑞士军刀一样集成了各种系统压力测试功能。它能模拟CPU高负载、内存吃紧、磁盘疯狂读写等极端场景，让我们提前发现系统的薄弱环节。与老版的stress相比，stress-ng支持更复杂的测试场景，比如同时测试多个子系统，还能模拟特定类型的计算任务。
在实际工作中，我发现stress-ng特别适合这些场景：
- 新服务器上线前的"烤机"测试
- 系统配置变更后的稳定性验证
- 模拟突发流量时的资源瓶颈定位
- 容器/K8s节点的资源限制测试
2. 从零开始安装stress-ng
2.1 准备编译环境
我建议直接从源码编译安装，这样可以获得最新版本的功能。在开始前，我们需要准备好构建工具链：
# Ubuntu/Debian系统 sudo apt update && sudo apt install -y build-essential # CentOS/RHEL系统 sudo yum groupinstall -y "Development Tools"遇到过一个小坑：在某些最小化安装的系统上，可能会缺少libaio等依赖库。这时可以补充安装：
sudo apt install -y libaio-dev libattr1-dev # Ubuntu sudo yum install -y libaio-devel libattr-devel # CentOS2.2 源码编译安装
我习惯将这类工具安装在/opt目录下，方便统一管理：
wget https://fossies.org/linux/privat/stress-ng-0.14.01.tar.gz tar -zxvf stress-ng-0.14.01.tar.gz cd stress-ng-0.14.01 make -j$(nproc) sudo make install安装完成后，验证下版本：
stress-ng --version如果看到版本号输出，恭喜你，工具链已经就绪。我建议把这个路径加入PATH环境变量：
echo 'export PATH=$PATH:/usr/local/bin' >> ~/.bashrc source ~/.bashrc3. 系统摸底：了解你的战场
在开始压力测试前，我们需要先摸清系统的硬件配置，就像医生要先了解病人的基本情况才能开药。
3.1 CPU信息侦查
lscpu | grep -E 'Model name|Socket|Core|Thread'这个命令会显示CPU型号、物理核数、逻辑线程数等关键信息。我曾经遇到过虚拟机的vCPU分配不足导致测试失真的情况，所以特别要注意：
- 物理CPU插槽数（Sockets）
- 每插槽核心数（Cores per socket）
- 每核心线程数（Threads per core）
3.2 内存容量检查
free -h重点关注"available"列，这才是系统实际可用的内存。有个经验值：压力测试时最好不要超过可用内存的90%，否则可能触发OOM killer。
3.3 磁盘性能基准
lsblk # 查看磁盘分区情况 df -h # 查看挂载点使用情况特别注意：
- /tmp目录的空间是否足够（某些测试会用到）
- 主要数据盘的I/O性能（可以用fio先做基准测试）
- 如果是SSD，注意预留足够的OP空间
4. CPU压力测试实战
4.1 基础CPU测试
最直接的测试方式是让所有CPU核心满载运行：
stress-ng --cpu $(nproc) --timeout 180s这里用了$(nproc)自动获取CPU核心数。测试时可以另开一个终端观察：
watch -n 1 'lscpu | grep "CPU MHz"'这会实时显示每个核心的频率变化，正常应该能看到频率飙升到最高睿频。
4.2 高级CPU测试技巧
stress-ng支持多种CPU压力算法：
stress-ng --cpu 4 --cpu-method all --timeout 120s这里的--cpu-method all会轮换使用各种计算算法：
- matrixprod 矩阵乘积
- fft 快速傅里叶变换
- sqrt 平方根运算
- ...
我曾经用这个方法发现过某款CPU在特定计算类型下会出现异常升温的情况。
4.3 温度监控要点
长时间CPU满载需要注意散热问题。推荐安装lm-sensors：
sudo apt install lm-sensors # Ubuntu sudo yum install lm_sensors # CentOS sudo sensors-detect --auto sensors测试时要密切监控温度变化，特别是：
- 温度上升曲线是否平稳
- 是否触发热节流（throttling）
- 风扇转速是否正常
5. 内存压力测试详解
5.1 基础内存测试
stress-ng --vm 4 --vm-bytes 80% -t 5m这个命令会启动4个worker，每个分配总内存80%的空间（自动计算），持续5分钟。我强烈建议使用百分比而非固定值，这样脚本在不同机器上都通用。
5.2 内存测试模式选择
stress-ng提供多种内存访问模式：
stress-ng --vm 2 --vm-bytes 2G --vm-method rowhammer可选模式包括：
- sequential 顺序访问
- random 随机访问
- rowhammer 模拟Rowhammer攻击
- ...
曾经用rowhammer模式在测试机上成功触发了ECC内存纠错，提前发现了内存条质量问题。
5.3 交换空间监控
当内存不足时，系统会使用swap空间。监控swap使用情况很重要：
watch -n 1 'free -h; swapon --show'如果发现swap使用量快速增长，可能意味着：
- 物理内存不足
- swappiness设置过高
- 内存泄漏（在长时间测试中）
6. 磁盘I/O压力测试
6.1 基础磁盘测试
stress-ng --hdd 2 --hdd-bytes 10G -t 10m这会创建两个worker，每个写入10GB临时文件。注意：
- 确保目标分区有足够空间（建议至少20%余量）
- 不要在系统关键分区（如/）上测试
- 测试文件默认存放在/tmp，可以用--temp-path指定其他位置
6.2 混合I/O模式
stress-ng --io 4 --iomix 2 --iomix-bytes 1G -t 5m--iomix选项会混合多种I/O操作：
- 同步/异步写入
- 文件元数据操作
- 随机/顺序读写
6.3 磁盘健康监控
在进行高强度I/O测试时，建议同时监控磁盘健康状态：
watch -n 5 'sudo smartctl -a /dev/sda | grep -i temperature' iostat -x 1 # 查看I/O等待和利用率特别警惕：
- I/O等待持续高于50%
- 磁盘温度异常升高
- 出现重分配扇区计数增长
7. 系统监控与结果分析
7.1 实时监控三板斧
测试时我习惯用这三个命令实时监控：
# CPU监控 htop # 内存监控 watch -n 1 'free -m' # 综合监控 dstat -cmdr --disk-util --top-cpu7.2 日志记录技巧
为了后续分析，建议将监控数据记录下来：
vmstat 1 60 > vmstat.log & iostat -x 1 60 > iostat.log & stress-ng --cpu 4 --timeout 60s7.3 常见问题诊断
根据多年经验，整理了几个典型问题现象：
| 现象 | 可能原因 | 验证方法 |
|---|---|---|
| CPU频率不升反降 | 温度过高触发降频 | sensors + turbostat |
| 内存测试OOM | overcommit设置过严 | cat /proc/sys/vm/overcommit_memory |
| 磁盘I/O卡顿 | 磁盘队列深度不足 | iostat -x 观察avgqu-sz |
8. 进阶：综合场景测试
8.1 模拟真实业务负载
stress-ng --cpu 4 --io 2 --vm 2 --vm-bytes 2G --hdd 1 --timeout 1h这种混合测试能更好地模拟真实业务场景。建议逐步增加负载，观察系统响应曲线。
8.2 长时间稳定性测试
对于关键业务服务器，我通常会进行24小时以上的耐力测试：
stress-ng --all 2 --timeout 24h注意：
- 使用nohup或tmux保持会话
- 设置合理的监控间隔（如每5分钟记录一次）
- 准备自动报警机制（如温度超过阈值自动停止）
8.3 容器环境测试
在Docker中测试需要注意资源限制：
docker run -it --rm --cpus=2 -m 2g ubuntu stress-ng --cpu 2 --vm 1 --vm-bytes 1G重点验证：
- Cgroup限制是否生效
- 容器内外的监控数据是否一致
- OOM Killer行为是否符合预期
记得第一次在生产环境使用stress-ng时，我意外发现了一批服务器的内存兼容性问题。从那时起，这就成了我的标准测试工具。建议把关键测试命令写成脚本，纳入你的运维工具库。测试不是为了证明系统会失败，而是为了了解它会在什么情况下失败——这样我们才能真正掌控自己的系统。