有没有办法限制“git gc”的内存量用途？

Question

我在共享主机上托管 git 存储库。我的存储库中必然有几个非常大的文件，每次我尝试在存储库上运行“git gc”时，我的进程都会因使用过多内存而被共享托管提供商杀死。有没有办法限制 git gc 可以消耗的内存量？我希望它可以用内存使用来换取速度，并且只需花更长的时间来完成工作。

Answer 1

Git repack 的内存使用量为：(pack.deltaCacheSize + pack.windowMemory) × pack.threads。各自的默认值是 256MiB、无限制、nproc。

增量缓存没有什么用处：大部分时间都花在了滑动窗口上计算增量上，其中大部分都被丢弃了；缓存幸存者以便它们可以重用一次（写入时）不会改善运行时间。该缓存也不在线程之间共享。

默认情况下，窗口内存通过 pack.window (gc.aggressiveWindow) 进行限制。限制这种打包方式是一个坏主意，因为工作集的大小和效率会有很大差异。最好将两者提高到更高的值，并依靠 pack.windowMemory 来限制窗口大小。

最后，线程具有分割工作集的缺点。降低 pack.threads 并增加 pack.windowMemory 以使总数保持不变应该可以缩短运行时间。

repack 还有其他有用的可调参数（pack.depth、pack.compression、位图选项），但它们不会影响内存使用。

Answer 2

您可以使用关闭 delta 属性来仅对这些路径名的 blob 禁用增量压缩：

在 foo/.git/info/attributes 中（或 foo.git/info/attributes 中） code> 如果它是一个裸存储库）（请参阅 gitattributes 中的增量条目并参阅 gitignore 用于模式语法）：

/large_file_dir/* -delta
*.psd -delta
/data/*.iso -delta
/some/big/file -delta
another/file/that/is/large -delta

这不会影响存储库的克隆。要影响其他存储库（即克隆），请将属性放入 .gitattributes 文件中，而不是（或除了）info/attributes 文件中。

Answer 3

Git 2.18 (Q2 2018) 将改善 gc 内存消耗。
在 2.18 之前，“git pack-objects”在完成工作时需要分配大量的“struct object_entry”：缩小其大小对性能有很大帮助。
这会影响 git gc。

请参阅提交f6a5576，提交 3b13a5f, 提交0aca34e，提交 ac77d0c，提交27a7d06，提交 660b373，提交 0cb3c14，提交898eba5，提交 43fa44f，提交 06af3bb , 提交 b5c0cbd, 提交 0c6804a, 提交fd9b1ba，提交 8d6ccce，提交 4c2db93（2018 年 4 月 14 日），作者：Nguyễn Thái Ngọc Duy (pclouds)。
^{（由 Junio C Hamano -- gitster -- 合并于 提交 ad635e8，2018 年 5 月 23 日）}

pack-objects：重新排序成员以缩小struct object_entry

以前的补丁在这个结构中留下了很多洞和填充。
此补丁重新排序成员并将结构缩小到 80 字节
（在 64 位系统上从 136 字节开始，在完成任何字段收缩之前）
有 16 位空闲（当 in_pack_header_size 时还有更多位
我们真的用完了位）。

这是一系列内存减少补丁中的最后一个（请参阅
“pack-objects：一些关于 struct object_entry 的文档”
第一个）。

总的来说，他们减少了 linux-2.6.git 上的重新打包内存大小
3.747G 至 3.424G，减少了 320M 左右，减少了 8.5%。
重新打包的运行时间在整个系列中保持不变。
Ævar 在他可以访问的大型 monorepo（大于 linux-2.6.git）上进行的测试显示，性能下降了 7.9%，因此总体预期改进应该在 8% 左右。

---

使用 Git 2.20（2018 年第 4 季度），可以更轻松地检查一个分叉中存在的对象是否与未出现在同一分叉存储库中的另一个对象形成增量。

请参阅提交 fe0ac2f、提交 108f530, 提交f64ba53（2018 年 8 月 16 日），作者：Christian Couder (chriscool)。
帮助者：Jeff King (peff) 和 Duy Nguyen (pclouds)。
请参阅 提交 9eb0986、提交 16d75fa, 提交28b8a73，提交 c8d521f（2018 年 8 月 16 日），作者：杰夫·金 (peff)。
帮助者：Jeff King (peff) 和 Duy Nguyen (pclouds)。
^{（由 Junio C Hamano -- gitster -- 合并于 提交 f3504ea，2018 年 9 月 17 日）}

pack-objects：将“layer”移动到“struct Packing_data”

这将“struct object_entry”的大小从 88 个字节减少到 80 个字节，从而使打包对象更加高效。

例如，在具有 12M 对象的 Linux 存储库上，即使不使用图层功能，git pack-objects --all 也需要额外的 96MB 内存。

---

请注意，Git 2.21（2019 年 2 月）修复了一个小错误：“git pack-objects”错误地使用了未初始化的互斥体，该错误已得到纠正。

请参阅 提交 edb673c、提交 459307b（2019 年 1 月 25 日），作者： Patrick Hogg ( ``）。
帮助者：Junio C Hamano (gitster)。
^{（由 Junio C Hamano -- gitster -- 合并于 提交 d243a32，2019 年 2 月 5 日）}

pack-objects：将读取互斥体移动到packing_data结构

ac77d0c ("pack-objects: 收缩结构体object_entry中的大小字段”，
2018-04-14) 在新版本中添加了 read_lock/read_unlock 的额外用法
引入了 oe_get_size_slow 以确保并行调用中的线程安全
try_delta()。
不幸的是 oe_get_size_slow 也用于串行
代码，其中一些在第一次调用之前被调用
ll_find_deltas。
因此，不保证读取互斥锁会被初始化。

通过将读取互斥体移至 packing_data 并初始化来解决此问题
它位于在cmd_pack_objects中初始化的prepare_packing_data中。

---

Git 2.21（2019 年 2 月）仍然找到另一种方法来缩小包的大小，通过“git pack-objects”学习另一种算法来计算集合
要发送的对象，将生成的包文件进行交换以保存
有利于小推送的遍历成本。

pack-objects：创建pack.useSparse设置

“git pack-objects”中的“--sparse”标志更改了算法
用于将对象枚举为对个体来说更快的对象
用户推送仅改变一小部分圆锥体的新对象
工作目录。
不建议对服务器使用稀疏算法，因为服务器可能会发送出现在整个工作目录中的新对象。

创建一个“pack.useSparse”设置来启用此新算法。
这允许“git push”使用此算法而无需传递
'--sparse' 标志一直贯穿 run_command() 的四个级别
来电。

如果设置了“--no-sparse”标志，则此配置设置为
被覆盖。

配置包文档现在包括:

pack.useSparse：

当为 true 时，Git 将默认使用 '--sparse' 选项
当存在“--revs”选项时，使用“git pack-objects”。
该算法仅遍历出现在引入新对象的路径中的树。

在计算一个包以发送小额零钱时，这可以带来显着的性能优势。

但是，如果包含的提交包含某些类型的直接重命名，则可能会向包文件中添加额外的对象。

请参阅“git Push 对于大型存储库来说非常慢”举个具体的例子。

---

注意：正如 Git 2.24 中所评论的，像 pack.useSparse 这样的设置仍然是实验性的。

请参阅提交aaf633c，提交 c6cc4c5, 提交ad0fb65，提交 31b1de6，提交 b068d9a，提交 7211b9e（2019 年 8 月 13 日），作者：Derrick Stolee (derrickstolee) 。
^{（由 Junio C Hamano -- gitster -- 合并于 提交 f4f8dfe，2019 年 9 月 9 日）}

repo-settings：创建feature.experimental设置

“feature.experimental”设置包括未承诺成为默认值的配置选项，但可以使用其他测试g。

更新以下配置设置以采用新的默认值，并
如果尚未使用 repo_settings 结构，请使用它们：

• 'pack.useSparse=true'
• 'fetch.negotiationAlgorithm=跳过'

---

使用 Git 2.26 (Q1 2020)，方式“git pack-objects" 重用现有包中存储的对象来生成其结果改善了。

请参阅提交 d2ea031、提交 92fb0db, 提交bb514de，提交 ff48302，提交 e704fc7，提交 2f4af77，提交 8ebf529，提交 59b2829，提交 40d18ff，提交 14fbd26 （2019 年 12 月 18 日），提交 56d9cbe，提交 bab28d9（2019 年 9 月 13 日），作者 杰夫·金 (peff)。
^{（由 Junio C Hamano -- gitster -- 合并于 提交 a14aebe，2020 年 2 月 14 日）}

pack-objects：改进部分包文件重用

^{帮助者：Jonathan Tan
签字人：杰夫·金
签字人：Christian Couder}

重用现有包文件中的增量的旧代码只是尝试逐字转储包的整个片段。这比实际将物品添加到装箱单的传统方法要快，但它并不经常起作用。这个新代码实际上是在寻求中间立场：为每个对象做一些工作，但比我们传统上做的要少得多。

新代码的一般策略是从我们将包含的包文件中创建对象的位图，然后对其进行迭代，完全按照磁盘包中的方式写出每个对象，但是不将其添加到我们的包列表中（这会消耗内存，并增加增量的搜索空间）。

一个复杂的问题是，如果我们省略了一些对象，我们就无法针对我们不发送的基础设置增量。因此，我们必须检查 try_partial_reuse() 中的每个对象，以确保我们拥有其增量。

关于性能，在最坏的情况下，我们可能会交错发送或不发送对象，并且我们将拥有与对象一样多的块。但实际上我们会发送大块。

例如，在 GitHub 服务器上打包 torvalds/linux 现在重用了 650 万个对象，但只需要约 5 万个块。

---

在 Git 2.34（2021 年第 4 季度）中，git repack 本身（由 git gc 使用）受益于内存使用量的减少。

请参阅 提交 b017334、提交 a9fd2f2, 提交a241878（2021 年 8 月 29 日），作者：Taylor Blau (ttaylorr)。
^{（由 Junio C Hamano -- gitster -- 合并于 提交 9559de3，2021 年 9 月 10 日）}

builtin/pack-objects.c：删除重复的哈希查找

^{签字人：Taylor Blau}

在08cdfb1的原始代码中（“pack-objects - -keep-unreachable”，2007-09-16，Git v1.5.4-rc0 -- merge），我们将每个对象添加到类型为 ``obj->type, 的装箱清单中，其中 obj 来自 lookup_unknown_object( )。
除非我们已经查找并解析了该对象，否则这将是 OBJ_NONE。
没关系，因为 oe_set_type() 将 type_valid 位设置为“0”，并且我们稍后会确定实际类型。

因此，我们在对象查找中唯一需要的是访问 flags 字段，以便我们可以使用 OBJECT_ADDED 标记我们已添加对象，以避免添加再次获取它（我们可以直接传递 OBJ_NONE ，而不是从对象中获取它）。

但是 add_object_entry() 已经拒绝重复项！自 7a979d9 （“精简包 - 创建缺少增量基础的包文件.", 2006-02-19, Git v1.3.0-rc1 -- 合并 ），但是 08cdfb1 没有利用它。
此外，要进行 OBJECT_ADDED 检查，我们必须在 obj_hash 中进行哈希查找。

因此，我们可以完全放弃 lookup_unknown_object() 调用，和 OBJECT_ADDED 标志，因为我们在这里触及的位置是唯一检查它的位置。

最后，我们执行相同数量的哈希查找，但还有一个额外的好处，即我们不会浪费内存分配 OBJ_NONE 对象（如果我们正在遍历，我们需要它最终，但此代码路径的重点不是遍历）。

---

fetch.negotiationAlgorithm 和 feature.experimental 配置变量之间的交互已在 Git 2.36（2022 年第 2 季度）中得到纠正。

请参阅提交 714edc6、提交 a9a136c, Elijah Newren (newren)。
^{（由 Junio C Hamano -- gitster -- 合并于 提交 70ff41f，2022 年 2 月 16 日）}

repo-settings：重命名传统默认值fetch.negotiationAlgorithm

^{签字人：伊利亚·纽伦}

将传统的默认 fetch.negotiationAlgorithm 命名为“consecutive”。
还允许选择“default”，让 Git 在选项之间做出决定（目前，如果 feature.experimental 为 true，则选择“skipping”，并且否则为“连续”）。
相应地更新文档。

git config 现在包含在其 手册页：

控制本地存储库中有关提交的信息的方式
在协商要发送的包文件的内容时发送
服务器。

• 设置为“连续”以使用遍历算法
  在连续提交中检查每一项。
• 设置为“跳过”
  使用跳过提交的算法来努力收敛
  更快，但可能会导致包文件过大；或设置
  到“noop”根本不发送任何信息，这几乎将
  当然会导致包文件过大，但会跳过
  谈判步骤。
• 设置为“default”以覆盖所做的设置
  之前并使用默认行为。

一般情况下默认为
“consecutive”，但如果 feature.experimental 为 true，则
默认为“跳过”。
未知值将导致“git fetch”
错误输出（未知的获取协商算法）。

---

在 Git 2.44（2024 年第 1 季度）中，包文件数据的流传输过去只能通过具有多个包文件的存储库中的单个主包来完成。
它已被扩展为允许从其他包文件中重用。这会影响 gc。

请参阅 提交 ba47d88、提交 af626ac, 提交9410741，提交 3bea0c0， nofollow noreferrer“> commit B1E33333068247DDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDEB69457C249DDEE7A1“ REL =“ Nofollow Noreferrer”> commit B1E3333 5e6ad2“ rel =” nofollow noreferrer”>提交ED9F414 ，， /git/comm/ca0fd69e37132ACDDDC457B96A91EF528C7C312B“ rel =“ nofollow noreferrer”> commit Ca0fd69 ， commit 4805125 ， github.com/git/git/commit/D1D701EB9CE2293588AABF34C69335D49640F968“ rel =“ nofollow noreferrer”> commitd d1d701e 2102185E7450C54A3637FDEE0“ rel =” nofollow noreferrer">commit 5e29c3f, commit 83296d2, nofollow noreferrer“> commit 35E156B E5D48BF38BC0E1F44F4DAA7C8E0F75CD9296D020“ rel =“ nofollow noreferrer”>提交E5D48BF ， commit dab6093 ， commits 6cdb67b 12d2952305a4793d7b43f“ rel =” nofollow noreferrer“> commit 66f0c71 （2023年12月14日）作者： 。
^{（由 Junio C Hamano -- gitster -- 合并于}

位图包

^{签名：泰勒·布劳}

现在，Pack-bitmap和Pack-Objects代码都准备好处理标记和使用来自多个位图包的对象进行逐字重复使用，允许从所有位映射的包装中标记对象作为符合重用的资格。

。

reuse_partial_packfile_from_bitmap（）函数，我们不再仅标记第一个对象的重用位置为零的包，而是标记MIDX中包含的任何包装作为重复使用候选者。 /p>

在新脚本（T5332）中提供少数测试用例，以对多包重复使用行为有趣的行为，以确保我们正确执行了所有之前的所有步骤。

git config 现在包含在其人页：

当true或“ 单个”时，以及可及性位图为
已启用，包装对象将尝试发送位图的一部分
Packfile逐字。
当“ Multi ”，当多包时
可及性位图可用，包对象将尝试发送
MIDX中所有包装的一部分。

如果只有一个包位图，并且
pack.AllowPackReuse 设置为“多”，仅重复使用部分
位图包装。这可以将内存和CPU使用降低到
提供提取，但可能会导致发送稍大
包。
默认为true。

---

与Git 2.44（Q1 2024），将用户选择到多彼得重复使用实验中，

请参见 href =“ https://github.com/git/git/commit/7C01878EEB15E8DD75F0262BDFBDFB3249C85A30A4A” rel =“ nofollow noreferrer”> norelollow noreferrer“> commition 7c01878 05年5月5日（05年5月5日） /ttaylorr“ rel =” nofollow noreferrer“> taylor blau（ ttaylorr ）。
^{（由 Junio C Hamano -- gitster -- 合并于}

通过功能重复使用。经验

^{签名：泰勒·布劳}

现在支持多包重复使用，请通过功能启用它。经典配置除了经典 pack.allowpackreuse 。

这将允许更多用户尝试新行为，这些新行为可能不知道现有 pack.allowpackreuse 配置选项。

带有值的枚举 no_pack_reuse， single_pack_reuse， and multi_pack_reuse 在

git config 现在包含在其人页：

• pack.AllowPackReuse = Multi 可能会通过从多个包中重用对象而不是一个。

来改善创建包的时间。

Answer 4

我使用了此链接<的说明/a>.与 Charles Baileys 建议的想法相同。

命令的副本在这里：

git config --global pack.windowMemory "100m"
git config --global pack.packSizeLimit "100m"
git config --global pack.threads "1"

这对我在具有共享托管帐户的 hostgator 上有用。

Answer 5

是的，查看 git config 的帮助页面并查看 pack.* 选项，特别是 pack.depth、 pack.window、pack.windowMemory 和 pack.deltaCacheSize。

它不是一个完全精确的大小，因为 git 需要将每个对象映射到内存中，因此无论窗口和增量缓存设置如何，一个非常大的对象都可能导致大量内存使用。

您可能会更好地在本地打包并“手动”将打包文件传输到远程端，添加 .keep 文件，这样远程 git 就不会尝试完全重新打包所有内容。