如何从“致命:内存不足”中恢复? mmap 失败:无法分配内存”在 Git 中?

发布于 2024-11-25 13:01:17 字数 1789 浏览 2 评论 0原文

让我从一些背景开始:

我必须将一个重要的 Magento 网上商店升级到新版本。为了确保所有现有代码在升级后仍然可以工作并进行一些升级后更改,我从整个 Magento 安装中创建了一个 Git 存储库(不包括明显的内容,如 4.5GB 图像、./var 目录等),并将其推送到一个源并将其克隆到开发服务器上。创建一个新分支,执行升级,进行代码更改,将其全部提交到 dev 分支并将其推回原点。

现在是时候升级“真实”商店了,这意味着我必须将生产服务器上的主分支与开发分支合并。然后一切都出了问题:

git fetch - Works

gitbranch 说: * master

git merge origin/dev 继续严重错误(等待一段时间后才输出):

致命:内存不足? mmap失败:无法分配内存

同样适用于git checkout devgit rebase master origin/dev等。

在这里对现有问题中的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

和:

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)

除了前面的命令之外,我还尝试了这个 (这非常相似)。 作为链接 提到了 32 位系统可能存在的问题,也许明智的做法是提及所涉及的三个系统的规格:

  • “dev”服务器:x86_64 Gentoo 2.6.38-hardened-r6 // 4 核 & 8GB RAM
  • “原始”服务器: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

有谁知道我该如何恢复?原产地重新包装有用吗?如果是这样,我如何说服生产服务器获取存储库的新副本? 任何帮助将不胜感激!

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.

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:

git fetch - works

git branch says: * master

git merge origin/dev goes horribly wrong (only output after some waiting):

fatal: Out of memory? mmap failed: Cannot allocate memory

Same goes for git checkout dev, git rebase master origin/dev etc.

Did some research here on stackoverflow in existing questions and spent an evening of trying suggestions, including (but not limited to):

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 link makes mention of a possible issue with 32-bit systems, perhaps it's wise to mention the specs for the three systems involved:

  • '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

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!

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(2

自由范儿 2024-12-02 13:01:17

您收到的错误来自存储库中的大文件。 Git 试图将文件的全部内容放入内存中,这导致文件发出嘎嘎声。

尝试升级 Git

Git 1.7.6 于上个月发布,其发行说明中有这样一段可爱的内容:

使用“git add”添加大于 core.bigfilethreshold(默认为 1/2 Gig)的文件会将内容直接发送到 packfile,而不必同时将其及其压缩表示形式保存在内存中。< /p>

升级到 1.7.6 可能使您能够运行 git gc ,甚至可能运行 git merge ,但我无法验证,因为很难让存储库进入该状态(条件一定是刚刚好)。

尝试删除有问题的文件

如果升级 Git 没有帮助,您可以尝试使用 git filter-branch 从存储库中删除大文件。在此之前,请尝试使用 git cat-file -p:path/to/large/file >/path/to/backup/of/large/file 备份大文件>。

您需要在最强大的机器(大量内存)上执行这些操作。

如果这有效,请尝试重新克隆到其他计算机(或简单地 rsync .git 目录)。

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.

Try Upgrading Git

Git 1.7.6 was released last month and has this lovely bit in its release notes:

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.

Upgrading to 1.7.6 might enable you to run git gc and 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).

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.

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 .git directory).

墨离汐 2024-12-02 13:01:17

我见过一些关于在非空目录中执行“git init --bare”时发生这种情况的报告。

您是否有机会使用非空的“裸”/“服务器”存储库(即,除了 .git 目录之外还有其他内容)?

I've seen a few reports of this happening when you do "git init --bare" in a non-empty directory.

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)?

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文