尧图网站建设 
简介Linux压力测试工具stress 1.0.1源码资源包面向系统管理员、运维工程师与嵌入式开发者用于模拟CPU、内存、线程/进程等负载评估系统在极限场景下的稳定性与性能表现。压缩包整体约199KB共32个文件以C源码、configure配置脚本、Makefile构建文件为主兼有texinfo文档、man手册及ChangeLog等说明材料目录沿用标准GNU工程结构便于编译、安装与二次开发。该工具支持通过命令行灵活指定负载类型与线程数量可模拟计算密集、内存紧张及高并发进程创建等场景。目前已有3031人学习下载适合需要验证服务器承载力、排查资源瓶颈或开展性能调优的工程师。借助该包可收获完整源码与配套文档既能直接用于压测环境搭建也能深入研读stress的核心实现为自行编写轻量级负载工具提供参考。linux压力测试工具stress实战从装库到拷机一条龙做Linux运维和系统性能验证的朋友一定绕不开一个场景新买的服务器到了要验证硬件稳不稳内核打了一个补丁要确认系统不会跑着跑着就崩部署容器之前要看看资源隔离到底靠不靠谱。这些场景都有一个共同的底子需求——给系统施加一个可控的压力然后在压力下观察它的表现。stress就是干这个的一个轻量、纯粹、用来给Linux系统制造负载的小工具我用它做过不少次拷机和稳定性验证这篇就来聊聊它的完整玩法。1. 工具选型与核心概念1.1 stress到底是个什么工具stress是Amos Waterland写的一个C语言小工具它的设计目标非常纯粹通过fork出大量子进程分别去消耗CPU、内存、磁盘I/O和资源分配能力从而让系统进入一种可量化、可控的高负载状态。说人话就是——你告诉它“给我压出8个满负荷CPU的负载”它就老老实实fork出8个进程每个进程拼命算数学题把CPU时间吃满。很多人会把stress和stress-ng搞混。stress-ng是它的加强版包含几百种压测方法功能更强但复杂度也高。而stress的特点是参数简单、行为直观、结果容易判断适合做快速验证和日常拷机。我个人的习惯是快速验证用stress深度专项压测用stress-ng或sysbench但日常工作中stress出现的频率其实更高因为它足够轻量装完即用不引入太多学习成本。1.2 为什么需要给系统制造压力很多人会有疑问我的服务已经在线上跑了为什么还要额外制造压力这里有个概念要分清线上跑业务是“实际负载”压测工具制造的是“人工负载”。实际负载是随机的、起伏的、不好控制的而人工负载是确定的、稳定的、可调节的。做稳定性验证时你不希望负载忽高忽低导致结果无法解释你希望CPU稳定在100%、内存稳定占用N个GB然后观察系统在这种极端情况下是否还能正常工作。stress的价值就在这里它把负载变成了一个有刻度的仪器让你能够在“系统扛不住之前”就掌握系统的边界在哪里。比如一台8核机器先压6个CPU看看是否稳定再压8个再压10个超卖观察不同负载级别下的系统行为。这种测试在硬件验收、性能基线采集、容器限制验证中都属于必备环节。1.3 适用场景梳理从我实际接触过的使用场景来看stress主要适合以下几种情况硬件拷机新装机或购买二手服务器后用CPU和内存压力验证硬件是否有隐性故障。内核与驱动验证打了补丁、升级了内核、更换了驱动需要在负载下确认系统不会panic或死锁。性能调优前后对比调整内核参数、CPU调频策略之前和之后用同样的压力对比系统表现。容器与虚拟化资源限制验证确认cgroup的CPU限制、内存限制是否真正生效。教学和技术测试演示系统负载、观察调度行为时stress是干净利落的负载制造工具。2. 安装部署与环境准备2.1 各主流发行版的安装方法stress的安装非常简单官方源里基本都有现成的包。以最常见的几个发行版为例# Debian / Ubuntu sudo apt-get install stress # CentOS / RHEL 7/8/9 sudo yum install stress # Fedora sudo dnf install stress # Arch Linux sudo pacman -S stress如果你用的是极其精简的发行版或者没有现成包也可以从源码编译安装。stress的源码包很小编译过程依赖也很少wget https://downloads.your.org/stress/stress-1.0.7.tar.gz tar -xzf stress-1.0.7.tar.gz cd stress-1.0.7 ./configure make sudo make install安装完成之后验证一下是否成功stress --version能输出版本号就说明OK了。我在编译安装时踩过一次坑某些精简系统上缺少make和gcc需要先用包管理器装好基础编译工具链再执行configure。2.2 压测前的系统状态确认在做压力测试之前有一件小事经常被忽略确认CPU调频策略。现在的CPU大多有自动调频功能空闲时降频省电负载高时自动升频。如果你不做任何设置压测过程中CPU频率可能忽高忽低测试结果的一致性会受影响。建议在压测前把CPU调到最大频率或性能模式观察一下当前频率运行状态# 查看当前CPU频率 cat /proc/cpuinfo | grep MHz # 使用cpupower工具设置性能模式需要root权限 cpupower frequency-set -g performance如果发行版没有cpupower命令也可以装linux-cpupowerDebian/Ubuntu或kernel-toolsCentOS包。当然如果你测试的目的恰恰是要验证调频策略本身的行为那就不需要这一步反而应该保持默认策略去压具体取决于你的目标。另外压测前还要确认系统负载基线是干净的。最好在一台没有业务的机器上做压测或者至少确认当前top显示的load average不高避免把别人业务的负载误算进你的测试结果里。3. 压测方案设计与核心参数3.1 CPU压测--cpu参数详解stress最常见的用法是CPU压测命令格式如下stress --cpu 8这会在当前终端前台fork出8个子进程每个进程执行一个计算平方根的死循环把CPU核心吃满。根据我的实测每个--cpu进程会跑在单核上8个进程就能吃满8个逻辑核心。机器有多少核心可以用nproc查看。这里有个决策点如果机器是超线程架构8核16线程要压满所有逻辑核心应该用--cpu 16还是只压8个物理核心这取决于你的目的。如果你想验证整机散热和供电是否扛得住那就压满16个线程让所有逻辑处理器都进入高负载状态如果你想模拟“每个物理核心承载一个典型业务进程”的场景压8个可能更贴近实际。CPU压测默认会一直跑下去直到你按CtrlC终止。实际操作中通常需要限制时长用--timeout参数# 压8个CPU核心持续60秒后自动退出 stress --cpu 8 --timeout 60s--timeout支持10s、1m、1h、1d这样的时间后缀也支持纯数字单位为秒。加上超时控制的最大好处是不用干等测试完自动退出适合写进脚本里循环执行。3.2 内存压测--vm参数详解内存压测用到--vm系列的参数# 启动4个内存压测进程每个分配512MB内存 stress --vm 4 --vm-bytes 512M每个--vm进程会调用malloc分配指定大小的内存然后循环写入数据确保内存页真实被触达。这里我补充一个容易被忽视的细节malloc分配出来的内存在没有写入之前只是虚拟内存不会占据实际的物理内存页。stress内部会通过写入操作对这些内存页进行实际触达这也是它压内存比较有效的原因。实际压测时内存总量要算清楚。比如机器有8GB可用内存你启动4个进程每个分配2GB总量就是8GB。如果分配总量超过实际可用内存系统会开始使用swap性能会骤降如果超过物理内存加swap的总量则可能触发OOM Killer某个进程被内核杀掉测出来的结果就不具备参考意义。还有--vm-hang参数值得说明。它会指示子进程在分配并写入内存后挂起一段时间而不是反复随机读写。比如stress --vm 2 --vm-bytes 1G --vm-hang 30两个进程各分配1GB内存并保持30秒不释放。这种模式适合测试“系统在内存长期以高占用率运行时是否稳定”贴近数据库缓存、JVM堆内存这类常驻内存场景。3.3 磁盘和I/O压测--io与--hdd磁盘I/O压测主要有两个参数--io和--hdd。# 启动4个I/O进程每个进程不断执行sync系统调用 stress --io 4--io的做法是不断fork新进程执行sync()把文件系统缓冲区刷入磁盘产生系统调用和I/O调度压力。不过说实话这种压测方式对现代SSD来说压力并不大它更多是压内核的I/O路径和调度器不是直接压磁盘带宽。想要更直接的磁盘写入压力用--hdd# 启动2个写盘进程每个向文件中写入1GB数据 stress --hdd 2 --hdd-bytes 1G--hdd进程会创建一个临时文件默认在/var/tmp目录下然后反复写数据进去。这个测试会真实产生磁盘写入流量可以用来验证磁盘的稳定性和散热。这里有一个我踩过的坑--hdd默认会在/var/tmp下生成临时文件对于容量小的根分区1GB甚至几GB的写入很容易把根分区磁盘占满。所以在跑--hdd之前一定先看看磁盘剩余空间同时建议用--hdd-bytes限制单次写入上限或者指定文件路径。3.4 组合压测模拟真实混合负载前面的参数都是单一维度的但生产环境的负载从来不会只消耗一种资源。stress允许同时指定多个维度一次压测模拟混合负载# 8个CPU进程 2个内存进程各1G 1个磁盘写入进程持续5分钟 stress --cpu 8 --vm 2 --vm-bytes 1G --hdd 1 --hdd-bytes 1G --timeout 5m这种组合压测更适合在真实服务器上做整体稳定性验证。比如你新部署了一个生产环境想确认在“CPU高负载、内存大量占用、磁盘持续写入”的场景下业务进程还能不能稳定响应这种混合压测就很有参考价值。我在实际做服务器验收时几乎都是用组合参数跑30分钟以上而不仅仅是单测一个维度。3.5 核心参数速查表参数作用常用搭配备注--cpu N启动N个CPU负载进程--timeout每个进程吃满一个逻辑核心--vm N启动N个内存负载进程--vm-bytes每个进程分配指定大小内存--vm-bytes SIZE指定每个内存进程分配的大小--vm N支持K/M/G后缀--vm-hang N内存分配后挂起N秒--vm模拟常驻内存负载--io N启动N个I/O进程--timeout不断执行sync系统调用--hdd N启动N个写盘进程--hdd-bytes真实产生磁盘写入流量--timeout TIME指定总运行时长所有参数支持s/m/h/d后缀--verbose显示详细压测日志任意配合调试使用4. 实操过程与数据观察4.1 一个完整的压测流程示例在真正压测之前我先做一次基线采集也就是不做任何压测时记录系统初始状态。这一步很重要因为后续判断异常都需要和基线对比uptime free -h df -hT /var/tmp mpstat -P ALL 1 3假设我现在拿到一台8核16G的服务器要做一次硬件稳定性验收压测方案分三步走第一步跑CPU压力10分钟确认所有逻辑核心都稳定在100%负载stress --cpu 16 --timeout 10m第二步跑内存压力按70%内存占用设计16G机器留出系统余量分配12G占用stress --vm 6 --vm-bytes 2G --timeout 10m第三步混合压测30分钟模拟真实业务的高负载场景stress --cpu 16 --vm 4 --vm-bytes 2G --hdd 4 --hdd-bytes 2G --timeout 30m三个步骤跑完如果没有出现进程被kill、系统死机、内核报错等现象基本可以认为这台机器的硬件和系统在合理的负载范围内是稳定的。4.2 压测过程中的数据观察方法压测启动后记住一个原则不要只盯着黑色终端等结果要开另一个终端去观察系统状态。我最常用的观察工具组合如下top/htop看整体CPU使用率、load average、内存占用判断压测进程是否达到预期负载。mpstat -P ALL 1逐核查看CPU使用率。这个非常关键能看出压力是否均匀分布在所有核心上如果只有部分核心为100%说明压测进程数量少了或者存在中断绑核等问题。free -h查看内存与swap使用情况。如果内存压测导致swap开始大量增长说明压测内存分配过量不是理想状态。iostat -x 1观察磁盘使用率、吞吐量和I/O等待时间配合--hdd压测使用。这里我举个例子。用stress --cpu 8压一台8核机器在另一个终端跑mpstat -P ALL 1正常情况下每个CPU的%usr都接近100%。但如果发现其中某个CPU的%usr只有50%左右可能就是stress进程被调度到了中断处理较多的CPU上或者系统本身有绑核配置。这种细节在高精度压测中值得排查。4.3 压测时的安全注意事项压测说到底是在挑战系统的极限所以要讲究分寸。几个我吃过亏的教训分享给你第一不要在远程连接的唯一会话里直接跑大压力测试。如果你用的是SSH连服务器跑压力测试压力过大可能导致系统响应变慢甚至假死你的SSH连接有可能断掉然后你就失去了对机器的控制。建议用tmux或screen起一个会话跑压测即使连接断了压测进程还能继续运行重新连上后还能看到之前的输出。第二内存压测总量一定要留余量。别把物理内存压到100%给系统内核和基础服务留出几百MB甚至更多的余量否则OOM Killer启动后可能把不该杀的系统服务给杀了测试结果会被严重污染。第三跑磁盘压测前确认磁盘空间和磨损程度。如果是机械硬盘或老旧SSD的机器长时间--hdd压测会加剧磁盘磨损。这种测试不是不能做但要有目的性不是为了测磁盘本身就没必要长时间跑。5. 常见问题与排查技巧实录5.1 压测以后系统负载降不下来这个问题我遇到不只一次。明明按了CtrlC或者--timeout到了时间系统负载依然很高。排查步骤是这样的先用top看是哪个进程在消耗CPU如果是stress的残留子进程用pkill -f stress清理。注意stress的父进程退出后某些子进程可能会变成孤儿进程继续运行。这时可以pgrep -l stress列出所有名字包含stress的进程逐个确认后清理pkill -9 stress另外如果CPU压测跑完LOAD值依然很高但CPU使用率已经降下来了那可能是系统在刷脏页或等待I/O完成这时候耐心等一下就好通常不会持续太久。5.2 内存压测触发OOM Killer内存压测时系统报错Out of memory: Kill process说明压测配置和机器实际内存不匹配。比如一台只有4G内存的机器你直接跑stress --vm 8 --vm-bytes 1G8个进程共需要8G内存远超物理内存OOM Killer就会出手。解决方案是精确计算内存分配量。建议先看free -h确定可用内存最多用70%到80%的可用内存做压测。假设机器有8G内存系统已用2G可用约6G那压测内存量控制在4G到5G比较合适可以配置成stress --vm 4 --vm-bytes 1G还有一种情况你确实想压到OOM看系统能不能正确杀掉内存超限进程从而保护主机不挂这种测试在容器环境验证时其实是有效的验证手段。但如果你的目标是验证“系统在内存高负载下稳定运行”那就要避开OOM阈值。5.3 --hdd压测后临时文件没清理干净stress --hdd跑完后会在/var/tmp下留下临时文件按我的经验它会以类似stress.XXXXXX的命名方式写入文件。如果不清理日积月累会占用不少磁盘空间。清理命令很简单ls /var/tmp/ rm -f /var/tmp/stress.*为了避免这个问题更推荐的做法是在命令里就指定临时文件路径放到专门的测试目录下测完直接删目录mkdir /tmp/stress-test stress --hdd 2 --hdd-bytes 1G --timeout 1m跑完以后删除整个测试目录干净利落。5.4 压测过程中SSH超时断连这是一个很实际的运维场景你通过SSH连接服务器跑长时间压测压测到一半SSH连接断了。排查思路是先确认是不是网络侧的会话超时限制同时建议所有长时间压测都放进tmux会话中执行。我已经养成习惯凡是超过10分钟的压测一律先建tmux会话tmux new -s stress-test stress --cpu 16 --timeout 1h # 按 CtrlB 再按 D 脱离会话连接断了也不影响压测进程重新连接后用tmux attach -t stress-test回到压测会话查看输出情况。这个习惯帮我避免了多次远程压测断连后无法确认结果的麻烦。5.5 压测结果如何判断是否成功最后聊一下怎么判断压测结果。stress本身不会输出一个“通过/失败”的结论你需要自己综合判断。我个人的判断标准有三条压测期间系统没有出现严重错误日志dmesg中没有OOM、panic、硬件报错。压测结束后SSH和基础服务依然正常响应负载能回落到正常水平。压测期间业务进程如果有没有出现崩溃或者长时间无响应。这三条都满足这台机器基本可以认定在当前压测配置下是稳定的。如果再严格一点可以对比压测前后/proc/cpuinfo和smartctl的磁盘健康状态确认没有新增的硬件隐性故障。结尾我在实际使用stress过程中最大的体会是工具本身简单到不行真正的复杂度在于你怎么设计压测方案和解读压测结果。压测之前先想清楚要验证什么再动手跑数据才有参考价值。最后分享一个小技巧如果你需要定期做压力测试可以写一个脚本把stress和stress-ng配合使用先用stress做快速冒烟验证确认基本功能正常后再用stress-ng做专项深度压测这样兼顾了效率与深度我在多个项目的服务器验收中都是这么做的效果一直不错。本文还有配套的精品资源点击获取 Linux压力测试工具stress实战：从安装到拷机一条龙
简介Linux压力测试工具stress 1.0.1源码资源包面向系统管理员、运维工程师与嵌入式开发者用于模拟CPU、内存、线程/进程等负载评估系统在极限场景下的稳定性与性能表现。压缩包整体约199KB共32个文件以C源码、configure配置脚本、Makefile构建文件为主兼有texinfo文档、man手册及ChangeLog等说明材料目录沿用标准GNU工程结构便于编译、安装与二次开发。该工具支持通过命令行灵活指定负载类型与线程数量可模拟计算密集、内存紧张及高并发进程创建等场景。目前已有3031人学习下载适合需要验证服务器承载力、排查资源瓶颈或开展性能调优的工程师。借助该包可收获完整源码与配套文档既能直接用于压测环境搭建也能深入研读stress的核心实现为自行编写轻量级负载工具提供参考。linux压力测试工具stress实战从装库到拷机一条龙做Linux运维和系统性能验证的朋友一定绕不开一个场景新买的服务器到了要验证硬件稳不稳内核打了一个补丁要确认系统不会跑着跑着就崩部署容器之前要看看资源隔离到底靠不靠谱。这些场景都有一个共同的底子需求——给系统施加一个可控的压力然后在压力下观察它的表现。stress就是干这个的一个轻量、纯粹、用来给Linux系统制造负载的小工具我用它做过不少次拷机和稳定性验证这篇就来聊聊它的完整玩法。1. 工具选型与核心概念1.1 stress到底是个什么工具stress是Amos Waterland写的一个C语言小工具它的设计目标非常纯粹通过fork出大量子进程分别去消耗CPU、内存、磁盘I/O和资源分配能力从而让系统进入一种可量化、可控的高负载状态。说人话就是——你告诉它“给我压出8个满负荷CPU的负载”它就老老实实fork出8个进程每个进程拼命算数学题把CPU时间吃满。很多人会把stress和stress-ng搞混。stress-ng是它的加强版包含几百种压测方法功能更强但复杂度也高。而stress的特点是参数简单、行为直观、结果容易判断适合做快速验证和日常拷机。我个人的习惯是快速验证用stress深度专项压测用stress-ng或sysbench但日常工作中stress出现的频率其实更高因为它足够轻量装完即用不引入太多学习成本。1.2 为什么需要给系统制造压力很多人会有疑问我的服务已经在线上跑了为什么还要额外制造压力这里有个概念要分清线上跑业务是“实际负载”压测工具制造的是“人工负载”。实际负载是随机的、起伏的、不好控制的而人工负载是确定的、稳定的、可调节的。做稳定性验证时你不希望负载忽高忽低导致结果无法解释你希望CPU稳定在100%、内存稳定占用N个GB然后观察系统在这种极端情况下是否还能正常工作。stress的价值就在这里它把负载变成了一个有刻度的仪器让你能够在“系统扛不住之前”就掌握系统的边界在哪里。比如一台8核机器先压6个CPU看看是否稳定再压8个再压10个超卖观察不同负载级别下的系统行为。这种测试在硬件验收、性能基线采集、容器限制验证中都属于必备环节。1.3 适用场景梳理从我实际接触过的使用场景来看stress主要适合以下几种情况硬件拷机新装机或购买二手服务器后用CPU和内存压力验证硬件是否有隐性故障。内核与驱动验证打了补丁、升级了内核、更换了驱动需要在负载下确认系统不会panic或死锁。性能调优前后对比调整内核参数、CPU调频策略之前和之后用同样的压力对比系统表现。容器与虚拟化资源限制验证确认cgroup的CPU限制、内存限制是否真正生效。教学和技术测试演示系统负载、观察调度行为时stress是干净利落的负载制造工具。2. 安装部署与环境准备2.1 各主流发行版的安装方法stress的安装非常简单官方源里基本都有现成的包。以最常见的几个发行版为例# Debian / Ubuntu sudo apt-get install stress # CentOS / RHEL 7/8/9 sudo yum install stress # Fedora sudo dnf install stress # Arch Linux sudo pacman -S stress如果你用的是极其精简的发行版或者没有现成包也可以从源码编译安装。stress的源码包很小编译过程依赖也很少wget https://downloads.your.org/stress/stress-1.0.7.tar.gz tar -xzf stress-1.0.7.tar.gz cd stress-1.0.7 ./configure make sudo make install安装完成之后验证一下是否成功stress --version能输出版本号就说明OK了。我在编译安装时踩过一次坑某些精简系统上缺少make和gcc需要先用包管理器装好基础编译工具链再执行configure。2.2 压测前的系统状态确认在做压力测试之前有一件小事经常被忽略确认CPU调频策略。现在的CPU大多有自动调频功能空闲时降频省电负载高时自动升频。如果你不做任何设置压测过程中CPU频率可能忽高忽低测试结果的一致性会受影响。建议在压测前把CPU调到最大频率或性能模式观察一下当前频率运行状态# 查看当前CPU频率 cat /proc/cpuinfo | grep MHz # 使用cpupower工具设置性能模式需要root权限 cpupower frequency-set -g performance如果发行版没有cpupower命令也可以装linux-cpupowerDebian/Ubuntu或kernel-toolsCentOS包。当然如果你测试的目的恰恰是要验证调频策略本身的行为那就不需要这一步反而应该保持默认策略去压具体取决于你的目标。另外压测前还要确认系统负载基线是干净的。最好在一台没有业务的机器上做压测或者至少确认当前top显示的load average不高避免把别人业务的负载误算进你的测试结果里。3. 压测方案设计与核心参数3.1 CPU压测--cpu参数详解stress最常见的用法是CPU压测命令格式如下stress --cpu 8这会在当前终端前台fork出8个子进程每个进程执行一个计算平方根的死循环把CPU核心吃满。根据我的实测每个--cpu进程会跑在单核上8个进程就能吃满8个逻辑核心。机器有多少核心可以用nproc查看。这里有个决策点如果机器是超线程架构8核16线程要压满所有逻辑核心应该用--cpu 16还是只压8个物理核心这取决于你的目的。如果你想验证整机散热和供电是否扛得住那就压满16个线程让所有逻辑处理器都进入高负载状态如果你想模拟“每个物理核心承载一个典型业务进程”的场景压8个可能更贴近实际。CPU压测默认会一直跑下去直到你按CtrlC终止。实际操作中通常需要限制时长用--timeout参数# 压8个CPU核心持续60秒后自动退出 stress --cpu 8 --timeout 60s--timeout支持10s、1m、1h、1d这样的时间后缀也支持纯数字单位为秒。加上超时控制的最大好处是不用干等测试完自动退出适合写进脚本里循环执行。3.2 内存压测--vm参数详解内存压测用到--vm系列的参数# 启动4个内存压测进程每个分配512MB内存 stress --vm 4 --vm-bytes 512M每个--vm进程会调用malloc分配指定大小的内存然后循环写入数据确保内存页真实被触达。这里我补充一个容易被忽视的细节malloc分配出来的内存在没有写入之前只是虚拟内存不会占据实际的物理内存页。stress内部会通过写入操作对这些内存页进行实际触达这也是它压内存比较有效的原因。实际压测时内存总量要算清楚。比如机器有8GB可用内存你启动4个进程每个分配2GB总量就是8GB。如果分配总量超过实际可用内存系统会开始使用swap性能会骤降如果超过物理内存加swap的总量则可能触发OOM Killer某个进程被内核杀掉测出来的结果就不具备参考意义。还有--vm-hang参数值得说明。它会指示子进程在分配并写入内存后挂起一段时间而不是反复随机读写。比如stress --vm 2 --vm-bytes 1G --vm-hang 30两个进程各分配1GB内存并保持30秒不释放。这种模式适合测试“系统在内存长期以高占用率运行时是否稳定”贴近数据库缓存、JVM堆内存这类常驻内存场景。3.3 磁盘和I/O压测--io与--hdd磁盘I/O压测主要有两个参数--io和--hdd。# 启动4个I/O进程每个进程不断执行sync系统调用 stress --io 4--io的做法是不断fork新进程执行sync()把文件系统缓冲区刷入磁盘产生系统调用和I/O调度压力。不过说实话这种压测方式对现代SSD来说压力并不大它更多是压内核的I/O路径和调度器不是直接压磁盘带宽。想要更直接的磁盘写入压力用--hdd# 启动2个写盘进程每个向文件中写入1GB数据 stress --hdd 2 --hdd-bytes 1G--hdd进程会创建一个临时文件默认在/var/tmp目录下然后反复写数据进去。这个测试会真实产生磁盘写入流量可以用来验证磁盘的稳定性和散热。这里有一个我踩过的坑--hdd默认会在/var/tmp下生成临时文件对于容量小的根分区1GB甚至几GB的写入很容易把根分区磁盘占满。所以在跑--hdd之前一定先看看磁盘剩余空间同时建议用--hdd-bytes限制单次写入上限或者指定文件路径。3.4 组合压测模拟真实混合负载前面的参数都是单一维度的但生产环境的负载从来不会只消耗一种资源。stress允许同时指定多个维度一次压测模拟混合负载# 8个CPU进程 2个内存进程各1G 1个磁盘写入进程持续5分钟 stress --cpu 8 --vm 2 --vm-bytes 1G --hdd 1 --hdd-bytes 1G --timeout 5m这种组合压测更适合在真实服务器上做整体稳定性验证。比如你新部署了一个生产环境想确认在“CPU高负载、内存大量占用、磁盘持续写入”的场景下业务进程还能不能稳定响应这种混合压测就很有参考价值。我在实际做服务器验收时几乎都是用组合参数跑30分钟以上而不仅仅是单测一个维度。3.5 核心参数速查表参数作用常用搭配备注--cpu N启动N个CPU负载进程--timeout每个进程吃满一个逻辑核心--vm N启动N个内存负载进程--vm-bytes每个进程分配指定大小内存--vm-bytes SIZE指定每个内存进程分配的大小--vm N支持K/M/G后缀--vm-hang N内存分配后挂起N秒--vm模拟常驻内存负载--io N启动N个I/O进程--timeout不断执行sync系统调用--hdd N启动N个写盘进程--hdd-bytes真实产生磁盘写入流量--timeout TIME指定总运行时长所有参数支持s/m/h/d后缀--verbose显示详细压测日志任意配合调试使用4. 实操过程与数据观察4.1 一个完整的压测流程示例在真正压测之前我先做一次基线采集也就是不做任何压测时记录系统初始状态。这一步很重要因为后续判断异常都需要和基线对比uptime free -h df -hT /var/tmp mpstat -P ALL 1 3假设我现在拿到一台8核16G的服务器要做一次硬件稳定性验收压测方案分三步走第一步跑CPU压力10分钟确认所有逻辑核心都稳定在100%负载stress --cpu 16 --timeout 10m第二步跑内存压力按70%内存占用设计16G机器留出系统余量分配12G占用stress --vm 6 --vm-bytes 2G --timeout 10m第三步混合压测30分钟模拟真实业务的高负载场景stress --cpu 16 --vm 4 --vm-bytes 2G --hdd 4 --hdd-bytes 2G --timeout 30m三个步骤跑完如果没有出现进程被kill、系统死机、内核报错等现象基本可以认为这台机器的硬件和系统在合理的负载范围内是稳定的。4.2 压测过程中的数据观察方法压测启动后记住一个原则不要只盯着黑色终端等结果要开另一个终端去观察系统状态。我最常用的观察工具组合如下top/htop看整体CPU使用率、load average、内存占用判断压测进程是否达到预期负载。mpstat -P ALL 1逐核查看CPU使用率。这个非常关键能看出压力是否均匀分布在所有核心上如果只有部分核心为100%说明压测进程数量少了或者存在中断绑核等问题。free -h查看内存与swap使用情况。如果内存压测导致swap开始大量增长说明压测内存分配过量不是理想状态。iostat -x 1观察磁盘使用率、吞吐量和I/O等待时间配合--hdd压测使用。这里我举个例子。用stress --cpu 8压一台8核机器在另一个终端跑mpstat -P ALL 1正常情况下每个CPU的%usr都接近100%。但如果发现其中某个CPU的%usr只有50%左右可能就是stress进程被调度到了中断处理较多的CPU上或者系统本身有绑核配置。这种细节在高精度压测中值得排查。4.3 压测时的安全注意事项压测说到底是在挑战系统的极限所以要讲究分寸。几个我吃过亏的教训分享给你第一不要在远程连接的唯一会话里直接跑大压力测试。如果你用的是SSH连服务器跑压力测试压力过大可能导致系统响应变慢甚至假死你的SSH连接有可能断掉然后你就失去了对机器的控制。建议用tmux或screen起一个会话跑压测即使连接断了压测进程还能继续运行重新连上后还能看到之前的输出。第二内存压测总量一定要留余量。别把物理内存压到100%给系统内核和基础服务留出几百MB甚至更多的余量否则OOM Killer启动后可能把不该杀的系统服务给杀了测试结果会被严重污染。第三跑磁盘压测前确认磁盘空间和磨损程度。如果是机械硬盘或老旧SSD的机器长时间--hdd压测会加剧磁盘磨损。这种测试不是不能做但要有目的性不是为了测磁盘本身就没必要长时间跑。5. 常见问题与排查技巧实录5.1 压测以后系统负载降不下来这个问题我遇到不只一次。明明按了CtrlC或者--timeout到了时间系统负载依然很高。排查步骤是这样的先用top看是哪个进程在消耗CPU如果是stress的残留子进程用pkill -f stress清理。注意stress的父进程退出后某些子进程可能会变成孤儿进程继续运行。这时可以pgrep -l stress列出所有名字包含stress的进程逐个确认后清理pkill -9 stress另外如果CPU压测跑完LOAD值依然很高但CPU使用率已经降下来了那可能是系统在刷脏页或等待I/O完成这时候耐心等一下就好通常不会持续太久。5.2 内存压测触发OOM Killer内存压测时系统报错Out of memory: Kill process说明压测配置和机器实际内存不匹配。比如一台只有4G内存的机器你直接跑stress --vm 8 --vm-bytes 1G8个进程共需要8G内存远超物理内存OOM Killer就会出手。解决方案是精确计算内存分配量。建议先看free -h确定可用内存最多用70%到80%的可用内存做压测。假设机器有8G内存系统已用2G可用约6G那压测内存量控制在4G到5G比较合适可以配置成stress --vm 4 --vm-bytes 1G还有一种情况你确实想压到OOM看系统能不能正确杀掉内存超限进程从而保护主机不挂这种测试在容器环境验证时其实是有效的验证手段。但如果你的目标是验证“系统在内存高负载下稳定运行”那就要避开OOM阈值。5.3 --hdd压测后临时文件没清理干净stress --hdd跑完后会在/var/tmp下留下临时文件按我的经验它会以类似stress.XXXXXX的命名方式写入文件。如果不清理日积月累会占用不少磁盘空间。清理命令很简单ls /var/tmp/ rm -f /var/tmp/stress.*为了避免这个问题更推荐的做法是在命令里就指定临时文件路径放到专门的测试目录下测完直接删目录mkdir /tmp/stress-test stress --hdd 2 --hdd-bytes 1G --timeout 1m跑完以后删除整个测试目录干净利落。5.4 压测过程中SSH超时断连这是一个很实际的运维场景你通过SSH连接服务器跑长时间压测压测到一半SSH连接断了。排查思路是先确认是不是网络侧的会话超时限制同时建议所有长时间压测都放进tmux会话中执行。我已经养成习惯凡是超过10分钟的压测一律先建tmux会话tmux new -s stress-test stress --cpu 16 --timeout 1h # 按 CtrlB 再按 D 脱离会话连接断了也不影响压测进程重新连接后用tmux attach -t stress-test回到压测会话查看输出情况。这个习惯帮我避免了多次远程压测断连后无法确认结果的麻烦。5.5 压测结果如何判断是否成功最后聊一下怎么判断压测结果。stress本身不会输出一个“通过/失败”的结论你需要自己综合判断。我个人的判断标准有三条压测期间系统没有出现严重错误日志dmesg中没有OOM、panic、硬件报错。压测结束后SSH和基础服务依然正常响应负载能回落到正常水平。压测期间业务进程如果有没有出现崩溃或者长时间无响应。这三条都满足这台机器基本可以认定在当前压测配置下是稳定的。如果再严格一点可以对比压测前后/proc/cpuinfo和smartctl的磁盘健康状态确认没有新增的硬件隐性故障。结尾我在实际使用stress过程中最大的体会是工具本身简单到不行真正的复杂度在于你怎么设计压测方案和解读压测结果。压测之前先想清楚要验证什么再动手跑数据才有参考价值。最后分享一个小技巧如果你需要定期做压力测试可以写一个脚本把stress和stress-ng配合使用先用stress做快速冒烟验证确认基本功能正常后再用stress-ng做专项深度压测这样兼顾了效率与深度我在多个项目的服务器验收中都是这么做的效果一直不错。本文还有配套的精品资源点击获取