如何从 Git 中的“致命：内存不足？mmap 失败：无法分配内存”中恢复？
声明：本页面是StackOverFlow热门问题的中英对照翻译，遵循CC BY-SA 4.0协议，如果您需要使用它，必须同样遵循CC BY-SA许可，注明原文地址和作者信息，同时你必须将它归于原作者（不是我）：StackOverFlow
原文地址: http://stackoverflow.com/questions/6775242/
Warning: these are provided under cc-by-sa 4.0 license. You are free to use/share it, But you must attribute it to the original authors (not me):
StackOverFlow
How can I recover from "fatal: Out of memory? mmap failed: Cannot allocate memory" in Git?
提问by Rem.co
Let me start with some context:
让我从一些上下文开始：
I had to upgrade a crucial Magento webshop to a new version. To be sure all existing code would still work after the upgrade and make some post-upgrade changes I made a Git repository from the entire Magento installation (excluding obvious content like the 4.5GB of images, ./var directory etc.), pushed it to an origin and cloned it on a dev server. Made a new branch, performed the upgrades, made code changes, committed it all to the dev branch and pushed it back to origin.
我不得不将一个重要的 Magento 网上商店升级到新版本。为了确保所有现有代码在升级后仍然可以工作并进行一些升级后更改，我从整个 Magento 安装中创建了一个 Git 存储库（不包括明显的内容，如 4.5GB 的图像、./var 目录等），将其推送到源并将其克隆到开发服务器上。创建一个新分支，执行升级，更改代码，将其全部提交到 dev 分支并将其推回原点。
Now the time has come to upgrade the 'real' shop, meaning i have to merge the master branch on the production server with the dev branch. And then everyhing goes wrong:
现在是升级“真实”商店的时候了，这意味着我必须将生产服务器上的 master 分支与 dev 分支合并。然后一切都出错了：
git fetch- works
git fetch- 作品
git branchsays: * master
git branch说： * master
git merge origin/devgoes horribly wrong (only output after some waiting):
git merge origin/dev严重错误（仅在等待后输出）：
fatal: Out of memory? mmap failed: Cannot allocate memory
fatal: Out of memory? mmap failed: Cannot allocate memory
Same goes for git checkout dev, git rebase master origin/devetc.
同去的git checkout dev，git rebase master origin/dev等等。
Did some research here on stackoverflow in existing questions and spent an evening of trying suggestions, including (but not limited to):
在这里对现有问题中的 stackoverflow 进行了一些研究，并花了一个晚上尝试建议，包括（但不限于）：
git gc
Counting objects: 48154, done.
Delta compression using up to 2 threads.
Compressing objects: 100% (37152/37152), done.
fatal: Out of memory, malloc failed (tried to allocate 527338875 bytes)
error: failed to run repack
and:
和：
git repack -a -d --window-memory 10m --max-pack-size 20m
Counting objects: 48154, done.
Delta compression using up to 2 threads.
Compressing objects: 100% (37152/37152), done.
fatal: Out of memory, malloc failed (tried to allocate 527338875 bytes)
In addition to the previous command, i also tried this(which is pretty similar). As the linkmakes mention of a possible issue with 32-bit systems, perhaps it's wise to mention the specs for the three systems involved:
除了前面的命令，我还尝试了这个（非常相似）。由于该链接提到了 32 位系统可能存在的问题，因此提及所涉及的三个系统的规格可能是明智的：
- 'dev' server: x86_64 Gentoo 2.6.38-hardened-r6 // 4 cores & 8GB RAM
- 'origin' server: x86_64 Gentoo 2.6.38-hardened-r6 // 2 cores & 4GB RAM
- 'live' server: x86_64 Debian 4.3.2-1.1 2.6.35.5-pv1amd64 // (VPS) 2 cores & 3GB RAM
- “开发”服务器：x86_64 Gentoo 2.6.38-hardened-r6 // 4 核 & 8GB RAM
- 'origin' 服务器：x86_64 Gentoo 2.6.38-hardened-r6 // 2 核 & 4GB RAM
- “实时”服务器：x86_64 Debian 4.3.2-1.1 2.6.35.5-pv1amd64 // (VPS) 2 核 & 3GB RAM
Does anyone know how I can recover from this? Does repacking on origin work? If it does, how can I convince the production server to fetch a new copy of the repository? Any help would be greatly appreciated!
有谁知道我如何从中恢复？原产地重新包装有效吗？如果是这样，我如何说服生产服务器获取存储库的新副本？任何帮助将不胜感激！
回答by Richard Hansen
The error you're getting comes from the large files in your repository. Git is trying to put the entire contents of the file in memory, which makes it croak.
您收到的错误来自存储库中的大文件。Git 正试图将文件的全部内容放入内存中，这让它变得咝咝作响。
Try Upgrading Git
尝试升级 Git
Git 1.7.6 was released last month and has this lovely bit in its release notes:
Git 1.7.6 于上个月发布，在其发行说明中有这么可爱的地方：
Adding a file larger than core.bigfilethreshold (defaults to 1/2 Gig) using "git add" will send the contents straight to a packfile without having to hold it and its compressed representation both at the same time in memory.
使用“git add”添加一个大于 core.bigfilethreshold（默认为 1/2 Gig）的文件会将内容直接发送到一个包文件，而不必同时在内存中保存它和它的压缩表示。
Upgrading to 1.7.6 might enable you to run git gcand maybe even git merge, but I can't verify because it's hard get a repository into that state (the conditions must be just right).
升级到 1.7.6 可能使您能够运行git gc甚至git merge，但我无法验证，因为很难将存储库置于该状态（条件必须恰到好处）。
Try Removing the Offending Files
尝试删除有问题的文件
If upgrading Git doesn't help, you can try removing the large files from the repository using git filter-branch. Before you do that, try backing up the large files using git cat-file -p <commit_sha1>:path/to/large/file >/path/to/backup/of/large/file.
如果升级 Git 没有帮助，您可以尝试使用git filter-branch. 在此之前，请尝试使用git cat-file -p <commit_sha1>:path/to/large/file >/path/to/backup/of/large/file.
You'll want to do these operations on your most beefy machine (lots of memory).
您需要在最强大的机器（大量内存）上执行这些操作。
If this works, try re-cloning to the other machines (or simply rsync the .gitdirectory).
如果这有效，请尝试重新克隆到其他机器（或简单地 rsync.git目录）。
回答by Joost Diepenmaat
I've seen a few reports of this happening when you do "git init --bare" in a non-empty directory.
我已经看到一些关于在非空目录中执行“git init --bare”时发生这种情况的报告。
Are you by any chance working in/with a "bare"/"server" repository that isn't empty (that is, has anything else besides the .git directory in it)?
您是否有机会在非空的“裸”/“服务器”存储库中工作/使用它（也就是说，除了 .git 目录之外还有其他任何内容）？
