stress-ng 的 --cpu 参数需配合 --cpu-method all 和 --affinity 才能真正打满逻辑核，否则因调度和频率缩放导致利用率不达标；--vm 必须加 --vm-keep 才持久占内存；--hdd 比 --io 更真实测盘，需加 --hdd-opts sync 绕过缓存。
stress-ng 的 CPU 压力测试怎么选 --cpu 参数才不白跑
stress-ng 的 --cpu 并不是“开几个核就压几个核”，它默认启动的是 cpu stressor，每个 worker 运行一个计算密集型循环（比如 sqrt() 或 sin()），但实际 CPU 占用率受调度、频率缩放、Turbo Boost 影响很大。常见错误是只写 stress-ng --cpu 4，结果 top 里看到 300% 而非 400%，甚至某些核心空闲。
-
--cpu 4启动 4 个独立 worker，但不绑定到特定 CPU 核心，可能被调度器挤到同一物理核上 - 想真正打满所有逻辑核，得配合
--cpu-method all（启用全部可用算法）+--affinity（强制绑核） - 如果目标是模拟持续高负载而非峰值，加
--timeout 60s和--metrics-brief看真实平均利用率 - 注意：Intel 的
intel_idle驱动或 AMD 的acpi_cpufreq可能让空闲核快速降频，导致stress-ng --cpu N初期飙升、后期回落——这不是 bug，是电源管理在生效
stress-ng --cpu 8 --cpu-method all --affinity --timeout 30s --metrics-brief
内存压力测试别只用 --vm，--vm-keep 才决定是否真占内存
--vm 默认行为是分配内存 → 写入 → 释放 → 重分配，所以 free -h 看不到长期占用，ps aux 里 RSS 也忽高忽低。很多人误以为没压上，其实是 stress-ng 在“反复申请释放”，内核的 LRU 和 page reclaim 机制让它看起来“不持久”。
-
--vm-keep是关键开关：开启后分配的内存不会被 munmap，RSS 稳定上涨直到 OOM 或达到--vm-bytes限制 - 默认每个
--vmworker 分配 256MB，想压满 16GB 内存？得算清楚：--vm 64 --vm-bytes 256M --vm-keep（64 × 256MB = 16GB） - 不加
--vm-keep时，--vm-bytes只控制单次分配大小，不是总用量 - 注意：如果系统启用了
swappiness=1或 cgroup memory limit，--vm-keep可能触发 swap 或被 OOM killer 杀掉，得提前查/proc/sys/vm/swappiness和cat /sys/fs/cgroup/memory/memory.limit_in_bytes
IO 压力测试用 --io 不如直接用 --hdd + --hdd-opts sync
--io stressor 实际调用的是 posix_fadvise() 和 read()/write() 循环，但它默认使用 buffered I/O，大量数据会卡在 page cache 里，iostat -x 1 看不到真实磁盘 IO（%util 低、await 也不高），容易误判存储性能。
- 真实测盘？用
--hdd：它直接 open(O_DIRECT) + write()，绕过 page cache，iostat和iotop数据才可信 -
--hdd-opts sync强制每次 write() 后fsync()，模拟数据库类同步写场景；不加则类似日志追加（异步刷盘） -
--hdd-bytes控制每个 worker 写入总量，不是文件大小——它会反复覆写同一块区域，避免磁盘爆满 - 坑点：NVMe 盘上
--hdd可能触发控制器队列饱和，iostat显示qcut> 0，此时需配合--hdd-ops限速，否则测试失真
组合压测模板要防资源抢占，--class 和 --sequential 得搭配用
想同时跑 CPU + 内存 + IO？直接 stress-ng --cpu 4 --vm 2 --hdd 1 很危险：所有 stressor 默认并发启动，IO worker 可能把 CPU worker 挤出运行队列，top 看起来像“CPU 没压上”，其实是调度干扰。
-
--class io/--class cpu只是标签，不影响调度；真正可控的是--sequential（串行启动）和--timeout（统一收口） - 推荐模板：
stress-ng --cpu 4 --vm 2 --vm-keep --hdd 1 --hdd-opts sync --timeout 60s --metrics-brief --verbose - 加
--verbose能看到每个 worker 启动时间戳，方便排查是否某类 stressor 启动失败（比如--hdd因权限/空间不足静默跳过） - 更稳的做法：分阶段压，用 shell 控制节奏，比如先
stress-ng --cpu 4 --timeout 30s，再stress-ng --vm 4 --vm-keep --timeout 30s，避免 OOM killer 误杀关键进程
复杂点在于：stress-ng 的每个 stressor 对内核子系统的影响路径不同，CPU 压的是 scheduler 和 frequency scaling，内存压的是 buddy allocator 和 LRU，IO 压的是 block layer 和 device queue——它们不是线性叠加，而是互相扰动。跑一次就断言“系统扛得住”，往往漏掉了调度延迟、page fault spike 或 I/O completion 中断堆积这些隐性瓶颈。
