git fetch：无法分配内存

Question

1. 首先执行：git submodule update --init

    克隆到'_aaa'...
    检查连接... 完成。
    子模块路径'_aaa'：检出'87311dd0bb0ac9b77cd9bbac0a15671858f0cf17'

1. 然后执行：git fetch --recurse-submodules

    正在获取子模块_base
    正在获取子模块_aaa
    自动打包仓库以获得最佳性能。你也可以手动运行“git gc”。有关更多信息，请参见“git help gc”。
    对象计数：21678 已完成。
    压缩对象：100% (20602/20602)，已完成。
    写入对象：100% (21678/21678)，已完成。
    总共 21678 (差异 8973)，重用 0 (差异 0)
    删除重复对象：100% (256/256)，已完成。
    fatal: Out of memory? mmap failed: Cannot allocate memory
    fatal: Out of memory? mmap failed: Cannot allocate memory
    error: failed to run prune

上次更新大约1GB，但没有超过40MB的文件。

我将服务器上的内存从512M增加到1024M，但问题仍然存在。我还尝试了不同的git gc、窗口、压缩等操作，但都没有任何结果。

- user1934268

---

作为替代方案，您可以逐个获取子模块，而不是使用“--recurse-submodules”。 - gitaarik

我已经尝试过了，得到了相同的错误。 - user1934268

你看过这个问题了吗？https://dev59.com/9mw15IYBdhLWcg3wLIzI - gitaarik

当然，但据我所知，他们的情况不同，例如：git fetch --work 和大文件，我没有遇到过，而且我的 git 版本是 1.8.4.1。 - user1934268

Answer 1

错误本身源自于git的sha1对象处理代码，但是如果不知道mmap返回的errno，很难确切地知道发生了什么。

你可以在strace下运行你的命令，并在这里发布关于mmap失败的行。

编辑：尝试使用git config --add core.bigFileThreshold 4m（甚至更小的数字）。

core.bigFileThreshold

    Files larger than this size are stored deflated, without attempting delta compression. Storing large files without delta compression avoids excessive memory usage, at the slight expense of increased disk usage.

    Default is 512 MiB on all platforms. This should be reasonable for most projects as source code and other text files can still be delta compressed, but larger binary media files won’t be.

    Common unit suffixes of k, m, or g are supported.

https://www.kernel.org/pub/software/scm/git/docs/git-config.html

- mockinterface

---

这里是第一笔收入：<pre> ... [pid 23816] fcntl(3, F_SETFD, FD_CLOEXEC) = 0 [pid 23816] read(3, "PACK\0\0\0\2\0\0T\256", 12) = 12 [pid 23816] lseek(3, 918541449, SEEK_SET) = 918541449 [pid 23816] read(3, "n\373\t\n\341\330Tf\253\372\263/\211e%\f8\5Y(", 20) = 20 [pid 23816] mmap(NULL, 918541469, PROT_READ, MAP_PRIVATE, 3, 0) = -1 ENOMEM (无法分配内存) [pid 23816] mmap(NULL, 918541469, PROT_READ, MAP_PRIVATE, 3, 0) = -1 ENOMEM (无法分配内存) [pid 23816] write(2, "fatal: Out of memory? mmap faile"..., 58) = 58 [pid 23816] exit_group(128) = ? </pre> - user1934268

有趣。我没有明确的答案，只是看起来它显然会用完内存。你是否有一个巨大的“/idol/.client/.git/modules/_aaa/packed-refs”文件？这只是一个文本文件，用于加速 git 查找 - 而不是在文件系统中查找对象。此外，你说你尝试过git gc - 你尝试过git gc --aggressive --prune = now吗？ - mockinterface

git gc --aggressive --prune=now 计算对象: 118，完成。 压缩对象: 100% (115/115)，完成。 写入对象: 100% (118/118)，完成。 总共 118 (差异 48)，重用 70 (差异 0)。 - user1934268

git fetch --recurse-submodules 获取子模块 _base 获取子模块 _aaa 致命错误: 内存不足？mmap 失败：无法分配内存 - user1934268

你的意思是说这些是 packed-refs 文件中唯一的行吗？我们还可以尝试设置 core.bigfilethreshold 来避免将文件映射到内存中 - 这需要一个相当新的 git 版本。 - mockinterface