Windows MongoDB Restore 性能排查记录

问题

Windows 每天自动 restore MongoDB 很慢。同一份约 4.8 GB、1.2 亿 documents 的 backup：

关键排查与结果

WSL 改为原生 PowerShell

最初经 WSL restore，怀疑 /mnt/... 访问 Windows 文件系统带来 I/O overhead。后来改为 Windows 原生 PowerShell，直接执行 scp、mongosh 和 mongorestore。

有改善，但仍然很慢；WSL 不是主要原因。

Windows Defender exclusion

为 MongoDB data、backup、log 目录添加 Defender exclusion。

效果不明显，不是主因。

MongoDB data 从 HDD 移到 NVMe

MongoDB 虽然安装在 C:，实际 dbPath 却在 H: 机械硬盘。restore 时 HDD disk utilization 接近 100%。将 data 移到 C: 的 NVMe SSD 后，restore 从 2 小时以上降至约 1 小时 40 分钟。

结论：MongoDB data 的写入位置是主要瓶颈。

Backup 不需要移到 SSD

Backup 仍在 H: HDD。曾考虑在 restore 前复制到 C: SSD，但手工运行同一 PowerShell script 后发现：backup 在 HDD、MongoDB data 在 NVMe 时，restore 只需约 12 分钟。

结论：无需移动 backup；关键是 MongoDB data 写入 NVMe。

Scheduled Task Priority

出现明显差异：

检查 Task XML 后发现未明确设置 priority。将其设为：

<Priority>4</Priority>

并通过真实 Task Scheduler 环境测试：

Start-ScheduledTask -TaskName "..."

restore 降至 14:05。

结论：Task Scheduler 的 priority（也会影响 I/O priority）是另一个关键因素。

其他尝试

• 检查 MongoDB Database Tools 版本、backup 文件大小、BSON 文件数量与完整性。
• 用 mongosh --eval 做自动 verification，并比对 restore document count。
• 尝试捕获 mongorestore 的 stderr/output。

PowerShell 处理 native command 的 quoting 与 stderr 较麻烦，且 mongorestore 的正常 progress 也会写 stderr，额外捕获容易造成误判。最后去除不必要的 verification，只以 mongorestore exit code 判断成功。

最终结果

2026-08-30 的真实 Scheduled Task 记录：

[2026-08-30 05:08:40] Dropping local swimdb...
[2026-08-30 05:08:42] swimdb dropped successfully.
[2026-08-30 05:08:42] Starting mongorestore...
[2026-08-30 05:22:10] MongoDB restore duration: 00:13:27
[2026-08-30 05:22:10] mongorestore completed successfully.
[2026-08-30 05:22:10] Restore completed successfully.
[2026-08-30 05:22:10] Total job duration: 00:22:07

• mongorestore：13:27
• 整个任务（含 SCP）：22:07

最终方案：

1. 将 MongoDB data 从 HDD 移到 NVMe SSD。
2. 将 Task Scheduler priority 设为 4。
3. Backup 继续放在 HDD。
4. 使用原生 PowerShell，不再通过 WSL restore。

目前 Windows restore 性能已与 Mac 基本同一水平。