git 大仓库内存耗尽速查：pack 时 OOM 的六个根因与调优

更新时间：2026-10-24。FAQ 速查页，面向在巨型仓库上跑 git clone / git gc / git repack / git push 时被 fatal: Out of memory, malloc failed 或 fatal: pack-objects died of signal 9 挡住的同学。git 内存耗尽的含义一句话：Git 在做对象打包（pack）时要把大量对象读进内存做 delta 压缩，窗口开多大、线程开几条直接决定峰值内存，默认参数在几万兆的大仓库上会把机器内存吃光，被 OOM killer 或 Git 自己的 malloc 检查击毙。收敛在六根轴上：windowMemory 默认不设限导致单线程吃爆、threads 多线程内存按份翻倍、大二进制文件进了 pack 流程、浅克隆把历史砍浅引发的连锁反应、没用 filter=blob:none 部分克隆硬扛全量、以及 gc 时机不当叠加内存峰。本篇主线工具是 git config 的 pack 系列参数——调参是这类报错的第一处置手段。

本文要回答的问题

• Out of memory, malloc failed 是机器内存不够还是 Git 参数不对？
• pack-objects died of signal 9 里的 signal 9 是谁发的？
• core.packedGitLimit / pack.windowMemory / pack.threads 各自管什么？
• 浅克隆 --depth 1 能省内存吗，代价是什么？
• --filter=blob:none 和浅克隆的区别是什么，哪个更适合 CI？

一、报错原文与典型现象

git 内存耗尽家族的几种真实措辞如下（路径以 /proj/demo 占位，远端以 git.example.com 占位）：

$ git -C /proj/demo gc --aggressive
Counting objects: 100% (812345/812345), done.
fatal: Out of memory, malloc failed

$ git clone git@git.example.com:group/huge-repo.git /proj/demo
remote: Enumerating objects: 100%, done.
error: pack-objects died of signal 9
fatal: the remote end hung up unexpectedly

$ git -C /proj/demo repack -a -d
fatal: Out of memory, malloc failed (tried to allocate 18446744073709551615 bytes)

$ git -C /proj/demo push
fatal: Out of memory, malloc failed
error: failed to push some refs to 'git@git.example.com:group/huge-repo.git'

读报错抓三个信号：malloc failed 是 Git 主动检查分配失败、和平退出，说明单进程要的内存超了物理极限；died of signal 9 是 Linux OOM killer 动的手，整条进程组被杀，往往伴随系统日志里的 oom-kill 记录；push/clone 时报错则说明打包发生在本地发送或远端回传阶段，调参位置不同。三种措辞对应三种战场，别在一个地方反复试。

二、病因处置速查表

报错现象 / 场景	可能原因	快速验证	处置
gc/repack 报 malloc failed	pack.windowMemory 未设限，窗口吃爆	git config pack.windowMemory 无输出	设 pack.windowMemory=256m
多核机器上 pack 全被杀	pack.threads 过高，内存按线程翻倍	git config pack.threads 值大	降到 1-2 或 pack.threads=1
仓库里有 GB 级二进制进 pack	大文件无 delta 可压，全量进内存	git rev-list --objects --all | cat-file 查大对象	大文件转 LFS，git lfs migrate
clone 巨型仓库中途信号 9	全量历史 + 全量 blob 一次拉	git count-objects -vH 看体量	浅克隆 --depth 1 或 --filter=blob:none
浅克隆后 log/blame 报错	历史被砍浅，相对引用越界	git rev-list --count HEAD 极小	按需 git fetch --unshallow 补历史
服务器端 push 被拒 OOM	远端 receive-pack 打包内存不足	服务端 dmesg 有 oom-kill	服务端设 pack.windowMemory / core.packedGitLimit
gc 在高峰期跑内存翻倍	业务进程与 gc 同时吃内存	跑前 free -m 看余量	错峰跑 gc，或先 git prune 减量
老版本 Git 大仓库不稳	老版本 pack 内存管理缺陷	git --version 低于 2.30	升级 Git，新版本默认更克制

三、排查决策图

下面这张图是标准排查路线，颜色按角色区分：红是报错入口与命中的根因，蓝是排查动作，绿是通过分支，橙是修复动作，紫是防复发沉淀。

读这张图抓主线顺序：先查 Git 自己的内存参数（windowMemory/threads 两条命令见底），参数已经限了还爆才去查「仓库里是不是有不该进 pack 的大对象」，最后才是「这个仓库的体量是否压根该用浅克隆或部分克隆而不是硬扛全量」。九成 case 在第一步收敛——pack 类 OOM 的病，根子几乎都在「默认参数对大仓库不设防」。

四、逐条排查展开

第一条：windowMemory 不设限——单线程吃爆的最大头。 git gc、git repack、远端 pack-objects 的核心是 delta 压缩：拿一个滑窗在对象流上找相似块，窗口越大压得越狠、吃得越多。老版本默认不设上限，窗口可以长到吞掉整段历史。处置一句话：

git config pack.windowMemory 256m
git config pack.packSizeLimit 2g
git config core.packedGitLimit 512m

三条含义：pack.windowMemory 是单次 delta 窗口的内存上限；pack.packSizeLimit 是单个 pack 文件的体积上限，超限自动切分；core.packedGitLimit 是映射 pack 文件进虚拟内存的上限。设完重跑 gc，内存曲线立刻变平。

第二条：threads 翻倍——多核机器的隐形放大器。 pack.threads 默认按 CPU 核数走，每个线程各吃一份 windowMemory 份额：8 核 256m 窗口就是约 2GB 峰值。小内存机器上把线程压下来：

git config pack.threads 1        # 最省内存，速度换稳定
git config pack.threads 2        # 折中档

CI 构建机、容器里跑 git 操作时尤其要压——容器内存配额被超就是 cgroup OOM，报错的还是 signal 9。

第三条：大二进制进 pack——该走 LFS 的走了对象库。 视频、模型权重、编译产物、PSD 这类文件没有 delta 可压，每次小改都是全量新对象，pack 时被整个读进内存。查证：

git rev-list --objects --all | git cat-file --batch-check='%(objecttype) %(objectsize) %(rest)' | sort -k2 -n -r | head

处置：历史里的大文件用 git lfs migrate import --include="*.zip,*.psd" 迁去 LFS，新增大文件直接 git lfs track。注意迁移改写历史，需要团队协调强推，操作前备份。迁完后旧历史里的大对象还会留在 pack 里，要再跑一次 git gc --aggressive --prune=now 才真正瘦下来——此时前面设好的 windowMemory 护栏依然生效，两步不冲突。

第四条：浅克隆——用砍历史换内存与速度。 CI 只编当前代码不要历史，直接：

git clone --depth 1 git@git.example.com:group/huge-repo.git /proj/demo

代价要清楚：HEAD~n 相对引用越界报 bad revision（对照 bad revision 速查）、blame 只剩一层、push 受限制。要回补历史用 git fetch --unshallow 或 --deepen 500 分级加深。

第五条：filter=blob:none——部分克隆，比浅克隆更优雅的减重。 只要树与提交、不要文件内容本体，文件按需再取：

git clone --filter=blob:none git@git.example.com:group/huge-repo.git /proj/demo

与浅克隆的本质区别：历史完整（log、blame、相对引用都正常），缺的只是 blob 内容、用到才按需拉取。需要 Git ≥2.19 且服务端支持 partial clone。CI 与开发机本地都想省内存时，这是首选；只要最新快照不要历史时才选浅克隆。

第六条：gc 时机与版本——叠加峰与老缺陷。 两个收尾点。其一：git gc --aggressive 在业务高峰期跑，业务进程与 gc 峰值叠加直接顶爆——把 gc 排到低峰，跑前 free -m 确认余量，容器里还要留足 cgroup 配额。其二：2.30 之前的老版本 pack 内存管理有缺陷，大仓库上不稳，git --version 低于此线先升级——版本问题的更多场景见 git 仓库版本不兼容速查。还有一个容易忽略的放大器：跑 gc 前如果刚做过大批量 rebase 或 filter-repo 改写历史，悬空对象会让 gc 的工作集翻倍，先 git reflog expire --expire=now --all 再 git prune，把待清对象量降下来再跑主流程。

五、规范做法与预防

• pack 三参数常驻配置：windowMemory / packSizeLimit / packedGitLimit 按机器内存设好，写进系统级 git config --system，新机器开箱即有护栏。
• 大文件入库前拦截：pre-commit 钩子或服务端 pre-receive 拒收超阈值文件，引导走 LFS，从源头不让大对象进 pack。
• CI 默认部分克隆：流水线统一 --filter=blob:none，只要产物的任务再叠加 --depth 1，内存与带宽双省。
• gc 排低峰：定时任务跑 gc 避开业务高峰，跑前确认内存余量；容器环境把 git 操作放进独立配额。
• 大仓库操作前看体量：git count-objects -vH 一眼看到 pack 体积与对象数，心里有数再动手。

这一篇在知识体系里的位置

本篇是 Git 排错速查簇的资源耗尽篇，定位「pack 阶段内存超物理极限」：引用与路径类报错看 bad revision 速查 与 pathspec did not match 速查；仓库版本不认看 git 仓库版本不兼容速查；连远端够不着看 git clone 卡死超时速查；推送被拒看 git push rejected 速查；配置文件写法出错看 gitconfig 与 gitignore 写法错误速查；合并两条无共同祖先的历史看 refusing to merge unrelated histories 速查；克隆与远端配置的基础见 config、init、clone 与 remote、pull、push。

一句话总结

git 大仓库内存耗尽的本质是「pack 窗口与线程把内存吃超了」：先设 pack.windowMemory=256m、pack.threads=1 或 2、core.packedGitLimit 三条护栏重跑，仍爆就查仓库里的大二进制转 LFS，CI 与日常克隆直接上 --filter=blob:none 部分克隆（历史完整、blob 按需），只要快照就上 --depth 1 浅克隆。护栏常驻配置、大文件拦截在入库前、gc 排低峰，这类 OOM 基本绝迹。