简介本资源是Linux系统管理员与运维开发人员必备的stress压力测试工具源码包专用于CPU与内存极限负载模拟、系统稳定性验证及性能调优实践。资源包含完整构建所需的32个文件涵盖核心源码stress.c、自动化构建脚本configure、Makefile.am/in、文档体系README、NEWS、stress.texi、stress.1、stress.html、许可证COPYING及辅助工具install-sh、missing、depcomp等全面支持从编译安装到本地化部署的全流程。压缩包仅199KB轻量精简适配主流Linux发行版。目前已有1036人学习下载读者可直接获取可编译的原始源码、标准化构建环境配置、多格式技术文档texi源码生成的info/html手册以及完整的版本管理与测试校验脚本check_version_return_code等为深入理解工具原理、定制化改造或集成至CI/CD压测流程提供坚实基础。1. stress Linux加压测试工具不是“跑个命令就完事”而是精准复现CPU/内存/IO瓶颈的黑匣子探针你有没有遇到过这样的场景线上服务突然响应变慢监控显示CPU使用率只有65%但top里却看不到明显吃资源的进程或者容器频繁OOM被杀可free -h显示内存还有2G空闲又或者磁盘IO等待时间飙升到200msiostat却说util才30%——这些反直觉现象背后往往不是监控不准而是负载特征没被真实激发出来。stress就是干这个的它不模拟业务逻辑而是用最底层、最暴力的方式把Linux内核调度器、内存管理子系统、块设备队列、文件系统缓存机制全逼到临界点让你看清系统在高压力下的真实行为边界。它不是压测平台而是诊断型压力探针——适合运维排查资源争抢、SRE验证弹性扩缩阈值、嵌入式工程师测试散热极限、甚至安全研究员复现内存耗尽类DoS条件。别被“stress”这名字骗了它既不stress测试人员也不stress业务代码它只stress你的Linux内核和硬件。如果你还在用dd if/dev/zero of/tmp/test bs1G count10来“测IO”那真该换上stress了——后者能同时压CPU、内存、磁盘、网络四路还能控制每路的强度、持续时间和混合比例这才是现代Linux系统级压测的起点。2. 从零部署stress源码编译与包管理安装的实操选择与版本陷阱2.1 包管理器安装快但有坑Ubuntu/Debian/CentOS/RHEL各走各的路绝大多数Linux发行版都自带stress包但版本差异极大且默认仓库常滞后。Ubuntu 22.04默认装的是stress 1.0.42017年发布而最新稳定版已是1.3.02023年发布新版本修复了ARM64下CPU绑定失效、--hdd选项在XFS文件系统上的写入校验绕过等关键问题。所以第一步必须确认版本# 查看当前安装版本及来源 stress --version dpkg -l | grep stress # Ubuntu/Debian rpm -qa | grep stress # CentOS/RHEL提示如果输出是stress 1.0.4或更低强烈建议不要直接用。旧版在多核NUMA节点调度、cgroup v2兼容性、以及--vm-bytes参数解析上存在已知缺陷会导致压力不均或根本无法触发预期负载。Ubuntu/Debian用户推荐用apt安装最新版需启用universe源sudo apt update sudo apt install stress-ng注意这里装的是stress-ng而非stress——这是原作者Colin Ian King维护的增强版功能全面覆盖原版且持续更新。stress-ng已成事实标准本文后续所有操作均基于stress-ng 0.14.082024年主流版本。CentOS/RHEL 8用户应启用EPEL源后安装sudo dnf install epel-release -y sudo dnf install stress-ng -yRHEL 7用户因EPEL 7已停止维护必须源码编译见2.2节。2.2 源码编译绕过包管理器枷锁掌控每一个编译开关当包管理器无法提供新版或你需要定制编译选项如禁用OpenMP以减少线程竞争干扰、启用debug符号用于gdb调试源码编译是唯一可靠路径。stress-ng源码托管在GitHub但切勿直接git clone主分支——master常含未合入的实验性补丁稳定性不如release tag。# 下载并解压稳定版源码以0.14.08为例 wget https://github.com/colin-i-king/stress-ng/releases/download/0.14.08/stress-ng-0.14.08.tar.xz tar -xf stress-ng-0.14.08.tar.xz cd stress-ng-0.14.08 # 配置编译选项--disable-openmp避免多线程调度干扰--enable-debug生成调试符号 ./configure --prefix/usr/local --disable-openmp --enable-debug # 编译-j$(nproc)加速但内存不足时建议-j2 make -j$(nproc) # 安装需root权限 sudo make install # 验证安装路径与版本 sudo /usr/local/bin/stress-ng --version编译后stress-ng二进制位于/usr/local/bin/比系统默认/usr/bin/stress-ng优先级高PATH顺序决定。可通过which stress-ng确认生效路径。若需卸载执行sudo make uninstall即可干净无残留。2.3 验证安装完整性三个命令揪出90%的环境问题安装完成后别急着压测先运行三行命令排除基础环境故障# 1. 检查是否支持所有stress-ng子测试尤其关注cpu, vm, io, hdd stress-ng --class cpu --show # 2. 测试最小单元能否运行1秒CPU压力应无报错 stress-ng --cpu 1 --timeout 1s --verbose # 3. 检查系统限制是否阻碍压力生成重点关注memlock和nofile ulimit -l # 应为unlimited或65536否则vm测试会失败 ulimit -n # 应65536否则hdd测试创建大量文件句柄时崩溃注意若ulimit -l显示数值如64说明系统对内存锁定有限制。需临时提升sudo ulimit -l unlimited或永久修改/etc/security/limits.conf中* soft memlock unlimited。这是stress-ng最常踩的坑——不是工具不行是系统拦住了。3. 核心压测场景落地CPU/内存/IO/磁盘四路压力的参数精调与效果验证3.1 CPU压力不止是“占满100%”而是精准控制核数、频率、指令类型单纯stress-ng --cpu 4会让4个进程各占一个CPU核心但这只是最粗粒度。真实业务压力往往是非均匀分布比如Web服务主要消耗整数运算科学计算依赖浮点向量加密服务则密集使用AES-NI指令。stress-ng通过--cpu-method精细控制# 场景1模拟Web服务整数运算为主避免浮点干扰 stress-ng --cpu 2 --cpu-method int8 --timeout 30s --metrics-brief # 场景2模拟AI推理高强度浮点SIMD stress-ng --cpu 1 --cpu-method matrixprod --timeout 30s --metrics-brief # 场景3模拟加密服务AES指令压测 stress-ng --cpu 1 --cpu-method cryptomgr --timeout 30s --metrics-brief--metrics-brief输出关键指标bogo ops/sec每秒伪操作数反映实际计算吞吐、CPU%进程级占用、MHz估算CPU频率。重点看bogo ops/sec——若该值远低于同配置机器说明CPU被降频或存在微架构瓶颈如Intel TSX事务冲突。参数说明--cpu-method可选值超30种常用包括int88位整数、matrixprod矩阵乘法、cryptomgr加密算法、bitops位运算。避免用all它会轮询所有方法导致负载特征混乱。3.2 内存压力区分page cache、anonymous memory与swap thrashing内存压测最容易翻车——stress-ng --vm 2看似简单但默认行为是分配匿名内存anonymous pages这会直接触发OOM Killer。而真实业务更多是page cache污染如数据库缓存、文件服务预读。stress-ng用--vm-keep和--vm-populate控制内存类型# 场景1模拟数据库缓存分配并锁定page cache不触发swap stress-ng --vm 2 --vm-keep --vm-hang 1 --timeout 60s # 场景2模拟内存泄漏持续分配匿名内存观察OOM Killer触发 stress-ng --vm 4 --vm-keep --vm-bytes 2G --timeout 120s # 场景3模拟swap thrashing强制交换验证swap性能瓶颈 stress-ng --vm 2 --vm-keep --vm-bytes 4G --swappiness 100 --timeout 60s--vm-keep确保内存不被释放--vm-hang 1让每个vm worker休眠1秒再重分配模拟缓存渐进填充--swappiness 100强制内核优先swap而非回收page cache。验证时紧盯cat /proc/meminfo | grep -E Swap|Mem和dmesg | tail——若出现Out of memory: Kill process即OOM触发成功。3.3 IO与磁盘压力绕过缓存、直写设备、控制队列深度dd和fio是IO压测主力但stress-ng的--io和--hdd能更贴近系统级瓶颈。关键区别在于--io压块设备队列bdev--hdd压文件系统层fs。生产环境必须两者结合# 场景1压块设备队列绕过page cache直写/dev/sda stress-ng --io 2 --io-ops 1000 --hdd 1 --hdd-opts direct --timeout 60s # 场景2压文件系统缓存模拟日志写入触发writeback stress-ng --hdd 4 --hdd-bytes 1G --hdd-opts sync --timeout 60s # 场景3混合IOCPU复现DB写入时CPU忙于日志刷盘 stress-ng --io 1 --hdd 1 --cpu 2 --timeout 60s--hdd-opts direct强制O_DIRECT跳过page cache--hdd-opts sync每次write后fsync模拟事务日志。验证指标iostat -x 1看%util设备利用率、await平均IO等待、svctm服务时间cat /proc/diskstats查# of reads/writes merged合并请求数——若merged值高说明IO调度器有效否则需调优/sys/block/sda/queue/scheduler。3.4 网络与文件描述符压力常被忽略的连接数与socket瓶颈虽标题未提网络但stress-ng的--sock和--file-ioctl能暴露TCP连接数、socket缓冲区、inode耗尽等隐性瓶颈# 场景1压TCP连接数模拟高并发短连接 stress-ng --sock 4 --sock-ops 10000 --timeout 60s # 场景2压inode与dentry缓存创建大量小文件 stress-ng --file-io 2 --file-ops 5000 --file-lseek 100 --timeout 60s # 场景3压socket缓冲区发送大数据包触发丢包 stress-ng --sock 1 --sock-tcp --sock-ops 1000 --sock-port 8000 --timeout 30s验证ss -s看total连接数、inuse已用df -i查inode使用率cat /proc/net/sockstat看sockets: used和TCP: inuse。若sockets: used接近net.core.somaxconn默认128则需调大该值。4. 避坑指南stress-ng压测中90%人踩过的5个血泪坑4.1 现象stress-ng --cpu 4只占2个核心且top显示CPU%总和不到200%原因Linux内核的CFS调度器对短时burst型负载有“公平性补偿”机制。stress-ng默认--cpu工作模式是快速分配/释放CPU时间片导致调度器误判为“轻量级任务”主动降频或迁移至空闲核。这不是bug是设计使然。解决强制绑定CPU核心并延长单次计算周期stress-ng --cpu 4 --cpu-bind 0-3 --cpu-method matrixprod --cpu-ops 1000000--cpu-bind 0-3将4个worker分别绑到CPU0~3--cpu-ops 1000000让每个worker连续执行100万次矩阵乘形成稳定长时负载。此时htop可见4核均达100%。4.2 现象stress-ng --vm 2 --vm-bytes 4G报错failed to allocate memory: Cannot allocate memory原因--vm-bytes指定的是每个worker分配的内存大小非总量。--vm 2启动2个worker每个分4G共需8G但系统剩余内存不足或ulimit -l限制太低。解决先查可用内存与限制free -h ulimit -l若ulimit -l为64则最大锁定内存仅64KB。临时解除sudo ulimit -l unlimited stress-ng --vm 2 --vm-bytes 2G --vm-keep --timeout 60s永久方案编辑/etc/security/limits.conf添加* soft memlock unlimited。4.3 现象stress-ng --hdd 1 --hdd-bytes 10G执行极慢iostat显示%util仅10%原因默认--hdd使用O_SYNC每次写入都等待磁盘物理落盘但现代SSD有写缓存O_SYNC实际被内核优化为异步导致压力不真实。更糟的是若文件系统是ext4且启用了journalO_SYNC会双重落盘。解决强制直写绕过缓存stress-ng --hdd 1 --hdd-bytes 10G --hdd-opts direct,asyncdirect启用O_DIRECTasync禁用同步等待。此时iostat -x 1的await值会真实反映磁盘延迟。4.4 现象压测中系统卡死SSH无法连接但console仍可输入原因--io或--hdd压力过大导致块设备队列深度溢出内核IO调度器死锁。常见于机械硬盘或低端NVMe/sys/block/sda/queue/nr_requests默认值128过小。解决压测前调大队列深度echo 512 | sudo tee /sys/block/sda/queue/nr_requests stress-ng --io 2 --io-ops 2000 --timeout 120s压测后恢复echo 128 | sudo tee /sys/block/sda/queue/nr_requests。此操作需root权限且仅对当前session有效。4.5 现象stress-ng --sock 4启动后netstat -an | grep :8000无监听端口但ss -tuln显示端口被占原因--sock默认使用AF_UNIX本地socket不走TCP/IP协议栈故netstat不可见。ss因底层调用不同能捕获。解决明确指定TCP协议stress-ng --sock 4 --sock-tcp --sock-port 8000 --timeout 60s此时netstat -tuln | grep :8000和ss -tuln | grep :8000均可看到监听。--sock-tcp是必须显式声明的参数。5. 进阶技巧用stress-ng做自动化瓶颈定位与压测报告生成5.1 自动化瓶颈定位三步脚本揪出CPU/内存/IO谁是短板手动跑多次stress-ng效率低下。我写了一个auto-stress.sh脚本自动按顺序施加CPU→内存→IO压力并记录各阶段系统指标拐点#!/bin/bash # auto-stress.sh自动识别系统瓶颈 LOGFILEstress_report_$(date %s).log echo Stress Test Report $(date) $LOGFILE # Step1: CPU压力基线 echo CPU Test (2 cores, 30s) $LOGFILE stress-ng --cpu 2 --cpu-method int8 --timeout 30s --metrics-brief 21 $LOGFILE echo CPU load avg: $(uptime | awk {print $10,$11,$12}) $LOGFILE # Step2: 内存压力page cache污染 echo Memory Test (2G page cache, 60s) $LOGFILE stress-ng --vm 2 --vm-keep --vm-bytes 1G --timeout 60s --metrics-brief 21 $LOGFILE echo Memory pressure: $(free -h | awk NR2{print $3 / $2 ( $3/$2*100 %)}) $LOGFILE # Step3: IO压力直写磁盘 echo IO Test (direct write, 60s) $LOGFILE stress-ng --io 1 --io-ops 1000 --timeout 60s --metrics-brief 21 $LOGFILE echo IO await: $(iostat -x 1 2 | tail -1 | awk {print $10}) $LOGFILE echo Report saved to $LOGFILE运行后脚本会生成带时间戳的日志关键信息包括CPU计算吞吐bogo ops/sec、内存占用率、IO平均等待时间await。若某阶段await突增至50ms以上而CPU和内存指标正常则IO是瓶颈若free显示可用内存500M且dmesg有OOM日志则内存是瓶颈。5.2 压测报告生成用--metrics-json导出结构化数据供Grafana分析stress-ng内置JSON输出可直接对接监控系统# 生成JSON格式压测报告 stress-ng --cpu 4 --vm 2 --io 1 --timeout 120s --metrics-json report.json # 解析关键指标用jq cat report.json | jq .metrics[] | select(.typecpu) | {name:.name, bogo_ops:.bogo_ops, cpu_percent:.cpu_percent} cat report.json | jq .metrics[] | select(.typevm) | {name:.name, vm_bytes:.vm_bytes, pgpgin:.pgpgin}report.json包含每个worker的详细指标bogo_ops计算吞吐、cpu_percentCPU占用、pgpgin/pgpgout页入/页出次数、io_bytesIO字节数。将此JSON喂给Prometheus Pushgateway即可在Grafana中绘制压测过程曲线对比不同配置下的性能衰减点。5.3 生产环境安全压测用cgroups隔离压力避免殃及池鱼在Kubernetes或Docker环境中绝不能让stress-ng无约束运行。必须用cgroups限制其资源# 创建cgroup并设限CPU 2核内存2GIO权重50 sudo cgcreate -g cpu,memory,blkio:/stress-test echo 200000 /sys/fs/cgroup/cpu/stress-test/cpu.cfs_quota_us echo 100000 /sys/fs/cgroup/cpu/stress-test/cpu.cfs_period_us echo 2147483648 /sys/fs/cgroup/memory/stress-test/memory.limit_in_bytes echo 8:0 50 /sys/fs/cgroup/blkio/stress-test/blkio.weight # 在cgroup中运行stress-ng sudo cgexec -g cpu,memory,blkio:/stress-test \ stress-ng --cpu 2 --vm 1 --io 1 --timeout 300s这样即使stress-ng失控也不会拖垮宿主机。cgroups v2用户需改用systemd-runsystemd-run --scope -p CPUQuota200% -p MemoryLimit2G \ stress-ng --cpu 2 --vm 1 --io 1 --timeout 300s我习惯在压测前先跑stress-ng --dry-run它会预检所有参数合法性并输出预计资源消耗相当于压测前的“后悔药”。真正上线压测时永远用--timeout加保险绝不依赖CtrlC——因为卡死时键盘可能已无响应。希望帮到你。本文还有配套的精品资源点击获取 Linux系统级压测：用stress-ng精准复现CPU内存IO瓶颈
简介本资源是Linux系统管理员与运维开发人员必备的stress压力测试工具源码包专用于CPU与内存极限负载模拟、系统稳定性验证及性能调优实践。资源包含完整构建所需的32个文件涵盖核心源码stress.c、自动化构建脚本configure、Makefile.am/in、文档体系README、NEWS、stress.texi、stress.1、stress.html、许可证COPYING及辅助工具install-sh、missing、depcomp等全面支持从编译安装到本地化部署的全流程。压缩包仅199KB轻量精简适配主流Linux发行版。目前已有1036人学习下载读者可直接获取可编译的原始源码、标准化构建环境配置、多格式技术文档texi源码生成的info/html手册以及完整的版本管理与测试校验脚本check_version_return_code等为深入理解工具原理、定制化改造或集成至CI/CD压测流程提供坚实基础。1. stress Linux加压测试工具不是“跑个命令就完事”而是精准复现CPU/内存/IO瓶颈的黑匣子探针你有没有遇到过这样的场景线上服务突然响应变慢监控显示CPU使用率只有65%但top里却看不到明显吃资源的进程或者容器频繁OOM被杀可free -h显示内存还有2G空闲又或者磁盘IO等待时间飙升到200msiostat却说util才30%——这些反直觉现象背后往往不是监控不准而是负载特征没被真实激发出来。stress就是干这个的它不模拟业务逻辑而是用最底层、最暴力的方式把Linux内核调度器、内存管理子系统、块设备队列、文件系统缓存机制全逼到临界点让你看清系统在高压力下的真实行为边界。它不是压测平台而是诊断型压力探针——适合运维排查资源争抢、SRE验证弹性扩缩阈值、嵌入式工程师测试散热极限、甚至安全研究员复现内存耗尽类DoS条件。别被“stress”这名字骗了它既不stress测试人员也不stress业务代码它只stress你的Linux内核和硬件。如果你还在用dd if/dev/zero of/tmp/test bs1G count10来“测IO”那真该换上stress了——后者能同时压CPU、内存、磁盘、网络四路还能控制每路的强度、持续时间和混合比例这才是现代Linux系统级压测的起点。2. 从零部署stress源码编译与包管理安装的实操选择与版本陷阱2.1 包管理器安装快但有坑Ubuntu/Debian/CentOS/RHEL各走各的路绝大多数Linux发行版都自带stress包但版本差异极大且默认仓库常滞后。Ubuntu 22.04默认装的是stress 1.0.42017年发布而最新稳定版已是1.3.02023年发布新版本修复了ARM64下CPU绑定失效、--hdd选项在XFS文件系统上的写入校验绕过等关键问题。所以第一步必须确认版本# 查看当前安装版本及来源 stress --version dpkg -l | grep stress # Ubuntu/Debian rpm -qa | grep stress # CentOS/RHEL提示如果输出是stress 1.0.4或更低强烈建议不要直接用。旧版在多核NUMA节点调度、cgroup v2兼容性、以及--vm-bytes参数解析上存在已知缺陷会导致压力不均或根本无法触发预期负载。Ubuntu/Debian用户推荐用apt安装最新版需启用universe源sudo apt update sudo apt install stress-ng注意这里装的是stress-ng而非stress——这是原作者Colin Ian King维护的增强版功能全面覆盖原版且持续更新。stress-ng已成事实标准本文后续所有操作均基于stress-ng 0.14.082024年主流版本。CentOS/RHEL 8用户应启用EPEL源后安装sudo dnf install epel-release -y sudo dnf install stress-ng -yRHEL 7用户因EPEL 7已停止维护必须源码编译见2.2节。2.2 源码编译绕过包管理器枷锁掌控每一个编译开关当包管理器无法提供新版或你需要定制编译选项如禁用OpenMP以减少线程竞争干扰、启用debug符号用于gdb调试源码编译是唯一可靠路径。stress-ng源码托管在GitHub但切勿直接git clone主分支——master常含未合入的实验性补丁稳定性不如release tag。# 下载并解压稳定版源码以0.14.08为例 wget https://github.com/colin-i-king/stress-ng/releases/download/0.14.08/stress-ng-0.14.08.tar.xz tar -xf stress-ng-0.14.08.tar.xz cd stress-ng-0.14.08 # 配置编译选项--disable-openmp避免多线程调度干扰--enable-debug生成调试符号 ./configure --prefix/usr/local --disable-openmp --enable-debug # 编译-j$(nproc)加速但内存不足时建议-j2 make -j$(nproc) # 安装需root权限 sudo make install # 验证安装路径与版本 sudo /usr/local/bin/stress-ng --version编译后stress-ng二进制位于/usr/local/bin/比系统默认/usr/bin/stress-ng优先级高PATH顺序决定。可通过which stress-ng确认生效路径。若需卸载执行sudo make uninstall即可干净无残留。2.3 验证安装完整性三个命令揪出90%的环境问题安装完成后别急着压测先运行三行命令排除基础环境故障# 1. 检查是否支持所有stress-ng子测试尤其关注cpu, vm, io, hdd stress-ng --class cpu --show # 2. 测试最小单元能否运行1秒CPU压力应无报错 stress-ng --cpu 1 --timeout 1s --verbose # 3. 检查系统限制是否阻碍压力生成重点关注memlock和nofile ulimit -l # 应为unlimited或65536否则vm测试会失败 ulimit -n # 应65536否则hdd测试创建大量文件句柄时崩溃注意若ulimit -l显示数值如64说明系统对内存锁定有限制。需临时提升sudo ulimit -l unlimited或永久修改/etc/security/limits.conf中* soft memlock unlimited。这是stress-ng最常踩的坑——不是工具不行是系统拦住了。3. 核心压测场景落地CPU/内存/IO/磁盘四路压力的参数精调与效果验证3.1 CPU压力不止是“占满100%”而是精准控制核数、频率、指令类型单纯stress-ng --cpu 4会让4个进程各占一个CPU核心但这只是最粗粒度。真实业务压力往往是非均匀分布比如Web服务主要消耗整数运算科学计算依赖浮点向量加密服务则密集使用AES-NI指令。stress-ng通过--cpu-method精细控制# 场景1模拟Web服务整数运算为主避免浮点干扰 stress-ng --cpu 2 --cpu-method int8 --timeout 30s --metrics-brief # 场景2模拟AI推理高强度浮点SIMD stress-ng --cpu 1 --cpu-method matrixprod --timeout 30s --metrics-brief # 场景3模拟加密服务AES指令压测 stress-ng --cpu 1 --cpu-method cryptomgr --timeout 30s --metrics-brief--metrics-brief输出关键指标bogo ops/sec每秒伪操作数反映实际计算吞吐、CPU%进程级占用、MHz估算CPU频率。重点看bogo ops/sec——若该值远低于同配置机器说明CPU被降频或存在微架构瓶颈如Intel TSX事务冲突。参数说明--cpu-method可选值超30种常用包括int88位整数、matrixprod矩阵乘法、cryptomgr加密算法、bitops位运算。避免用all它会轮询所有方法导致负载特征混乱。3.2 内存压力区分page cache、anonymous memory与swap thrashing内存压测最容易翻车——stress-ng --vm 2看似简单但默认行为是分配匿名内存anonymous pages这会直接触发OOM Killer。而真实业务更多是page cache污染如数据库缓存、文件服务预读。stress-ng用--vm-keep和--vm-populate控制内存类型# 场景1模拟数据库缓存分配并锁定page cache不触发swap stress-ng --vm 2 --vm-keep --vm-hang 1 --timeout 60s # 场景2模拟内存泄漏持续分配匿名内存观察OOM Killer触发 stress-ng --vm 4 --vm-keep --vm-bytes 2G --timeout 120s # 场景3模拟swap thrashing强制交换验证swap性能瓶颈 stress-ng --vm 2 --vm-keep --vm-bytes 4G --swappiness 100 --timeout 60s--vm-keep确保内存不被释放--vm-hang 1让每个vm worker休眠1秒再重分配模拟缓存渐进填充--swappiness 100强制内核优先swap而非回收page cache。验证时紧盯cat /proc/meminfo | grep -E Swap|Mem和dmesg | tail——若出现Out of memory: Kill process即OOM触发成功。3.3 IO与磁盘压力绕过缓存、直写设备、控制队列深度dd和fio是IO压测主力但stress-ng的--io和--hdd能更贴近系统级瓶颈。关键区别在于--io压块设备队列bdev--hdd压文件系统层fs。生产环境必须两者结合# 场景1压块设备队列绕过page cache直写/dev/sda stress-ng --io 2 --io-ops 1000 --hdd 1 --hdd-opts direct --timeout 60s # 场景2压文件系统缓存模拟日志写入触发writeback stress-ng --hdd 4 --hdd-bytes 1G --hdd-opts sync --timeout 60s # 场景3混合IOCPU复现DB写入时CPU忙于日志刷盘 stress-ng --io 1 --hdd 1 --cpu 2 --timeout 60s--hdd-opts direct强制O_DIRECT跳过page cache--hdd-opts sync每次write后fsync模拟事务日志。验证指标iostat -x 1看%util设备利用率、await平均IO等待、svctm服务时间cat /proc/diskstats查# of reads/writes merged合并请求数——若merged值高说明IO调度器有效否则需调优/sys/block/sda/queue/scheduler。3.4 网络与文件描述符压力常被忽略的连接数与socket瓶颈虽标题未提网络但stress-ng的--sock和--file-ioctl能暴露TCP连接数、socket缓冲区、inode耗尽等隐性瓶颈# 场景1压TCP连接数模拟高并发短连接 stress-ng --sock 4 --sock-ops 10000 --timeout 60s # 场景2压inode与dentry缓存创建大量小文件 stress-ng --file-io 2 --file-ops 5000 --file-lseek 100 --timeout 60s # 场景3压socket缓冲区发送大数据包触发丢包 stress-ng --sock 1 --sock-tcp --sock-ops 1000 --sock-port 8000 --timeout 30s验证ss -s看total连接数、inuse已用df -i查inode使用率cat /proc/net/sockstat看sockets: used和TCP: inuse。若sockets: used接近net.core.somaxconn默认128则需调大该值。4. 避坑指南stress-ng压测中90%人踩过的5个血泪坑4.1 现象stress-ng --cpu 4只占2个核心且top显示CPU%总和不到200%原因Linux内核的CFS调度器对短时burst型负载有“公平性补偿”机制。stress-ng默认--cpu工作模式是快速分配/释放CPU时间片导致调度器误判为“轻量级任务”主动降频或迁移至空闲核。这不是bug是设计使然。解决强制绑定CPU核心并延长单次计算周期stress-ng --cpu 4 --cpu-bind 0-3 --cpu-method matrixprod --cpu-ops 1000000--cpu-bind 0-3将4个worker分别绑到CPU0~3--cpu-ops 1000000让每个worker连续执行100万次矩阵乘形成稳定长时负载。此时htop可见4核均达100%。4.2 现象stress-ng --vm 2 --vm-bytes 4G报错failed to allocate memory: Cannot allocate memory原因--vm-bytes指定的是每个worker分配的内存大小非总量。--vm 2启动2个worker每个分4G共需8G但系统剩余内存不足或ulimit -l限制太低。解决先查可用内存与限制free -h ulimit -l若ulimit -l为64则最大锁定内存仅64KB。临时解除sudo ulimit -l unlimited stress-ng --vm 2 --vm-bytes 2G --vm-keep --timeout 60s永久方案编辑/etc/security/limits.conf添加* soft memlock unlimited。4.3 现象stress-ng --hdd 1 --hdd-bytes 10G执行极慢iostat显示%util仅10%原因默认--hdd使用O_SYNC每次写入都等待磁盘物理落盘但现代SSD有写缓存O_SYNC实际被内核优化为异步导致压力不真实。更糟的是若文件系统是ext4且启用了journalO_SYNC会双重落盘。解决强制直写绕过缓存stress-ng --hdd 1 --hdd-bytes 10G --hdd-opts direct,asyncdirect启用O_DIRECTasync禁用同步等待。此时iostat -x 1的await值会真实反映磁盘延迟。4.4 现象压测中系统卡死SSH无法连接但console仍可输入原因--io或--hdd压力过大导致块设备队列深度溢出内核IO调度器死锁。常见于机械硬盘或低端NVMe/sys/block/sda/queue/nr_requests默认值128过小。解决压测前调大队列深度echo 512 | sudo tee /sys/block/sda/queue/nr_requests stress-ng --io 2 --io-ops 2000 --timeout 120s压测后恢复echo 128 | sudo tee /sys/block/sda/queue/nr_requests。此操作需root权限且仅对当前session有效。4.5 现象stress-ng --sock 4启动后netstat -an | grep :8000无监听端口但ss -tuln显示端口被占原因--sock默认使用AF_UNIX本地socket不走TCP/IP协议栈故netstat不可见。ss因底层调用不同能捕获。解决明确指定TCP协议stress-ng --sock 4 --sock-tcp --sock-port 8000 --timeout 60s此时netstat -tuln | grep :8000和ss -tuln | grep :8000均可看到监听。--sock-tcp是必须显式声明的参数。5. 进阶技巧用stress-ng做自动化瓶颈定位与压测报告生成5.1 自动化瓶颈定位三步脚本揪出CPU/内存/IO谁是短板手动跑多次stress-ng效率低下。我写了一个auto-stress.sh脚本自动按顺序施加CPU→内存→IO压力并记录各阶段系统指标拐点#!/bin/bash # auto-stress.sh自动识别系统瓶颈 LOGFILEstress_report_$(date %s).log echo Stress Test Report $(date) $LOGFILE # Step1: CPU压力基线 echo CPU Test (2 cores, 30s) $LOGFILE stress-ng --cpu 2 --cpu-method int8 --timeout 30s --metrics-brief 21 $LOGFILE echo CPU load avg: $(uptime | awk {print $10,$11,$12}) $LOGFILE # Step2: 内存压力page cache污染 echo Memory Test (2G page cache, 60s) $LOGFILE stress-ng --vm 2 --vm-keep --vm-bytes 1G --timeout 60s --metrics-brief 21 $LOGFILE echo Memory pressure: $(free -h | awk NR2{print $3 / $2 ( $3/$2*100 %)}) $LOGFILE # Step3: IO压力直写磁盘 echo IO Test (direct write, 60s) $LOGFILE stress-ng --io 1 --io-ops 1000 --timeout 60s --metrics-brief 21 $LOGFILE echo IO await: $(iostat -x 1 2 | tail -1 | awk {print $10}) $LOGFILE echo Report saved to $LOGFILE运行后脚本会生成带时间戳的日志关键信息包括CPU计算吞吐bogo ops/sec、内存占用率、IO平均等待时间await。若某阶段await突增至50ms以上而CPU和内存指标正常则IO是瓶颈若free显示可用内存500M且dmesg有OOM日志则内存是瓶颈。5.2 压测报告生成用--metrics-json导出结构化数据供Grafana分析stress-ng内置JSON输出可直接对接监控系统# 生成JSON格式压测报告 stress-ng --cpu 4 --vm 2 --io 1 --timeout 120s --metrics-json report.json # 解析关键指标用jq cat report.json | jq .metrics[] | select(.typecpu) | {name:.name, bogo_ops:.bogo_ops, cpu_percent:.cpu_percent} cat report.json | jq .metrics[] | select(.typevm) | {name:.name, vm_bytes:.vm_bytes, pgpgin:.pgpgin}report.json包含每个worker的详细指标bogo_ops计算吞吐、cpu_percentCPU占用、pgpgin/pgpgout页入/页出次数、io_bytesIO字节数。将此JSON喂给Prometheus Pushgateway即可在Grafana中绘制压测过程曲线对比不同配置下的性能衰减点。5.3 生产环境安全压测用cgroups隔离压力避免殃及池鱼在Kubernetes或Docker环境中绝不能让stress-ng无约束运行。必须用cgroups限制其资源# 创建cgroup并设限CPU 2核内存2GIO权重50 sudo cgcreate -g cpu,memory,blkio:/stress-test echo 200000 /sys/fs/cgroup/cpu/stress-test/cpu.cfs_quota_us echo 100000 /sys/fs/cgroup/cpu/stress-test/cpu.cfs_period_us echo 2147483648 /sys/fs/cgroup/memory/stress-test/memory.limit_in_bytes echo 8:0 50 /sys/fs/cgroup/blkio/stress-test/blkio.weight # 在cgroup中运行stress-ng sudo cgexec -g cpu,memory,blkio:/stress-test \ stress-ng --cpu 2 --vm 1 --io 1 --timeout 300s这样即使stress-ng失控也不会拖垮宿主机。cgroups v2用户需改用systemd-runsystemd-run --scope -p CPUQuota200% -p MemoryLimit2G \ stress-ng --cpu 2 --vm 1 --io 1 --timeout 300s我习惯在压测前先跑stress-ng --dry-run它会预检所有参数合法性并输出预计资源消耗相当于压测前的“后悔药”。真正上线压测时永远用--timeout加保险绝不依赖CtrlC——因为卡死时键盘可能已无响应。希望帮到你。本文还有配套的精品资源点击获取