问题描述
qtcloud-devops test run 在 15GB 内存的机器上反复触发 OOM killer,系统卡死后进程被强制终止。
根因
test::run 对 Rust scope 调用 cargo llvm-cov,该命令强制所有依赖(包括 ring、rustls、git2 + vendored libgit2 等 C 扩展)以 -Cinstrument-coverage 重新编译。插桩编译比普通 cargo test 内存开销高出数倍。
叠加以下因素时系统必然 OOM:
- 无并发控制:
cargo llvm-cov 使用默认并行度,不限制 job 数
- 无内存检测:启动前不检查可用内存,无法降级为普通
cargo test
- 其他进程抢占:opencode(75GB VSZ / 57GB VmData 匿名映射)占用大量虚拟地址空间,导致其 OOM 评分虚高,系统优先杀它
影响范围
- 在 15GB 内存机器上复现概率 100%
- 触发条件:
test run + 同时运行 opencode/zed-editor 等大内存进程
- 非 Rust scope(Python/Go/Dart/TS)不受影响
建议修复
- 添加
--jobs N 参数,传给 cargo llvm-cov 的 -j N
- 启动前检查
/proc/meminfo 可用内存,低于阈值时回退到 cargo test(不带覆盖)
- 限制
cargo llvm-cov 为可选的 --coverage 开关,默认只跑 cargo test
问题描述
qtcloud-devops test run在 15GB 内存的机器上反复触发 OOM killer,系统卡死后进程被强制终止。根因
test::run对 Rust scope 调用cargo llvm-cov,该命令强制所有依赖(包括ring、rustls、git2+ vendored libgit2 等 C 扩展)以-Cinstrument-coverage重新编译。插桩编译比普通cargo test内存开销高出数倍。叠加以下因素时系统必然 OOM:
cargo llvm-cov使用默认并行度,不限制 job 数cargo test影响范围
test run+ 同时运行 opencode/zed-editor 等大内存进程建议修复
--jobs N参数,传给cargo llvm-cov的-j N/proc/meminfo可用内存,低于阈值时回退到cargo test(不带覆盖)cargo llvm-cov为可选的--coverage开关,默认只跑cargo test