> 使用 nnUNetv2_plan_and_preprocess 处理大规模数据集（例如 704 例样本）时，程序常因多进程加载导致死锁而停滞。核心原因在于默认并发数过高引发资源竞争或 I/O 阻塞，适当降低并发数即可稳定完成全量预处理。 你在使用 `nnunetv2_plan_and_preprocess` 处理大规模样本集（比如 704 例）时，是否遇到过卡顿现象？这并非个例。许多用户反映命令长时间停滞在“Loading dataset…”阶段，CPU 占用率极低，无任何报错提示，进度条毫无响应——而将样本数降至 600 后却能顺利运行。原因很简单：默认并发数过高，导致系统 I/O 或进程调度被阻塞。 nnU-Net v2 预处理命令内部采用多进程并行（注意，是进程而非线程）。它默认会开启 min(32, CPU核心数 + 4) 个 worker——如果你使用的是 32 核服务器，那么将有 20 多个进程同时读取 NIfTI 文件、执行 spacing 校验和方向对齐等 I/O 密集型操作。磁盘与内存带宽有限，大量进程争抢读取极易引发资源竞争甚至死锁，最终表现为无响应。这正是减少样本数后能顺利运行的原因——降低并发规模，从而缓解资源争抢。 ✅ **最直接的解决方案：限制并发进程数** 手动指定 `-p` 参数，比如： ```bash nnUNetv2_plan_and_preprocess -d 201 --verify_integrity -p 4 ``` 这里需要澄清：为何使用 `-p` 而非 `-t`？因为 nnU-Net v2 的预处理主流程基于 `ProcessPoolExecutor`，`-p` 参数控制最大 worker 数量。默认值在高核数机器上容易达到 20 以上，导致 I/O 瓶颈。建议从 4 或 6 开始尝试，逐步增加，直到找到稳定性和效率的最佳平衡点。 ✅ **其他几个关键的优化方向** - **数据完整性与格式规范**：你已在使用 `--verify_integrity`，这能排除因缺失标签、形状不匹配或无效 header 导致的静默阻塞，是必不可少的步骤。 - **磁盘性能**：将数据集存放于 SSD 上，避免使用 NFS 或机械硬盘。并发条件下，随机读取延迟会被显著放大，影响整体效率。 - **监控资源**：运行期间使用 `htop` 或 `iotop` 监控，检查是否存在频繁 swap 或磁盘满载等情况。 - **升级依赖**：确保 nnunetv2 版本 ≥ 2.5.0，早期版本存在 SimpleITK 加载超时未被捕获的 bug，新版已修复，可避免意外阻塞。