stress-ng 需按硬件瓶颈层级精准配置参数：cpu 测多核调度用 --cpu n --cpu-ops 与亲和性；内存测控制器需 --vm 与 --numa 绑定节点；io 测 nvme 要 --hdd-opts direct,rand；--metrics-brief 直读内核接口暴露 tlb/numa 等深层指标；崩溃复现须匹配故障窗口，如 pcie 丢帧用 --hdd 循环监控 dmesg。
Stress-ng 是目前 Linux 下最灵活、最贴近真实负载场景的压力测试工具，比老牌 stress 更可靠，尤其适合验证 CPU、内存、IO、缓存一致性等底层硬件稳定性。但直接跑默认命令容易测偏——比如只压满 CPU 频率却绕过 thermal throttling，或用错 --vm-bytes 导致 OOM killer 杀进程而非暴露内存控制器缺陷。
如何用 stress-ng 模拟真实硬件压力而非“假满载”
关键在于匹配被测硬件的瓶颈层级：CPU 核心数、内存通道数、NVMe 队列深度、L3 缓存大小。默认 stress-ng --cpu 0 会起满逻辑核，但若目标是验证多核调度器或缓存争用，应显式控制并发数和亲和性。
- 查物理核心数：
nproc --all，再用--cpu 4 --cpu-ops 10000限制单核运算量，避免过早触发温控降频 - 验证内存控制器稳定性时，必须让每个 NUMA 节点独立压测：
stress-ng --vm 2 --vm-bytes 8G --vm-hang 1 --numa 1（--numa 1强制绑定当前节点） - 绕过 page cache 干扰 IO 测试：
stress-ng --hdd 1 --hdd-bytes 20G --hdd-noclean --hdd-opts direct（direct启用 O_DIRECT）
为什么 --metrics-brief 输出比 top 更能定位硬件问题
stress-ng 内置的指标采集不依赖用户态采样，而是直接读取 /sys/devices/system/cpu/cpu*/topology/ 和 /proc/stat 等内核接口，能暴露微秒级调度延迟、NUMA 迁移次数、TLB miss 率等 top 完全看不到的信号。
- 加
--metrics-brief --timeout 60s后，末尾会输出类似：cpu0: 99.2% user, 0.8% sys, 0.0% idle, 123456789 TLB misses - 若某核
TLB misses暴涨而user却卡在 70%，大概率是 L1D 缓存失效或页表遍历异常，需检查 BIOS 中的 SME/SEV 设置是否干扰 -
--metrics-brief不影响压测本身，但禁用--verbose，否则日志刷屏掩盖关键指标
常见崩溃现象与对应 stress-ng 参数修正
硬件不稳定往往不表现为 panic，而是静默错误：DMA corruption、PCIe AER 错误、uncorrectable ECC。这些需要针对性触发，而非泛泛地“把 CPU 打满”。
- 系统随机 hang 住（键盘无响应但 ping 可通）→ 很可能是 PCIe link reset 失败：
stress-ng --io 2 --io-opts aio,dsync --timeout 300s（aio触发高队列深度，dsync强制落盘） - dmesg 出现
Hardware error from APEI或Uncorrectable memory error→ 改用--vm 1 --vm-bytes 90% --vm-keep --vm-method rand（rand方法频繁跨页访问，放大内存颗粒缺陷） - GPU 渲染错乱或 X11 freeze → 必须隔离 GPU 内存压力：
stress-ng --vm 1 --vm-bytes 4G --vm-keep --vm-method touch（touch持续写入新页，逼迫 GPU 驱动重映射）
真正难的是让 stress-ng 的负载模式和你的硬件故障窗口对齐——比如某块主板在 PCIe 3.0 x4 SSD 持续 4K 随机写 3 分钟后才会丢帧，那就得用 --hdd 1 --hdd-bytes 1G --hdd-opts direct,rand,write 循环执行并监控 dmesg -T | grep -i "nvme\|aer"。参数调得越细，越容易复现那个“偶尔出问题”的瞬间。
