关键是在不拖垮内存和不触发系统限制前提下稳定压满CPU，pack.threads推荐设为CPU物理核心数或1.5倍，避免盲目调高导致上下文切换与内存争抢。
想让 Git 在多核服务器上跑满压缩吞吐，关键不是盲目设高 pack.threads，而是让它在不拖垮内存、不触发系统限制的前提下稳定压满 CPU。默认值为 1 实际是保守策略，多数现代服务器有提升空间。
先确认你的 CPU 核心数和当前负载
盲目调高线程数反而会因上下文切换和内存争抢导致整体变慢。建议用系统命令先摸清底数：
- Linux/macOS：运行
nproc或lscpu | grep "CPU(s)"查物理核心数；观察htop看空闲 CPU 是否充足 - Windows：任务管理器 → 性能 → CPU → 查看“逻辑处理器”数量（含超线程）
- 避免在内存已超 85% 或磁盘 I/O 持续 100% 时强行加线程
设置 pack.threads 的合理区间
Git 官方文档与实战数据表明，该参数并非越高越好。推荐按场景选择：
Github Stars Analyzer
下载
抓取指定 GitHub用户的 Stars 项目，生成标准化中文 Markdown 报告。用户提及「分析 GitHub stars」「导出收藏项目」「汇总 GitHub 星标」「生成 stars 报告」或粘贴含 ?tab=stars 的链接时触发。执行通过 bash...
- 日常开发/中小型仓库（2–4 即可获得明显提速，兼顾稳定性
- 大型单体仓库（如 Windows SDK、Chromium 镜像）：可设为 CPU 物理核心数 × 1.5（例如 16 核 → 设 24），但需配合
pack.windowMemory控制单线程内存上限 - CI/CD 构建节点（内存充足、无交互）：可尝试设为逻辑处理器总数，但务必同步启用
--no-reuse-delta或降低pack.depth防止 OOM
必须配套调整的三个关键参数
pack.threads 单独调高容易引发内存爆炸或卡死。以下三项应一并配置：
-
pack.windowMemory = 512m：限制每个 delta 搜索窗口最大内存占用，防止单线程吃光所有 RAM -
pack.depth = 50：降低 delta 链长度，缩短压缩耗时，减少线程间依赖等待 -
core.fscache = true：尤其在 Windows NTFS 下显著加速对象扫描，释放 CPU 去干压缩活儿
验证是否真正榨干了多核
改完配置后，别只看 push 成功与否——要观察真实吞吐表现：
- 执行
git repack -a -d -f --window=250 --threads=8 --progress（把 8 换成你设的值） - 同时开终端运行
top -H（Linux）或资源监视器（Windows），确认多个git-pack-objects进程活跃且 CPU 占用均匀 - 对比同一操作在
threads=1和threads=N下的耗时与峰值内存（可用/usr/bin/time -v或 PowerShell 的Measure-Command）
