Git 克隆失败并出现内存不足错误 - “致命：内存不足，malloc 失败（尝试分配 905574791 字节）/致命：索引包失败”
我正在尝试将一个大型 (1.4GB) Git 存储库克隆到具有 384MB RAM 的 32 位 Debian VM。我正在使用 Git 1.7.2.5，并使用 SSH 协议进行克隆 ('git clone [ email protected]:/my/repo')
克隆失败消息：
remote: Counting objects: 18797, done.
remote: warning: subobtimal pack - out of memory
remote: Compressing objects: 100% (10363/10363), done.
fatal: out of memory, malloc failed (tried to allocate 905574791 bytes)
fatal: index-pack failed
我尝试减少 Git 用于在主机存储库端重新打包的内存量，并重新打包：
git config pack.windowMemory 10m
git config pack.packSizeLimit 20m
git repack -a -d
我的问题如下：
- 这是客户端大小（克隆端）问题还是应该在存储库中解决我是从哪里克隆的？
无论哪种情况，我能做些什么来使克隆成功吗？网上许多潜在的解决方案都涉及以下部分/全部内容，在这种情况下，这些都是不可接受的：
- 实质性更改存储库的内容（即删除大文件）
- 为进行克隆的虚拟机提供更多 RAM
- 为进行克隆的虚拟机提供 64 位虚拟 CPU
- 带外传输（例如使用 Rsync 或 SFTP 传输 .git 目录）
的 VM提前致谢。
I'm attempting to clone a large (1.4GB) Git repository to a 32-bit Debian VM with 384MB of RAM. I'm using Git 1.7.2.5, and using the SSH protocol to clone ('git clone [email protected]:/my/repo')
The clone fails with this message:
remote: Counting objects: 18797, done.
remote: warning: subobtimal pack - out of memory
remote: Compressing objects: 100% (10363/10363), done.
fatal: out of memory, malloc failed (tried to allocate 905574791 bytes)
fatal: index-pack failed
I've tried reducing the amount of memory Git uses to repack on the host repository end, and repacking:
git config pack.windowMemory 10m
git config pack.packSizeLimit 20m
git repack -a -d
My questions are as follows:
- Is this a client-size (clone-side) problem or should it be resolved in the repo that I'm cloning from?
In either case, is there anything I can do to make the clone succeed? A lot of the potential solutions online involve some/all of the following things, none of which are acceptable in this instance:
- changing the contents of the repository substantively (i.e. deleting large files)
- giving the VM which is doing the clone more RAM
- giving the VM which is doing the clone a 64-bit virtual CPU
- transferring out-of-band (e.g. using Rsync or SFTP to transfer the .git directory)
Thanks in advance.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
git clone不会查看您的pack.packSizeLimit设置，它无论如何都会传输单个包中的所有内容 - 除非自上次查看以来它发生了变化。使用 SCP 或 Rsync 可能确实是解决您问题的一种方法。删除“无用”的大文件，然后重新打包您尝试克隆的存储库也可能有所帮助。
为虚拟机提供更多 RAM 也可能有所帮助 - 我认为您不需要 64 位地址空间来分配 900MB...您还可以为其提供足够的交换空间来处理 900MB 包，而不是增加 RAM。
git clonewill not look at yourpack.packSizeLimitsetting, it'll anyway transfer everything in a single pack - unless it changed since the last time I looked.Using SCP or Rsync might be a way to work around your issue indeed. Removing the "useless" large files, then repacking the repository you try to clone could also help.
Giving more RAM to the VM might also help - I don't think you'll need a 64-bits address space to allocate 900MB... You could also give it enough SWAP space to handle the 900MB package instead of increasing the RAM.
我在使用 MSysGit 32 位的 Windows 上遇到了类似的问题。
来自 Cygwin 的 git 64 位完成了这项工作。
也许您应该使用 64 位 Debian VM（而不是 32 位 VM）。
我的原始答案可用于问题Git在 Windows 上，“内存不足 - malloc 失败”。
I got a similar issue on Windows using MSysGit 32 bits.
The git 64 bits from Cygwin did the job.
Maybe you should use a 64 bits Debian VM (instead of 32 bits one).
My original answer is available on question Git on Windows, “Out of memory - malloc failed”.
今天我遇到了同样的问题。 Git 服务器内存不足，但 gitlab 报告仍有可用内存。我们用 htop 检查了内存（报告无可用内存），重新启动 gitlab，一切恢复正常。
Today I had the same issue. Git server ran out of memory, but gitlab reported that there is still memory available. We checked memory with htop (reported none available), restarted gitlab and everything went back to normal.
每次拉取时我都会遇到相同的错误消息，
sudo git pull实际上帮助我克服了这个错误消息并且拉取成功了。I faced the same error message every time I pull and
sudo git pullactually helped me to overcome this error message and pull was successful.