Git克隆失败，出现内存不足错误-“0”；致命：内存不足，malloc失败（尝试分配905574791字节）/致命：索引包失败“；

我正在尝试将一个大型（1.4GB）Git存储库克隆到一个32位的Debian VM，内存为384MB。我正在使用Git1.7.2.5，并使用SSH协议进行克隆（“Git克隆”）user@host.com：/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

我的问题如下:

这是一个客户端大小（克隆端）问题，还是应该在我从中克隆的回购协议中解决

在这两种情况下，我能做些什么使克隆成功？许多潜在的在线解决方案涉及以下部分/全部内容，在这种情况下，没有一个是可接受的：

• 实质性地更改存储库的内容（即删除大型文件）
• 为正在进行克隆的VM提供更多RAM
• 为进行克隆的VM提供64位虚拟CPU
• 带外传输（例如，使用Rsync或SFTP传输.git目录）

---

提前感谢。

git clone不会查看您的

包。packSizeLimit

设置，它将在单个包中传输所有内容-除非自上次查看后发生更改

使用SCP或Rsync可能是解决您的问题的一种方法。删除“无用”的大文件，然后重新打包尝试克隆的存储库也会有所帮助

---

为虚拟机提供更多的RAM也可能有所帮助-我认为您不需要64位地址空间来分配900MB。。。您还可以给它足够的交换空间来处理900MB的包，而不是增加RAM。

我在使用32位的Windows上遇到了类似的问题。 来自的git 64位完成了这项工作。 也许您应该使用64位Debian VM（而不是32位）

我的电话有问题

---

每次拉动时，我都会遇到相同的错误消息，

sudo git pull

实际上帮助我克服了这个错误消息，拉动成功了。

今天我遇到了同样的问题。Git服务器内存不足，但gitlab报告仍有可用内存。我们用htop检查了内存（报告没有可用的内存），重新启动了gitlab，一切都恢复正常。

您是否检查了（克隆机上）是否有足够的磁盘空间来容纳整个打包文件（900 MB）罗曼：是的，我在做克隆的机器上至少有5.5GB的可用空间。是的，当我在存储库中使用大型二进制文件时，这对我来说有一次。看看git bup，如果这是Romain的原因，可以找到其他方法，谢谢您的回复。我最终给了VM 768MB的RAM，这暂时解决了这个问题。不过，Git似乎确实吃内存当早餐——据#Git IRC频道上的Charon称，在即将发布的Git中可能会有一个解决方案，它支持“流式解压缩”，而不是RAM解压缩。@grw：它只为某些节省带宽的操作吃内存。。。这就是git如何成为fastI concur对@sehe所说内容的认可。。。只有当Git是轻松实现最佳性能的唯一方法时，它才需要大量内存。现在它更成熟了，人们正在努力使它在更受约束的环境中表现得更好…@Romain，我真的希望如此：D谢谢你们的建议，伙计们。尝试添加交换，但没有成功。还是不能克隆=/对不起，但这对我也不起作用。尝试分配212211077字节但失败您的操作系统是什么？（您使用WindowsXP吗？）您的操作系统是32位还是64位？你是如何安装Git的？（下载还是自编译？）您的Git是32位还是64位？干杯；-）快速解释我的否决票：这个答案指示违反最佳实践，执行一项本质上危险的操作。说真的，伙计们，不要这样做。

sudo git pull