企业官网建设流程全解析

把 CPU 打到 100%、内存撑到 90% 以上、磁盘写满、带宽占完——这种操作看着像在搞破坏，但做过高可用测试和性能压测的人都知道，这恰恰是运维、SRE、测试工程师最常用也最该练熟的本事。很多新手拿到压测任务，第一反应是找个压测平台或者现成脚本，等到现场才发现：平台只能压接口 QPS，根本压不住系统资源；脚本倒是写出来了，可一个不小心就把测试机压得连 SSH 都连不上。真正需要的是能够精确、可控、可恢复地把 CPU、内存、磁盘、网络分别压到接近 100% 的方法，用来验证监控告警、自动扩缩容、故障转移、OOM 重启这些高可用机制是不是真的会在该触发的时候触发。

这篇文章我把多年演练中用过的各种"压满系统"手段整理一遍，从最简单的一条命令到可以精确控制负载比例的进阶工具，从 CPU 到内存、磁盘、网络，都给出可复现的命令和原理，最后再用一次完整的故障演练来展示这些方法怎么串起来用。适合刚接触高可用测试的人做入门参考，也适合已经会几招但想补全资源类型覆盖的老手。

1. 先把"为什么"想清楚：负载 100% 到底在验证什么

1.1 高可用机制必须靠真负载才能验证

我做高可用测试这些年，见过太多"纸上谈兵"的架构：扩缩容策略写了，告警阈值配了，限流降级方案画了漂亮的时序图，但真到了故障演练那天，负载均衡器没有把流量摘掉，告警短信像哑火一样安静，扩容节点三十秒都没起来——全是因为之前没人真正把系统逼到过极限。

原因很简单。绝大多数的失效恢复机制是靠指标触发的，比如 CPU 超过 80% 持续五分钟就告警、内存使用率超过 85% 就扩容、磁盘写入超时熔断。这些阈值你当然可以在配置中心里看到，但它到底能不能在真实压力下被准确触发，不实测永远不知道。CPU 调度延迟、监控采集间隔、告警聚合窗口、扩容脚本冷启动时间，任何一环拖后腿，都会让"高可用"变成"高可用PPT"。

所以把系统压到高水位，本质是在做一次真实环境下的"消防演习"。消防演习不能只在会议室里画逃生路线，必须真点火、真拉警报、真跑一批人。压负载也是一样，把 CPU 打到接近 100%、把内存顶到 OOM 边缘，才有机会看到系统在那种状态下真实的反应速度和处理动作。

1.2 资源压满能验证什么、不能验证什么

我做了个清单，每次演练前都会过一遍，避免压测目标不清晰。

能验证的：

• 监控链路是否完整：从指标采集、存储、告警计算到通知触达，整条链路在负载高企时是否依然能够按时工作
• 自动伸缩是否真正生效：扩容触发条件到了会不会扩容、缩容策略在负载回落后是否恢复正常
• 熔断降级能否兜底：依赖方出现资源瓶颈时，主调方的行为是否符合预期
• OOM 之后的重启策略：内存被顶爆之后，进程是不是能被自动拉起，会不会陷入重启死循环
• 负载均衡器的摘流能力：某台机器持续高负载时，流量调度能否把新请求分到健康节点

不能验证的：

• 慢内存泄漏：一个每秒泄漏几 KB 内存的缺陷，要跑几天才能看出来，100% 压测的几分钟暴露不了
• 极端链条下的局部性能劣化：比如数据库连接池被慢慢耗尽、缓存穿透持续累积这类连锁反应，需要长时段混合压测才能发现
• 代码层面的逻辑缺陷：负载再高，压出来的只是资源耗尽问题，业务逻辑的 bug 是压测测不出来的

想清楚这点很有用，因为不少人做完一次资源压测，就觉得系统高可用已经验证完毕了，其实验证的边界很有限。知道这一点，才能把不同的压测手段组合成一套完整方案。

2. 压负载之前先立规矩：三个必须做的前置动作

2.1 先保证自己"收得了场"

这是我踩过最大的坑。很多年前我第一次做压测，拿了一条网上的"一行命令把 CPU 打满"直接往服务器上跑，当时确实打满了，CPU 100%，而且那台机器还兼着监控采集的角色，结果把所有监控数据一起打停了。最要命的是，我用 SSH 连上去想要恢复，发现命令都敲不动了。后来才明白，任何压负载的操作，都必须自带一个"计时炸弹"，要么命令本身带超时退出，要么外面包一层 timeout，要么写个脚本定时清理。

我现在的习惯是：不管用什么工具压，一律在最外层加上timeout，哪怕是压着测试玩的，也绝不裸跑。比如：

# 压 CPU 5 分钟，到点自动退出 timeout 300 stress-ng --cpu 4 --timeout 300

为什么timeout比手动Ctrl+C可靠？因为负载打满之后，终端的响应可能已经迟滞到秒级，甚至完全卡住，Ctrl+C有没有发出去都不一定。而timeout是内核在替你计时，时间到了直接向进程组发终止信号，不依赖终端通道。

2.2 准备一个"压测前快照"

压测开始之前，我会先采集一轮基线数据，包括：

• uptime看当前 load average 的基线
• free -h看内存基线
• df -h看磁盘剩余空间
• ss -s看当前连接数
• nproc看 CPU 核数，后面计算并发进程数要用

这一步不是走过场。有一次演练，我压磁盘的时候把日志分区写满，结果监控脚本因为写不了日志直接崩了，而我没留基线数据，排查了半天才意识到是自己的压测误伤了日志系统。有了快照，至少能快速分清"哪些问题是压测目标资源导致的，哪些是副作用导致的"。

2.3 明确环境边界

搞资源压测，一定要在隔离环境里做。我吃过一次亏：某次在预发环境压内存，因为预发和生产的监控组件共用一套告警规则，结果把值班同学半夜轰起来，人家一查是测试在搞事情，当场脸都绿了。从那以后，我给自己立了个规矩——接触的任何压测任务，第一件事是确认三件事：目标机器是不是测试标签、告警通知是不是定向到测试群、压完了自动恢复时间是多少。

容器环境里压测还要多注意一层：容器内的 CPU 限制是 cgroup 控制的，stress-ng看到的 CPU 数和宿主机可能不一样。压之前用nproc确认容器分到的核数，否则你以为压了 4 核，实际只压到了 1 个可用核的配额。

3. CPU 压满的五种操作办法，从"最土"到"最精确"

3.1 一条命令打满单核：yes 与 /dev/null 的经典组合

最原始、也最广为人知的一句命令：

yes > /dev/null

原理很好懂：yes会疯狂向标准输出写字符，把它重定向到/dev/null这个黑洞，CPU 就会永远在忙着做一件事——把字符写到空设备。这个操作占满一个 CPU 核心。要打满 N 核，就开 N 个这样的进程：

# 查看机器有几个核 nproc # 打进后台，每个核一个 for i in $(seq 1 $(nproc)); do yes > /dev/null & done

这个办法虽然土，但有一个好处：如果只是想把某个核打满做单线程性能验证，它非常简单直白，不会引入任何多余的系统调用开销，就是纯粹的循环写操作。缺点是完全没有精细控制，也不能指定跑多长时间，得自己配合timeout或者杀掉进程。

3.2 stress-ng：压测工具箱里的瑞士军刀

如果只让我留一个工具给读者，我会推荐stress-ng。它几乎能干所有资源压测的活：CPU 有几十种不同的压力模式，内存可以指定占用量，磁盘可以做读写压力，还支持超时退出。

安装：

# 常见发行版 apt install stress-ng # Debian/Ubuntu yum install stress-ng # CentOS/RHEL

打满 4 核 CPU 跑 60 秒：

stress-ng --cpu 4 --timeout 60

CPU 压测的进阶玩法是用不同的--cpu-method，比如：

# 用矩阵运算的方式压 CPU，更接近真实计算密集场景 stress-ng --cpu 4 --cpu-method matrixprod --timeout 60

这个工具比yes高明的地方在于它是完全为压测设计的：每个 worker 进程是可控的、可计时的、可统计的。我建议新手从它开始建立压测的"肌肉记忆"，后面所有资源类型都用到它，一套工具通吃。

3.3 lookbusy：把 CPU 精确控制在 70% 之类

很多时候，做高可用测试不需要 100%，而是需要"持续保持 70% 以上"来验证告警阈值是否准确。stress-ng虽然可以控制 worker 的数量，但没法直接说"给我 75% 的 CPU"。这时候就该用lookbusy。

# 生成 4 个进程，每个占用 20% 的 CPU lookbusy -c 20 -n 4 # 占用 80% 的 CPU，跑 120 秒 lookbusy -c 80 -t 120

它的原理是通过循环内精确计算忙等与睡眠的比例来达成目标占用率。换句话说，它不是"全有或全无"地压满，而是模拟一个"这台机器长期处于中高负载"的状态。这在验证自动扩容策略里非常实用——比如系统配置了"CPU 超过 75% 持续 10 分钟扩容一台"，用lookbusy可以非常精准地把负载压在 75% 上下浮动，看看到底第几分钟触发扩容。

3.4 自写脚本控制负载：理解进程状态比命令本身重要

如果你要在不安装任何工具的情况下做压测，或者需要模拟一种特殊的负载波形（比如每 30 秒冲一下 100%，再降下来缓 30 秒），就得自己写脚本。先看一段最小化的 CPU 打满脚本：

#!/bin/bash # 无限循环做空运算，让 CPU 持续忙 while :; do : done

这个脚本跑起来之后，你去看top，会看到那个进程的 CPU 使用率接近 100%，而且进程状态是R（running）。注意它和下面这个的区别：

#!/bin/bash while :; do sleep 1 done

加了sleep之后，进程大部分时间处于S（sleeping）状态，CPU 占用率几乎为 0。这两个状态的区别，就是压 CPU 的核心逻辑：要让 CPU 忙，就必须让进程处于不间断的 "R" 状态，而不是睡眠状态。

Python 写 CPU 密集任务也一样，关键是做真正的计算，而不是在循环里sleep：

import time def burn_cpu(duration_sec: int): end_time = time.time() + duration_sec x = 0.0 while time.time() < end_time: # 连续浮点乘法，制造 CPU 密集计算 x = x * 1.000001 + 0.000001 print("done:", x) if __name__ == "__main__": burn_cpu(30)

我自己写压测脚本时，倾向于用 Python 配合multiprocessing，因为可以灵活控制进程数、持续时间，还能顺手打日志。下面是一个打满全部核数、跑 60 秒的版本：

import multiprocessing import time import os def worker(duration: float): end = time.time() + duration x = 0.0 while time.time() < end: x = x * 1.000001 + 0.000001 print(f"process {os.getpid()} finished") if __name__ == "__main__": cores = multiprocessing.cpu_count() print(f"burning {cores} cores for 60s") procs = [ multiprocessing.Process(target=worker, args=(60.0,)) for _ in range(cores) ] for p in procs: p.start() for p in procs: p.join()

3.5 CPU 打满之后系统会发生什么

很多第一次做压测的人会被吓到：CPU 100% 跑起来，top里面 load average 从 0.5 一路飙到 4.0 甚至更高，然后觉得"系统是不是要崩了"。其实在 Linux 的抢占式调度模型下，CPU 满载只会让所有"想跑但没轮到"的进程排队，并不会让内核直接死掉。只要不是把内存同时打爆导致内核 OOM，系统依然可以响应高优先级的操作。

不过有两个副作用值得注意：一是长时间满载会让 CPU 温度升高，物理机如果散热不行，可能会触发降频，反而影响压测数据准确性；二是如果有多个 CPU 核，某些核打满会导致绑核的中断处理延迟变高，磁盘和网卡的 I/O 性能会跟着劣化。这些在分析压测结果时要分开看：哪些是 CPU 资源本身耗尽导致的，哪些是发热降频和中断延迟带来的间接影响。

4. 内存、磁盘、网络：三类不同资源的"满负载"操作手册

4.1 内存占用：从"90% 安全压"到"OOM 临界压"

内存压测的核心目的有两个：一个是验证"内存高水位告警是否准确"，另一个是验证"内存真的耗尽时 OOM Killer 会不会按预期杀掉进程、进程能否被守护机制重启"。两种目标对应的操作不一样。

高水位告警测试用stress-ng就够了：

# 占用系统内存的 90%，持续 60 秒 stress-ng --vm 2 --vm-bytes 90% --timeout 60

这里我故意写 90% 而不是 100%，原因是系统本身要留一点内存给内核、页缓存和核心守护进程。真用 100%，大概率会直接触发 OOM，那就测不到"告警"这个目标了。合理的做法是先压到 80%、85%、90% 分档观察告警，再决定要不要往临界点推。

如果就是想验证 OOM 之后的表现，可以把比例提到 95% 以上，或者用更可控的方式：写一个 Python 脚本，每次循环分配一块大内存但不释放，直到系统触发 OOM。我一般不建议在生产环境的同配置机器上直接做 OOM 测试，因为 OOM Killer 是有选择性的，它可能会杀掉你以为最不重要的进程，而那个进程恰好是别人正在用的。更安全的做法是在容器里测，借助 cgroup 的内存限制把 OOM 范围圈在容器内部。

# 在容器内模拟内存无限增长，触发 cgroup OOM stress-ng --vm 1 --vm-bytes 95% --vm-hang 5 --timeout 60

内存压力还经常配合其他手段做"内存泄漏模拟"：每 10 秒分配 50MB 内存，持续 30 分钟，看监控曲线是不是线性上升，告警是不是在预期阈值触发。这种模拟可以用一个简单的循环脚本完成，我在第五章会讲一个完整的例子。

4.2 磁盘压满的两个维度：带宽型与容量型

磁盘压测要分两个完全不同的方向，很多人只做了其中一个。

第一类是 I/O 带宽型压力，目标是让磁盘持续处于高读写状态，验证 I/O 等待时间、队列深度、监控系统在%util到 100% 时的表现。最常用的工具是dd和fio。dd做一次性写入压力：

# 持续写 1GB 文件块，测顺序写吞吐 dd if=/dev/zero of=/tmp/testfile bs=1M count=1024 oflag=direct

更精细控制还是用fio：

# 4 个进程做随机读写，持续 60 秒 fio -name=test -rw=randrw -bs=4k -size=1G -numjobs=4 \ -runtime=60 -time_based -group_reporting

第二类是容量型压力，也就是把磁盘空间真正占满，验证"磁盘写满之后系统表现如何"。这个更危险，一不留神就把根分区写满，导致服务起不来。我建议专门挂一块测试盘来搞：

# 用 /dev/shm 或者专门挂载的测试分区，不要用根分区 mkdir -p /mnt/stress_disk dd if=/dev/zero of=/mnt/stress_disk/fill bs=1M count=... # 更稳妥的办法是用 truncate 快速占满配额 while true; do dd if=/dev/zero of=/mnt/stress_disk/fill_$RANDOM bs=1M count=100 \ status=none || break done

写满之后观察系统行为：df -h应该显示 100%，再创建一个文件应该报No space left on device。高可用系统这时候应该触发日志清理、临时文件清理或告警。这里有个经验：Linux 的 ext4 文件系统默认会给 root 用户保留 5% 的预留空间，所以非 root 用户写满更容易，root 用户反而会晚一步触发告警，测试时要注意用户角色的差异。

4.3 网络压满：带宽耗尽与连接数打满

网络资源压测也有两条线。第一条是带宽占满，用iperf3最直接：

# 服务端 iperf3 -s # 客户端，并发 8 个流，持续 60 秒，打满到限速上限 iperf3 -c <server_ip> -P 8 -t 60

-P 8表示同时开 8 个 TCP 流，一般单流不一定占满带宽，多流叠加通常能把千兆或者万兆口压到接近上限。配合-R可以反过来测下行带宽：

iperf3 -c <server_ip> -R -P 8 -t 60

第二条是连接数打满，这对高并发的线上系统更有意义。用并发请求把节点的 TCP 连接数打到接近ulimit和somaxconn的上限，看调度器、反向代理、防火墙的表现。这里可以用ab（ApacheBench）、wrk、或者一个简单的并发连接脚本。wrk比较适合测七层连接和请求压力：

wrk -t 8 -c 1000 -d 60s http://<server_ip>/api/ping

这条命令用 8 个线程开 1000 个并发连接，保持 60 秒，打高并发和下行的同时也会吃掉不少系统资源。如果单纯想打满连接数而不产生大流量，可以写一个长连接脚本，建立连接之后挂着不发请求，占满连接槽位。

网络层面还有一个经常被忽略的操作：人为制造延迟和丢包。用tc命令可以做到：

# 给网卡加 100ms 延迟 + 10% 丢包，模拟恶劣网络 tc qdisc add dev eth0 root netem delay 100ms loss 10% # 用完记得删除 tc qdisc del dev eth0 root netem

这个对验证超时重试、熔断策略非常有用，严格说也是"负载"的一种形态——它不是把资源占满，而是把网络质量拖到极限，让上层依赖的容错机制必须工作。

5. 一次真实的 100% 负载测试实战记录

5.1 测试场景与压测编排

为了把上面的方法串起来，我描述一次实际做过的测试。目标是验证一个模拟项目的某 Web 节点集群（两节点）在高 CPU、内存、磁盘压力下，云平台的负载均衡器能否正确摘除不健康节点，监控告警能否按时触发。测试环境全部使用标签隔离，告警通知定向到测试群。

我先写了一个压测矩阵，防止现场手忙脚乱：

5.2 执行过程中的关键观察点

第一阶段用lookbusy精确压到 70% 之后，我盯着监控面板看 CPU 曲线。这里有个细节：监控系统采集 CPU 有 15 秒的粒度，而lookbusy的负载本身有波动，所以告警触发时间比"压测开始后立即触发"要晚一个采集周期。如果你有"CPU 持续 10 分钟超过 75% 触发扩容"的策略，此时你还会看到扩容动作在 10 分钟后才出现，这完全是策略定义决定的，不是系统故障。

第二阶段把负载拉满到 100% 之后，负载均衡器的健康检查开始出现连续失败，节点被摘流。这时候我注意到一个有意思的现象：摘流之后 CPU 使用率没有马上掉下来，因为已经建立的连接还在继续处理，要等存量流量排空才真正空闲。这个"摘流后回落"的延迟时间，其实是判断节点优雅退出配置是否合理的指标。

第三阶段压内存到 90% 时，告警正常触发，但我顺手做了个额外检查——dmesg -T | tail，确认系统没有提前进入 OOM 状态。如果 OOM 提前触发了，说明 90% 这个水位对于该机器已经不是安全水位了，需要重新评估业务进程的内存占用曲线。

第四阶段磁盘压满时，意料之外的事情出现了：监控进程本身因为写不了日志也开始报错，接口响应变慢。这恰好暴露了一个真实问题——系统的监控链路依赖本地日志盘，磁盘满会导致监控数据中断，形成"监控盲区"。这个发现比"验证磁盘告警是否触发"本身更有价值，因为我们在不健康状态下看不到完整的系统状态了。

5.3 如何判断测试结果"符合预期"

一轮压测下来，我不是只看"有没有告警"，而是把预期结果和实际结果做对照，分成了三个区间：

• 完全符合预期：70% CPU 持续 10 分钟触发扩容、100% CPU 时负载均衡器摘流、磁盘 95% 时告警触发
• 不符合预期但可接受：摘流后节点 CPU 回落需要 3 分钟，大于预期的 1 分钟，因为存量连接排空策略相关参数需要调优
• 暴露真实缺陷：磁盘满导致监控断链，这是预案里没考虑进来的故障

这套判断方法的好处是，一次压测结束之后能直接输出有行动项的结论，而不是一句"系统表现正常"就打发了。高可用测试要的是发现问题和验证修复，不是走过场。

6. 各种压测方法的边界与常见误区

6.1 "压满"和"压崩溃"之间有条线

很多新手容易把"压到 100%"误解成"把系统压到崩溃的边缘"。其实这两者之间隔着一条清晰的线：一个健康的 Linux 系统，即使 CPU 100%、内存 90%、磁盘 I/O 占满，依然能够响应基本的系统管理操作，比如 SSH 登录、查看日志、kill 进程。只有当内存真的耗尽触发 OOM、或者磁盘完全无空间导致核心服务写不了文件、或者文件句柄耗尽导致进程无法创建新连接时，才叫"压崩溃"。

在测试时要有意识地区分这两种状态。如果只是想验证应用的弹性，压到 100% CPU 就够了，不必真的触发 OOM；如果你就是要测 OOM 后的恢复能力，那就需要刻意为之，并且要清楚它可能波及的不只是被测应用，还有同机其他进程。我见过有人在混布了多个服务的机器上做 OOM 压测，结果把旁边的缓存服务一并带走了，场面一度很尴尬。所以压测前一定要明确：本次到底要压到哪一层，用什么指标来定义"停手"。

6.2 工具选型对照表

这些年我用过的压测方法不少，每个都有自己的适用场景。整理一张表，方便参考：

工具没有绝对的好坏，关键是匹配测试目标。比如验证"CPU 超过 75% 持续 5 分钟告警"，用yes就不合适——它只能 100%，超过了阈值一大截；用lookbusy压到 76% 才是精准验证。

6.3 我踩过的几个坑，希望你绕开

第一，别用 root 直接跑压测命令。压测工具有时候会误杀进程，root 权限下 OOM Killer 的杀伤范围更大，而且你可能不小心把系统关键服务一起搞挂。我一般用普通用户跑，配合systemd-run --scope指定 CPU 和内存限制：

systemd-run --scope -p CPUQuota=400% -p MemoryMax=2G \ stress-ng --cpu 4 --timeout 60

这样即使脚本失控，也最多杀掉这个 scope 内的进程，不会祸及全局。

第二，压测期间要给自己的"逃生通道"留资源。除了加timeout，我会额外开一个独立的 SSH 会话，并且通过带外管理口（比如云控制台 VNC）留一条看得到桌面/控制台的路径。有一次我压内存时，SSH 进程因为内存不足被 OOM 选中杀了，我只能靠云厂商的网页终端进去收场。这条通道平时不起眼，关键时候很救命。

第三，压测后的"恢复期"也要记录。停止压测之后，CPU 掉下来不难，但内存和磁盘的回收需要时间：页缓存会慢慢淘汰、磁盘空间释放、连接逐批关闭。如果恢复期太长，说明应用在资源释放上存在问题。这个指标我会写进压测报告，它和压测本身的峰值数据一样值得关注。

第四，不要在压测用的机器上同时跑日志采集。这个我在前面提到过，但真的值得反复强调。压测目标是资源占满，日志采集同样吃 CPU、内存和磁盘；两者叠加，要么日志先崩，要么压测数据被日志干扰，两头不讨好。演练前把采集代理停掉或者换到独立存储，比事后排查要省很多事。

写在最后的实操体会

做了这些年高可用压测，我最大的体会是：把某个资源压到 100% 从来不是目的，真正值钱的是这套"受控制造故障、观察系统反应、安全恢复现场"的能力。工具从yes到stress-ng到自写脚本，改的是控制精度和扩展性，不变的是三个核心习惯——动手前先有收场方案，压测中保留独立逃生通道，结束后记录恢复时长。如果你能把这三点刻进肌肉记忆，不管以后遇到什么样的压测任务，都不会出大乱子。下回做故障演练，别再只拿一条命令硬怼了，按目标选工具，按风险做隔离，把每一次压测都当成一次真正的排查训练来做。