我是一名运维工程师，日常负责为公司部署和维护亚太地区的边缘计算节点。最近上线了几台位于香港的数据中心的新物理服务器，用于承载海外业务流量。在实际上线之前，我始终坚持一个原则：服务器必须经过真实场景的压力验证，才能承载线上业务。

香港节点的网络质量尚可，但我更关注的是机器的硬件性能稳定性，尤其在 CPU 计算、内存读写、磁盘 IO 和文件系统处理能力等方面。这时，stress-ng 和 sysbench 成为了我多维度压测的首选工具。以下是我从0到1执行的一整套实操流程。

一、环境准备

1.1 系统环境说明

• 操作系统：Ubuntu Server 22.04 LTS
• 内核版本：5.15+
• 测试工具：stress-ng、sysbench
• 机器配置：64核 AMD EPYC / 256GB 内存 / NVMe SSD * 2 / 10Gbps 网口
• 节点位置：香港某Tier3机房

1.2 工具安装

# stress-ng 安装
sudo apt update
sudo apt install -y stress-ng

# sysbench 安装
sudo apt install -y sysbench

二、CPU 性能压测

2.1 使用 stress-ng 进行 CPU 压测

我优先使用 stress-ng 对 CPU 进行多线程指令集处理测试：

stress-ng --cpu 64 --cpu-method all --timeout 300s --metrics-brief

--cpu 64：启动 64 个工作线程（等同于物理核数）

--cpu-method all：尝试所有 CPU 算法，包括整数、浮点、矩阵等

--timeout：测试持续 5 分钟

--metrics-brief：输出简洁的性能摘要

✅ 预期输出重点关注：

• 每核每秒执行的 Bogo ops（虚拟操作数）
• 系统 load average 是否持续上升到极限
• 有无 core dump 或 system stall

2.2 使用 sysbench 进行浮点运算压测

sysbench cpu --cpu-max-prime=200000 --threads=64 run

--cpu-max-prime=200000：计算到 20 万以内的质数

--threads=64：并发线程与物理核一致

✅ 关注指标：

• 总执行时间
• 每秒执行事件数（events per second）

三、内存性能压测

3.1 使用 stress-ng 进行内存负载测试

stress-ng --vm 16 --vm-bytes 16G --vm-method all --verify --timeout 180s --metrics-brief

--vm 16：16 个内存工作线程

--vm-bytes 16G：每线程分配 1GB 内存（总计 16G）

--vm-method all：混合使用 memset、memcpy 等方法

--verify：测试内存正确性

--timeout 180s：运行 3 分钟

📌 实测经验： 使用 vm-bytes 接近物理内存的 70~80% 会更贴近实际业务负载，但别超过 SWAP 空间。

3.2 使用 sysbench 测试内存读写吞吐量

sysbench memory --memory-block-size=1M --memory-total-size=100G --threads=16 run

--memory-block-size=1M：每次读写 1MB

--memory-total-size=100G：总读写数据量

--threads=16：模拟并发场景

✅ 关键指标：

• MiB transferred per second（吞吐量）
• 每线程平均延迟

四、磁盘 IO 压测

4.1 使用 sysbench 进行磁盘顺序和随机读写测试

顺序写：

sysbench fileio --file-total-size=100G --file-test-mode=seqwr \
--file-block-size=1M --threads=8 prepare

sysbench fileio --file-total-size=100G --file-test-mode=seqwr \
--file-block-size=1M --threads=8 run

随机读写：

sysbench fileio --file-total-size=100G --file-test-mode=rndrw \
--file-block-size=4K --threads=32 prepare

sysbench fileio --file-total-size=100G --file-test-mode=rndrw \
--file-block-size=4K --threads=32 run

--file-total-size=100G：磁盘压力覆盖整个磁盘缓存区

--file-block-size=4K~1M：模拟不同级别的业务负载

--file-test-mode：可选 seqrd, seqwr, rndrd, rndwr, rndrw

🧠 建议：

测试前 prepare 阶段必须运行一次，创建必要的测试文件

测试后需 cleanup 清理：

sysbench fileio cleanup

五、IO/系统混合负载模拟

使用 stress-ng 混合模拟 IO、fork、缓存抖动

stress-ng --hdd 4 --hdd-bytes 10G \
          --fork 32 \
          --cache 8 --cache-level 3 \
          --timeout 300s --metrics-brief

--hdd：模拟磁盘写操作

--fork：快速创建子进程，模拟高并发 fork bomb

--cache：让缓存层频繁抖动（模拟 L3 cache thrash）

✅ 分析要点：

• swap 是否启用，若频繁交换，需关注内存瓶颈
• fork 失败是否频繁出现
• IO wait 时间是否显著上升

六、结果记录与分析建议

我使用 dstat 与 iostat 做实时性能观测：

sudo apt install dstat sysstat
dstat -cdnmgity --top-cpu --top-bio --output stress_test.csv

iostat -xz 1

✅ 关键观察项：

• CPU idle 是否长期低于 5%
• IOwait 是否高于 15%
• 磁盘的 await 和 svctm 是否均衡

七、压测后的优化建议

经过这轮压测，我确认了以下问题点并做出优化：

• 内核参数优化：调高了 vm.dirty_ratio 和 fs.aio-max-nr
• 磁盘调度器替换：从 cfq 切换为 none（NVMe场景下更高效）
• 多线程绑定 CPU core：部分性能测试中使用 taskset 限定 CPU affinity，更贴近生产业务调度

压测不仅是数据指标的收集，更是一种提前验证架构设计合理性的手段。特别是在边缘部署、海外节点等网络敏感场景下，通过 stress-ng 和 sysbench 的实测，我心里才真正踏实。

如果你也在部署海外服务器，建议你务必走一遍类似的压测流程——工具虽然简单，但能让你避免上线后的系统崩溃和 SLA 事故。