并行测试 CPU 满载：先查默认并发，再决定扩容

最近，我看到一台兼顾日常交互和后台工作的机器突然接近满载。直觉很容易指向硬件：是不是处理器不够，要不要再加一些核心？回到任务时间、测试日志和进程现场后，问题变得具体了：一轮回归测试按机器报告的逻辑 CPU 数启动并行进程，几乎把当时可用的计算空间都用上了。

我最后没有先扩容，而是调低这条测试入口的默认并发，并验证它确实传到了执行进程。这个调整不删测试，也不是给整台机器设置硬性资源上限。它只解决一个更小、也更常见的问题：单个后台任务的默认值，是否忘了同一台机器上还有人正在使用其他服务？

先把满载的时间，和工作的时间对上

CPU 曲线升高本身，只说明一个现象。为了判断责任，我先找与该时间窗口对应的任务，再核对测试日志、进程关系和结束后的资源变化。

这次记录能连成一条较清楚的链：回归测试在曲线上升窗口启动；日志明确报告了多进程并发；现场看到同一父进程下有多组忙碌的 Python 子进程；测试结束后，随后采样的 CPU 空闲比例又回升。

这比“最近装了某个工具，所以一定是它”更有说服力。但证据仍有边界：部分子进程在后续读取前已经退出，没有保存到完整命令行，不能假装逐个进程都追查过；短时回落也不能证明机器从此永远轻松。

另一个重要动作，是把不同压力拆开看。此前还出现过磁盘等待，不能为了故事简单，就把所有慢响应都归到这一轮 CPU 满载上。CPU 忙、存储等待和内存不足需要不同证据，不能共用一个根因标签。

我继续读了当前执行器的入口。它允许显式指定并发；没有指定时，便从环境变量或逻辑 CPU 数取得默认值。这是一种可以理解的吞吐优先策略，却未必适合同时承担交互工作的机器。

Python 官方文档把 os.cpu_count() 的结果定义为系统的逻辑 CPU 数，并另外提供 process_cpu_count() 描述当前进程调用线程可使用的逻辑 CPU 数。两者都不是“此刻可以放心借给后台测试的空闲配额”。[1]

于是，加核并不必然让交互得到余量。如果任务一直按照“报告多少 CPU，就启动多少进程”的策略运行，增加核心也可能同时增加测试进程。它可能让整轮更快结束，却没有主动为其他工作留出空间。

这里不是说扩容无效。专用测试机器和共享工作机器追求的目标不同。专用机器可以优先追求测试吞吐；共享机器还要考虑前台响应、其他服务，以及同一时刻的任务叠加。先辨认目标，再决定是否扩容，比看到一个峰值就买硬件更稳妥。

只在配置文件里写一个较小的数字，不足以证明调整生效。我把验证拆成三个层次。

第一层是入口。启动新的终端环境，避免把旧会话里已经存在的环境变量当作新默认的证据；再读取实际传给子进程的值。

第二层是行为。使用少量低 CPU 的独立测试样本，为每个样本记录开始和结束时刻，按时间区间计算同时运行的峰值。这样验证的是“执行器究竟同时启动了多少任务”，而不是只相信启动日志上的参数。

第三层是可调整性。除了检查默认并发，还分别用明确参数提高和降低它，确认覆盖仍然有效；同时核对全部小样本都完成，子进程都退出，临时样本已清理。

这次记录支持的结论是：已配置入口的默认值确实被读取，小样本峰值与请求的并发一致，显式调整也有效。它不支持另一个更诱人的结论——整台机器的 CPU 已被统一限制，或者实际交互延迟已经长期改善。后两件事需要不同的验证。

降低测试进程的默认并发以后，我仍然发现一个范围外的阶段：启动脚本会先做字节码预编译，这个步骤使用自己的并行参数，没有消费刚调整的测试配置。

当前 Python compileall 官方文档明确提供独立的 -j N 参数来控制编译工作进程；其中自动选择的取值又有自身语义。因此，“测试参数已改”不能推出“启动前后所有阶段都改了”。[2]

还有三种同样需要留意的情形：

测试内部启动的线程或额外进程也要单独核对。我没有为了消除所有可能的峰值，顺手改整个系统或所有启动器；先把已经生效和没有覆盖的范围说清楚，才是这次调整可信的地方。

如果共享机器在跑测试时变得迟缓，可以先按这个顺序检查，而不是马上删测试、停服务或扩容：

低 CPU 样本适合证明调度数量，不适合证明性能收益。不要把它的总耗时当成真实回归测试的加速比；也不要用“并发数量正确”替代“用户响应确实改善”。

我这次真正完成的，不是“彻底解决机器性能问题”，而是让指定测试入口不再默认占用全部报告的 CPU，并保留按任务调整的能力。

最值得迁移的经验是：共享机器上的资源安排，要从执行器实际怎样分配工作开始查。硬件数量、单轮并发、整机资源隔离和用户体验，是四个不同的问题。把它们分开，才能既不因峰值过度扩容，也不因一个默认值生效就宣布全局治理完成。

事实核验时间：2026 年 10 月 5 日。实践部分依据原始任务日志、当前入口实现和独立小样本验证记录，已移除内部系统身份、设备、路径、配置值及运行规模。本文由作者实践与判断形成，AI 辅助整理；官方文档只支持对应机制，不为个人诊断背书。