Win10环境下Git fetch传输约1GB后速度骤降问题求助

问题场景 #

• 环境：Win10 x64，Git for Windows 2.37.1，两块专业级SSD上的Git仓库（根目录相同，需合并内容），硬件预期传输速度≥100MiB/s
• 核心问题：
  • Fetch前60%阶段速度在5-50MiB/s波动
  • 传输约1GiB后速度骤降至2MiB/s以下，持续数小时
  • 曾参考相关文档调整参数，仅能增加跟踪输出，但传输开始后日志停止更新
  • 源仓库达数十GB，含大量不同大小BLOB；必须设置core.bigFileThreshold=1m，否则会卡在"remote: compressing ..."阶段，半小时后报内存不足错误

进程跟踪观测（Process Monitor） #

• 涉及进程：3个git.exe（调用方、接收方、发送方）+ git-upload-pack，所有进程CPU占用均低于1%
• 接收方进程：每秒执行数十甚至数百次WriteFile系统调用，每次仅使用4KB缓冲区
• 另有一个git.exe进程：每分钟被唤醒一次，执行一批1MB缓冲区的ReadFile操作后再次进入静默状态

问题根源分析 #

1. Windows/MSYS环境的数据流瓶颈 #

Git for Windows基于MSYS2模拟POSIX环境，在跨进程管道通信、文件IO的缓冲区适配上存在Windows特有的限制：

• MSYS默认管道缓冲区较小，传输大文件时会触发频繁IO系统调用，拖慢整体速度
• 接收方的4KBWriteFile窗口，大概率是MSYS层强制使用了POSIX风格的小缓冲区，未适配Windows本地IO优化逻辑

2. 大BLOB处理的连锁反应 #

设置core.bigFileThreshold=1m的操作，说明仓库中存在大量接近或超过1MB的BLOB：

• Git压缩逻辑处理大BLOB时，若缓冲区配置不合理，会导致内存占用飙升（之前的内存不足报错就是直接佐证）
• 当传输进入大BLOB密集阶段（即1GiB后），压缩/解压缩的效率瓶颈会传导到IO层面，触发系统自动缩小IO窗口以避免内存溢出，形成"速度越慢→窗口越小→速度更慢"的恶性循环

3. 本地仓库作为远程的特殊场景 #

将本地SSD仓库作为远程时，Git不会启用网络传输的优化策略（如TCP窗口缩放），而是依赖MSYS的进程间通信（IPC）机制：

• 跨SSD的本地fetch依然走git upload-pack/git fetch-pack的管道通信流程，而非直接文件系统级复制，额外增加了IO开销

解决方案建议 #

1. 调整Git缓冲区相关配置 #

尝试增大IO缓冲区和压缩缓冲区参数，缓解大BLOB处理压力：

# 调整大文件阈值为10MB
git config --global core.bigFileThreshold 10m
# 增大打包窗口内存限制
git config --global pack.windowMemory 1024m
# 增大单个打包文件大小限制
git config --global pack.packSizeLimit 2048m
# 暂时关闭压缩，验证是否为压缩环节瓶颈
git config --global core.compression 0

注：若关闭压缩后速度明显提升，说明压缩是主要瓶颈，可将core.compression调整为1（低压缩比）平衡速度与体积

2. 切换为原生Windows Git组件 #

卸载当前Git，重新安装时选择"Windows native console tools"，减少MSYS模拟带来的开销：

• 安装步骤中，在"Adjusting your PATH environment"选择"Use Git and optional Unix tools from the Command Prompt"，后续确保勾选"Windows native console tools"选项

3. 绕过Git Fetch，直接文件系统级合并 #

因两个仓库均在本地，可直接通过文件系统操作合并，再重建仓库：

• 备份目标仓库的.git目录，将源仓库所有文件（除.git）复制到目标仓库目录
• 进入目标仓库，执行git add .和git commit -m "Merge source repository content"，跳过Git fetch的管道传输开销

4. 拆分大仓库 #

针对数十GB的超大仓库，建议拆分为多个子模块（git submodule），将大BLOB单独放到子仓库中，减少单次fetch的数据量，降低压缩和IO压力

内容的提问来源于stack exchange，提问作者PasterOfMuppets