1. 从“压力测试”到“压力制造”为什么我们需要stress-ng在服务器运维、嵌入式开发或者性能调优的日常里我们经常会遇到一些“灵魂拷问”这台新采购的服务器它的CPU满载时功耗和温度曲线是怎样的我们写的这个内存管理算法在极端的内存压力下会不会崩溃系统在I/O和计算密集型任务并发时调度器表现如何这些问题光靠理论推算或者轻量级的测试往往难以触及真实场景的边界。你需要一个能“可控地制造混乱”的工具把系统推到极限观察它在压力下的真实表现。这就是stress-ng诞生的初衷也是它名字里“ng”Next Generation的含义——它不仅仅是施加压力更是下一代、更全面、更精准的压力测试工具。你可以把它理解为一个系统级的“压力健身房”。普通的stress工具可能只让你做做俯卧撑CPU计算或者深蹲内存分配而stress-ng则提供了一整套完整的健身方案从有氧CPU运算到无氧内存压力从爆发力缓存冲刷到耐力磁盘I/O甚至还有组合器械多种压力源并发。它的设计目标非常明确通过模拟各种极端工作负载来暴露硬件、内核、驱动乃至应用程序的潜在缺陷、性能瓶颈和稳定性问题。我第一次深入使用stress-ng是在一次线上数据库主机的容量评估项目中。当时我们需要验证在CPU和内存同时接近饱和的情况下数据库的响应延迟和事务成功率。简单的脚本和基准测试工具很难精确地、可重复地制造出我们想要的混合压力场景。而stress-ng凭借其丰富的“压力源”stressors和精细的参数控制让我们能够像调配化学试剂一样精确地“合成”出目标压力环境最终帮助我们定位到了一个在高内存带宽占用时CPU调度延迟增大的内核参数问题。自那以后它就成了我性能测试工具箱里的常备利器。2. stress-ng的核心架构与压力源全景图理解stress-ng首先要理解它的核心设计思想模块化和可扩展。它不是一个单一功能的程序而是一个由众多独立“压力源”组成的框架。每个压力源都是一个独立的模块负责产生一种特定类型的系统负载。2.1 压力源分类你的系统能承受多少种“折磨”stress-ng的压力源大致可以分为以下几类这几乎涵盖了计算机系统所有可能承受压力的子系统CPU类这是最常用的。不仅仅是让CPU占用率100%它还可以细分。cpu经典的浮点、整数混合计算让CPU核心持续忙碌。matrix执行矩阵运算对CPU的浮点单元和缓存进行压力测试。crypt执行加密解密操作如AES, SHA测试CPU的加密指令集加速性能。cpu-cache专门针对CPU缓存进行压力测试通过特定的内存访问模式来填充和冲刷缓存。内存类测试内存子系统、总线和内存控制器的稳定性。vm虚拟内存压力测试。它通过mmap分配内存然后以各种方式如写入、读取、移动来操作这些内存区域可以模拟内存碎片、交换swap活动等场景。malloc频繁地分配和释放堆内存测试内存分配器如glibc的malloc的效率和碎片化情况。stack通过递归或大量局部变量消耗栈空间测试栈溢出边界。I/O类给磁盘和文件系统上强度。io基本的同步I/O操作如read/write。hdd模拟硬盘工作负载包括顺序和随机读写。sync调用sync,fsync,fdatasync等系统调用强制将缓存数据刷入磁盘测试I/O提交和完成的延迟。进程与调度类考验操作系统的进程管理能力。fork疯狂地创建fork和终止子进程测试进程创建开销和进程表大小限制。sem信号量操作测试进程间同步原语的性能。sched通过调整进程的调度策略如SCHED_FIFO, SCHED_RR和优先级来测试调度器的公平性和实时性。网络类需要指定网络接口或端口。sock创建大量的TCP/UDP套接字进行连接、绑定、监听等操作测试网络协议栈和文件描述符限制。udp/tcp模拟简单的UDP/TCP流量。注意这类测试通常需要配合对端不如专业网络压测工具强大但用于制造本地协议栈压力足够。设备与内核类一些更底层的测试。dev通过ioctl调用“折磨”设备。sysinfo频繁调用sysinfo,getpid,gettimeofday等系统调用测试系统调用的开销。timer创建大量的定时器测试内核的定时器子系统。2.2 工作模式如何组织这些压力源stress-ng提供了两种主要的工作模式让你可以灵活地设计测试场景顺序模式使用--sequential或-s参数。所有指定的压力源会依次运行每个运行指定的时间。这适合用来单独评估每个子系统在压力下的独立表现。并行模式默认模式也是更常用的模式。使用--parallel或-p参数或默认不指定就是并行。所有指定的压力源会同时启动并发地给系统施加压力。这模拟了真实世界中多种负载同时出现的复杂场景对于发现资源竞争、锁争用、调度器瓶颈等问题至关重要。例如一个模拟Web服务器压力的测试可能同时并行运行cpu处理逻辑、vm内存缓存、io日志写入和sock处理连接等多个压力源。3. 从安装到实战手把手构建你的第一个压力测试理论说了这么多不如动手跑一遍。我们从一个最简单的单压力源测试开始逐步深入到复杂的混合场景。3.1 安装与验证在大多数Linux发行版上安装stress-ng都非常简单。# 在 Ubuntu/Debian 上 sudo apt update sudo apt install stress-ng # 在 CentOS/RHEL/Fedora 上 (需要EPEL仓库) sudo yum install epel-release sudo yum install stress-ng # 或者使用 dnf sudo dnf install stress-ng # 在 Alpine Linux 上 sudo apk add stress-ng安装完成后首先查看一下版本和帮助确认工具可用并了解其丰富的功能。stress-ng --version stress-ng --help | less帮助信息会列出所有可用的压力源这是你探索功能的“地图”。3.2 基础命令与参数解析stress-ng的命令行参数虽然繁多但结构清晰。掌握几个核心参数就能应对大部分场景。--cpu N启动N个worker进程来执行CPU压力测试。--io N启动N个worker进行I/O压力测试。--vm N启动N个worker进行内存压力测试通常配合--vm-bytes使用。--vm-bytes M指定每个vmworker分配多少内存例如--vm-bytes 1G。这是关键参数不指定的话默认分配256MB可能达不到你的测试目标。--timeout T指定整个测试运行的时长例如--timeout 60s表示运行60秒。支持s秒、m分、h时单位。--metrics-brief在测试结束时输出一个简洁的性能摘要包括每秒操作数BogoOps。这个“BogoOps”是stress-ng自定义的一个性能单位用于横向比较同一压力源在不同系统上的相对性能其绝对值意义不大但对比变化很有价值。--verbose显示更详细的运行时信息方便调试。注意stress-ng的许多参数都有短格式和长格式例如-c对应--cpu-t对应--timeout。在脚本中建议使用长格式以提高可读性在命令行交互时可以使用短格式节省时间。3.3 实战案例一CPU满载与温度监控假设我们想测试一台服务器在CPU持续100%负载下运行10分钟的温升和功耗情况。# 启动与CPU核心数相同的worker运行10分钟 stress-ng --cpu $(nproc) --timeout 10m --metrics-brief命令拆解与原理$(nproc)这是一个shell命令替换会自动获取当前系统的CPU核心线程数。让worker数等于核心数可以确保所有CPU逻辑核心都被充分利用。--timeout 10m整个测试持续10分钟。--metrics-brief结束后我们会看到类似下面的输出其中bogo ops/s反映了在这个系统上执行该压力源的相对速度。stress-ng: info: [12345] dispatching hogs: 8 cpu stress-ng: info: [12345] successful run completed in 600.12s stress-ng: info: [12345] stressor bogo ops real time usr time sys time bogo ops/s bogo ops/s stress-ng: info: [12345] (secs) (secs) (secs) (real time) (usrsys time) stress-ng: info: [12345] cpu 12345678 600.12 4800.98 0.05 20568.12 2570.99此时你需要打开另一个终端窗口使用监控工具观察系统状态CPU使用率与频率htop或top可以直观看到所有核心100%占用。watch -n 1 \cat /proc/cpuinfo | grep MHz\可以观察CPU频率是否因过热而降频Throttling。温度监控安装lm-sensors包运行sensors命令查看CPU核心温度。温度会逐渐上升并最终稳定在一个值这个值就是该散热条件下的满载稳态温度。功耗估算对于服务器可以通过IPMI工具如ipmitool sensor读取功耗传感器数据。对于桌面平台有些主板也支持。实操心得跑这种长时间满载测试前务必确保散热系统正常特别是灰尘较多的老旧服务器。我曾遇到过因为散热风扇积灰导致测试中途CPU过热降频性能曲线出现断崖式下跌从而误判为CPU性能问题实际上是散热故障。观察bogo ops/s在测试期间是否稳定。如果出现持续下降可能预示着温度升高导致降频或者系统其他部分如供电出现了瓶颈。3.4 实战案例二内存压力测试与OOM触发内存测试比CPU测试风险稍高因为它可能导致系统因内存耗尽而触发OOMOut-Of-Memory Killer杀掉其他进程。我们可以在控制内存总量的情况下进行测试。# 测试一分配总计4GB内存例如4个worker每个1GB进行频繁的内存移动操作持续2分钟。 stress-ng --vm 4 --vm-bytes 1G --vm-method move --timeout 120s # 测试二更激进的方式分配接近系统可用内存的总量测试系统换页swap行为。 # 首先查看可用内存包括buffer/cache free -h # 假设可用内存大约为8G我们可以分配7.5G进行测试 stress-ng --vm 1 --vm-bytes 7.5G --vm-method all --timeout 60s参数解析--vm-method指定内存操作的方法。move是移动内存块的内容all则会循环使用多种方法写入、读取、移动等。使用all能产生更复杂的内存访问模式。第二个测试命令中--vm 1只启动一个worker但分配了7.5G内存。这比启动多个小内存worker更能模拟单个内存消耗型应用如大型数据库的场景。监控与观察运行vmstat 1命令关注siswap in和soswap out两列。如果它们从0开始持续增长说明物理内存不足系统正在使用交换分区这会带来巨大的性能开销。运行dstat -m可以查看内存使用情况。如果系统启用了OOM Killer并且你的stress-ng进程被杀死你会看到stress-ng进程突然消失并且dmesg或/var/log/kern.log中会有OOM相关的日志。重要警告在生产环境或运行重要服务的系统中进行内存压力测试必须极其谨慎。最好在测试机、容器或虚拟机上操作。明确设置--timeout避免测试失控。使用--vm-keep参数可以在测试结束后保留分配的内存不释放用于测试长时间内存占用的影响但这风险更高。3.5 实战案例三混合压力场景模拟真实的应用负载很少是单一的。一个典型的后端服务可能同时需要CPU计算、内存缓存和磁盘I/O。我们可以用stress-ng来合成这种负载。# 模拟一个负载2个CPU核心计算1个worker进行512MB内存压力2个worker进行磁盘I/O所有并发运行3分钟。 stress-ng --cpu 2 --vm 1 --vm-bytes 512M --io 2 --timeout 180s --metrics-brief进阶组合使用--class参数。stress-ng预定义了一些负载类别class可以一次性启动一组相关的压力源。# 启动所有“cpu”类别的压力源 stress-ng --class cpu ?--all 2 --timeout 60s # 启动所有“io”类别的压力源 stress-ng --class io ?--all 2 --timeout 60s这里的?需要替换为正确的参数。实际上--class通常与--parallel和指定worker数一起用但更常见的还是手动指定需要的压力源组合这样控制粒度更细。4. 高级用法、调优与结果解读当你掌握了基础命令后一些高级功能和调优技巧能让你的测试更具针对性和洞察力。4.1 精准控制绑定CPU与优先级在多核NUMA非统一内存访问架构的服务器上将压力进程绑定到特定CPU核心或NUMA节点可以测试内存本地访问与远程访问的性能差异。# 将cpu压力worker绑定到0,1号核心将vm压力worker绑定到2,3号核心 stress-ng --cpu 2 --cpu-affinity 0,1 --vm 2 --vm-bytes 1G --vm-affinity 2,3 --timeout 60s你也可以提高压力测试进程的调度优先级让它更容易获得CPU时间片从而制造更极端的竞争环境慎用可能导致系统无响应。sudo stress-ng --cpu 4 --ioprio 0 --timeout 30s--ioprio用于设置I/O优先级但需要配合--io等I/O类压力源。对于CPU调度优先级更底层的方式是在启动stress-ng前使用nice或chrt命令。4.2 结果解读与性能分析--metrics-brief输出的bogo ops/s是一个相对值。它的正确用法是对比横向对比在同一台机器上调整系统参数如CPU调速器从ondemand改为performance或调整内核参数vm.swappiness运行相同的stress-ng命令比较bogo ops/s的变化可以量化参数调整的效果。纵向对比在不同的机器如新旧服务器上运行相同的测试比较bogo ops/s可以粗略评估不同硬件平台的相对计算能力。但绝不能认为bogo ops/s越高系统性能就一定越好。它只代表stress-ng这个特定负载的执行速度。真正的性能评估必须结合应用层的基准测试如数据库TPS、Web请求QPS和系统层的关键指标如vmstat中的r可运行进程数、us/sy用户/系统CPU时间占比iostat中的%util设备利用率和await平均I/O等待时间。4.3 常见问题与避坑指南测试无效果或负载上不去检查worker数量对于CPU测试如果worker数远少于CPU核心数自然无法让所有核心满载。使用$(nproc)或手动指定足够数量。检查压力源类型有些I/O测试io可能因为缓存page cache而显得很快负载不高。可以尝试使用--hdd或结合sync来强制刷盘增加I/O压力。系统限制检查用户进程数限制ulimit -u、内存锁限制ulimit -l等。特别是vm测试分配大量内存时可能需要调整限制或使用sudo。测试导致系统卡死或无响应这是正常现象尤其是进行极端的内存I/O混合测试时。一定要通过--timeout设置安全运行时间。对于远程服务器最好在screen或tmux会话中运行测试防止SSH断开导致进程失控。如果测试命令本身已导致Shell无响应你可以尝试从另一个终端或通过IPMI等带外管理工具登录用pkill stress-ng来终止测试。如何模拟更真实的磁盘I/O压力单纯的--io可能主要操作的是内存中的缓存。为了模拟真实磁盘写入可以# 创建一个临时文件并在此文件上进行I/O压力测试 dd if/dev/zero of/tmp/testfile bs1M count1024 stress-ng --hdd 1 --hdd-bytes 1G --hdd-opts direct,wr-rnd --timeout 60s使用--hdd-opts direct可以进行直接I/O绕过页面缓存wr-rnd表示随机写这会给磁盘带来更大的压力。注意直接I/O对硬盘损耗较大测试需谨慎。stress-ng与稳定性测试烤机stress-ng是硬件稳定性测试如“烤机”的常用工具。一个全面的稳定性测试命令可能包含所有主要压力源stress-ng --all 0 --timeout 24h--all 0会为每个检测到的压力源启动一个worker。运行数小时甚至数天如果系统不出现蓝屏、死机、重启或硬件错误说明系统在极端复杂负载下的稳定性较好。这通常用于新机组装或超频后的验证。5. 在CI/CD与自动化测试中的集成实践stress-ng不仅是一个命令行工具也可以作为自动化测试流水线中的一个环节用于资源验证和回归测试。5.1 作为健康检查的一部分在交付一台新的虚拟机或容器镜像时可以加入一个简短的stress-ng测试确保基础计算单元功能正常。#!/bin/bash # 基础健康检查脚本 set -e # 遇到错误即退出 echo 开始基础压力健康检查... # 运行一个短时间的CPU和内存测试 if stress-ng --cpu 2 --vm 1 --vm-bytes 500M --timeout 30s --metrics-brief; then echo 健康检查通过CPU与内存压力测试正常。 else echo 健康检查失败压力测试出现错误。 exit 1 fi5.2 性能回归测试在软件版本迭代中如果担心新版本引入性能衰退可以在固定的硬件环境下将stress-ng作为系统层性能基准测试的一部分。#!/bin/bash # 性能回归测试脚本 VERSION$1 LOG_FILEperf_${VERSION}.log # 定义测试套件 TESTS( --cpu 4 --timeout 60s --vm 2 --vm-bytes 2G --vm-method all --timeout 60s --io 4 --timeout 60s ) echo 性能测试开始版本: $VERSION | tee -a $LOG_FILE for TEST in ${TESTS[]}; do echo 运行测试: stress-ng $TEST | tee -a $LOG_FILE stress-ng $TEST --metrics-brief 21 | grep bogo ops/s | tee -a $LOG_FILE done echo 性能测试结束。 | tee -a $LOG_FILE运行此脚本比较不同版本日志中的bogo ops/s如果某个子系统测试结果出现显著下降例如超过5%就需要引起警惕结合应用层测试进一步分析原因。5.3 容器资源限制验证在Docker或Kubernetes中我们经常为容器设置CPU和内存限制cpus,memory。stress-ng可以完美地验证这些限制是否生效。# 在Dockerfile中安装stress-ng FROM alpine:latest RUN apk add --no-cache stress-ng CMD [stress-ng, --cpu, 4, --vm, 2, --vm-bytes, 256M, --timeout, 30s, --metrics-brief]然后运行容器并设置限制docker run -it --cpus1.5 --memory512m my-stress-image观察输出stress-ng会启动4个CPU worker但由于容器被限制在1.5个CPU它们的总利用率不会超过150%。内存方面两个vmworker各尝试分配256M总计512M正好达到容器内存限制的上限。通过这种测试可以确认你的资源隔离配置是按预期工作的。在我参与的一个微服务项目中我们就曾利用这个方法来验证Kubernetes Pod的resources.limits配置是否正确成功发现了一个由于内存限制设置不当导致JVM应用堆大小计算错误的问题。stress-ng就像一把系统级的“压力扳手”力道可轻可重目标可精可广。从简单的CPU满载测试到复杂的混合负载模拟再到自动化流水线中的集成验证它都能提供可靠且可控的压力输入。关键在于理解每个压力源的含义清晰地定义你的测试目标是测极限是测稳定性还是验证配置然后像调配试剂一样组合使用它们。记住它制造压力而你负责观察和解读系统在压力下的反应这才是性能工程和稳定性保障的核心。