Git GC использует слишком много памяти, не может завершить - PullRequest
35 голосов
/ 21 ноября 2011

Окончательное обновление и исправление : решение здесь оказалось комбинацией двух вещей: использование Windows Git вместо Cygwin Git, как Грэм Борланд . и настройки Git config pack.threads = 1 и gc.aggressiveWindow = 150.

У меня есть большой локальный репозиторий Git, git svn clone репозитория SVN с около 40000 коммитов. Я пытаюсь запустить git gc через этот репозиторий и не получаю:

$ git gc --auto
Auto packing the repository for optimum performance. You may also
run "git gc" manually. See "git help gc" for more information.
Counting objects: 25966, done.
Compressing objects: 100% (25249/25249), done.
fatal: Out of memory, malloc failed (tried to allocate 426523986 bytes)
error: failed to run repack

Я запускаю Git 1.7.5.1 внутри Cygwin на 64-битной двухъядерной машине Win7 с 4 ГБ ОЗУ. Каталог .git в настоящее время имеет размер чуть более 6,1 ГБ.

Я попытался запустить git gc --aggressive, чтобы посмотреть, сможет ли более полная система это исправить, но не повезло: я получаю сообщение, аналогичное приведенному выше, с таким же размером попытки malloc, но значительно большее количество объектов (насчитывается 508 485, сжато 493 506).

Я также пытался - как подсказывает Google - сортировать тиддли в части [pack] моего файла .gitconfig; наиболее полное из другого вопроса StackOverflow . У моего .gitconfig теперь есть следующие соответствующие строки, но их установка, похоже, не изменила:

[pack]
        windowMemory = 16m
        threads = 1
        window = 1
        depth = 1
        deltaCacheSize = 1

Любые предложения о том, как я могу получить git в gc мой репозиторий?

Редактировать : Марк Лонгэйр предложил некоторые другие .gitconfig изменения файла. Что я сделал, новые строки ниже. Но изменения не имели никакого значения.

[core]
        packedGitWindowSize = 1m
        packedGitLimit = 256m
[pack]
        packSizeLimit = 128m

Редактировать 2 : Майкл Крелин предложил увеличить размер файла подкачки / страницы (инструкции WinXP здесь , и аналогично для Win7 ). Я попробовал это, но это не имело никакого значения, и действительно, я только увеличил максимальный доступный размер, и похоже, что Windows никогда не пыталась увеличить размер используемого файла подкачки.

Сейчас я смотрю, было ли это вызвано ограничением памяти внутри или наложено на Cygwin. Чтобы проверить «наложено», я пытаюсь запустить Cygwin с правами администратора. Чтобы проверить «внутри» (что выглядит более вероятным), я играю с максимальными настройками памяти Cygwin .

Редактировать 3 : Хотя я и предпочитаю использовать Cygwin, оказывается, что клиент Windows Git прекрасно справляется с проблемой памяти. Кажется, я буду прибегать к этому время от времени, когда моему хранилищу нужна аккуратность.

Ответы [ 5 ]

11 голосов
/ 31 декабря 2011

У меня была такая же проблема, безуспешно пробовал упомянутые решения. Но мои проблемы с git gc начались после того, как я добавил в репозиторий большие файлы изображений, поэтому я создал файл .gitattributes и отключил дельта-сжатие для этих больших файлов:

*.tga -delta
*.psd -delta

Это сработало.

7 голосов
/ 21 ноября 2011

Возможно, вам больше повезет, если вы будете работать с собственным клиентом Windows, таким как msysGit , а не пытаться сделать это внутри Cygwin.

5 голосов
/ 21 ноября 2011

Некоторые другие параметры конфигурации, которые вы можете попробовать ограничить значениями ниже значений по умолчанию, включают:

  • pack.packSizeLimit
  • core.packedGitWindowSize
  • core.packedGitLimit

... все это документировано в git config документации .В каждом конкретном случае особенно стоит проверять, какие единицы понимаются, с чем я ошибался в прошлом.

3 голосов
/ 11 мая 2013

Единственное, что помогло избежать этой ошибки на общем хостинге Linux, это добавить

  [pack]
    packSizeLimit = 64m
    threads = 1

до

.gitconfig

Самым важным было "threads = 1"

1 голос
/ 21 ноября 2011

Может быть, поможет временное добавление файла подкачки больше, чем life, и покупка нескольких чашек кофе в другом месте?

...