一、简介：为什么实时 AI 必须“虐自己”？
场景痛点：
视觉引导的机械臂：推理延迟从 5 ms 跳到 50 ms → 焊接点偏移 2 mm，废品率飙升。
自动驾驶 ECU：CPU 被日志进程抢占 100 ms → 错过激光雷达融合窗口，安全降级。
压力测试价值：
提前暴露“资源饥饿”拐点，避免“现场翻车”。
为 SIL/ISO 26262 认证提供“极端条件下实时性”证据。
工具选择：Stress-ng 自带 200+ 压力模块，支持CPU、内存、网络、中断、 thermal等多维度组合，与 cyclictest 无缝配合，是实时 Linux 社区公认“标配”。
二、核心概念：5 个关键词先搞懂
| 关键词 | 一句话 | 本文出现场景 |
|---|---|---|
| Stressor | 压力模块，如--cpu 8 --matrix 1 | 模拟不同负载 |
| Cyclictest | 测量调度延迟的标杆工具 | 与 Stress-ng 同时跑，看最大延迟 |
| Network Storm | 瞬间 >1 Gbps UDP/TCP 突发 | 验证网卡驱动 NAPI/RT 补丁 |
| Thermal Throttling | CPU 温度墙降频 | 实时性“隐藏杀手” |
| Watchdog | 软件/硬件看门狗 | 压力过程触发复位即失败 |
三、环境准备：10 分钟搭好“压力实验室”
1. 硬件
x86_64 多核 ≥4 核，内存 ≥8 GB，千兆网卡 ×2（一张压测、一张管理）
2. 软件
| 组件 | 版本 | 安装命令 |
|---|---|---|
| Ubuntu Server | 22.04 | — |
| PREEMPT_RT 内核 | 5.15-rt50+ | 见 3.1 一键脚本 |
| Stress-ng | 0.15+ | apt install stress-ng |
| RT-Tests | 2.5+ | apt install rt-tests |
| iperf3 | 3.9+ | apt install iperf3 |
3.1 一键安装 RT 内核（可复制）
#!/bin/bash # install_rt.sh VER=5.15.71 RT_PATCH=patch-5.15.71-rt50.patch.xz wget https://kernel.ubuntu.com/~kernel-ppa/mainline/v${VER}/linux-${VER}.tar.xz wget https://kernel.ubuntu.com/~kernel-ppa/mainline/v${VER}/${RT_PATCH} tar -xf linux-${VER}.tar.xz && cd linux-${VER} xzcat ../${RT_PATCH} | patch -p1 make olddefconfig ./scripts/config --set-val CONFIG_PREEMPT_RT y make -j$(nproc) deb-pkg sudo dpkg -i ../*.deb sudo reboot重启选 RT 内核进入即可。
3.2 创建实验目录
mkdir -p ~/stress-lab && cd ~/stress-lab四、应用场景（300 字实战缩影）
某 3D 视觉引导机器人需在 1 kHz 频率下完成“拍照→AI 推理→姿态计算→伺服控制”闭环。现场调试时发现：
当上位机通过千兆网批量下载模型文件（>800 Mbps）时，推理周期从 1 ms 抖动到 3-5 ms，机械臂轨迹出现“毛刺”；
运维临时打开系统日志（journald）DEBUG 级别，CPU 瞬时 100%，导致 cyclictest Max 延迟飙升至 120 µs，触发安全 PLC 停机。
使用本文 Stress-ng 脚本，实验室内复现“网络风暴 + CPU 满载 + 内存抖动”三元耦合压力，提前锁定瓶颈：
网卡 NAPI 权重过高，占用 SoftIRQ 连续 2 ms；
Journald 与 AI 推理线程同核，日志打印触发写回，产生长延迟。
通过taskset隔离 +chrt提升推理线程优先级，并启用irqbalance禁用压测网卡中断亲和，最终 Max 延迟降至 38 µs，通过 IEC 61508 SIL 2 预审。
五、实际案例与步骤：从“温和”到“极限”四段式加压
每段均可独立运行，先本地验证，再逐步叠加。
5.1 基础：CPU 满载 + 调度延迟监测
# Terminal 1: 压力 stress-ng --cpu 4 --cpu-method matrixprod --timeout 300s & # Terminal 2: 实时性 sudo cyclictest -p99 -i100 -d60s -n结果解读
Max ≤ 80 µs（RT 内核）即合格；若 >150 µs 检查 BIOS 电源管理、关闭 Turbo。
5.2 进阶：内存抖动 + Page Fault 抑制
stress-ng --vm 2 --vm-bytes 1G --vm-keep --timeout 300s &场景：AI 推理使用大页 (HugeTLB)，普通 4 k 页被换出 → 缺页异常 20 µs→2 ms。
对策：提前mlockall(MCL_CURRENT|MCL_FUTURE)并开启/proc/sys/vm/nr_hugepages。
5.3 网络风暴：千兆 UDP 洪水 + 抓延迟
# Server 端 (被测机) iperf3 -s -p 5201 # Client 端 (另一台 PC) iperf3 -c <被测IP> -p 5201 -u -b 1G -t 60同时跑 cyclictest，观察 Max 是否突增；若突增 → 检查网卡驱动 NAPI 权重，适当调低net.core.netdev_budget。
5.4 终极：三合一“地狱模式”脚本（可复制）
#!/bin/bash # hell_mode.sh echo "=== 1. CPU 满载 + 内存抖动 + 网络风暴 ===" stress-ng --cpu 4 --matrix 1 --vm 2 --vm-bytes 1G --vm-keep & SPID=$! iperf3 -c 192.168.10.5 -u -b 1G -t 300 & IPID=$! echo "=== 2. 实时性监测 ===" sudo cyclictest -p99 -i100 -d300s -n > cyclictest.log 2>&1 echo "=== 3. 结束压力 ===" kill $SPID $IPID wait echo "Max latency:" grep "Max" cyclictest.log | sort -n -k 2 | tail -1运行后：
若 Max < 100 µs → 通过“工业级”门槛；
若 100-200 µs → 优化中断亲和、日志隔离；
若 >200 µs → 检查是否触发 Thermal throttling（见 6.2）。
六、常见问题与解答（FAQ）
| 问题 | 现象 | 解决 |
|---|---|---|
| cyclictest Max > 300 µs | 未关闭 Turbo Boost | BIOS 关闭 Turbo，内核加intel_pstate=disable |
| 网络压力时 SSH 断 | 管理口被压 | 独立网口跑 iperf3，管理口不接压力 |
| 内存压力导致 OOM | 系统 kill 推理进程 | 提前ulimit -l unlimited+mlockall |
| 温度飙 90°C 降频 | 延迟突刺 1 ms | 加风扇，或stress-ng --thermal 0关闭热压 |
| 容器内无法运行 | /dev/cpu_dma_latency不可见 | --privileged或--cap-add SYS_NICE |
七、实践建议与最佳实践
自动化门禁
GitLab CI 每夜跑hell_mode.sh，Max > 100 µs 即 MR 失败。可视化大屏
grafana + node_exporter 插件cyclictest_exporter，实时看延迟分布。分层加压
先单核 CPU → 再内存 → 再网络，逐步逼近，一次只改一个变量。故障注入常态化
每月“随机故障日”：脚本随机拉高负载 30 分钟，团队演练定位。保留证据
每次压测保留cyclictest.log+stress-ng.log+ 系统dmesg，认证审核直接交。别忘了 AI 模型本身
TensorRT/ONNXRT 推理线程加sched_setscheduler(SCHED_FIFO, prio=90)，避免被非实时任务抢占。
八、总结：一张脑图带走全部要点
实时 AI 压力测试 ├─ 工具：stress-ng + cyclictest + iperf3 ├─ 场景：CPU满载→内存抖动→网络风暴→三合一 ├─ 指标：Max latency < 100 µs（SIL 2 门槛） ├─ 调优：锁页、隔离核、关Turbo、NAPI调权 └─ CI：每夜地狱模式，Max超阈值即失败压力测试不是“可选”，是实时 AI 走向工业现场的“门票”。
立刻复制本文脚本，今晚就让系统“跑在刀尖”——提前暴露问题，总比现场召回强！祝你一次压测通过，延迟曲线永远平滑。
