Есть ли способ ограничить объем памяти, который использует "git gc"?

Ответ 1

Да, посмотрите справочную страницу git config и посмотрите параметры pack.*, в частности pack.depth, pack.window, pack.windowMemory и pack.deltaCacheSize.

Это не совсем точный размер, поскольку git должен отображать каждый объект в память, поэтому один очень большой объект может вызвать много использования памяти, независимо от настроек окна и дельта-кеша.

Возможно, вам удастся упаковать локально и перенести файлы на удаленную сторону "вручную", добавив файлы .keep, чтобы удаленный git никогда не пытался полностью переупаковать все.

Ответ 2

Я использовал инструкции из этой ссылки. Та же идея, что и Чарльз Бейлис.

Копия команд находится здесь:

git config --global pack.windowMemory "100m"
git config --global pack.packSizeLimit "100m"
git config --global pack.threads "1"

Это сработало для меня на hostgator с учетной записью общего хостинга.

Ответ 3

Git repack использование памяти: (pack.deltaCacheSize + pack.windowMemory) × pack.threads. Соответствующие значения по умолчанию - 256 Мбайт, без ограничений, nproc.

Дельта-кеш не полезен: большая часть времени тратится на дельтах вычислений на скользящем окне, большинство из которых отбрасывается; кэширование оставшихся в живых, чтобы их можно было повторно использовать один раз (при написании), не улучшит время выполнения. Этот кеш также не разделяется между потоками.

По умолчанию память окна ограничена pack.window (gc.aggressiveWindow). Ограничение упаковки - это плохая идея, потому что размер и эффективность рабочего набора будут сильно различаться. Лучше поднять оба значения до более высоких значений и полагаться на pack.windowMemory, чтобы ограничить размер окна.

Наконец, нарезание резьбы имеет недостаток в разбиении рабочего набора. Уменьшение pack.threads и увеличение pack.windowMemory, чтобы общее время оставалось одинаковым, чтобы улучшить время выполнения.

у repack есть другие полезные настройки (pack.depth, pack.compression, параметры растрового изображения), но они не влияют на использование памяти.

Ответ 4

Вы можете использовать отключить атрибут delta, чтобы отключить дельта-сжатие только для blobs этих путей:

В foo/.git/info/attributes (или foo.git/info/attributes, если это голый репозиторий) (см. дельта-запись в gitattributes и см. gitignore для синтаксиса шаблона):

/large_file_dir/* -delta
*.psd -delta
/data/*.iso -delta
/some/big/file -delta
another/file/that/is/large -delta

Это не повлияет на клоны репозитория. Чтобы повлиять на другие репозитории (например, клоны), поместите атрибуты в файл .gitattributes вместо (или в дополнение) к файлу info/attributes.

Ответ 5

Git 2.18 (Q2 2018) улучшит потребление памяти gc.
До версии 2.18, "git pack-objects" должен выделять тонны "struct object_entry", выполняя свою работу: уменьшение его размера помогает производительности совсем немного.
Это влияет на git gc.

См. commit f6a5576, commit 3b13a5f, commit 0aca34e, commit ac77d0c, commit 27a7d06, commit 660b373, коммит 0cb3c14, коммит 898eba5, коммит 43fa44f, коммит 06af3bb, коммит b5c0cbd, коммит 0c6804a, коммит fd9b1ba, коммит 8d6ccce, коммит 4c2db93 (14 апреля 2018 г.) от Нгуен Тхай Нгёк Дуй (pclouds).
^{(Merged by Junio C Hamano -- [TG44] -- in commit ad635e8, 23 May 2018)}

pack-objects: изменить порядок членов, чтобы уменьшить struct object_entry

Предыдущие исправления оставляют много дыр и отступов в этой структуре.
Этот патч меняет порядок членов и сокращает структуру до 80 байт (от 136 байтов в 64-битных системах до сокращения любого поля) с 16 битами, чтобы сэкономить (и еще пара в in_pack_header_size, когда у нас действительно кончились биты).

Это последний из серии патчей уменьшения памяти (см. "pack-objects: немного документа о структуре object_entry" для первый).

В целом они уменьшили объем памяти для перепаковки на linux-2.6.git с 3,747G до 3,424G, или примерно на 320M, снижение на 8,5%.
Время выполнения repack осталось неизменным на протяжении всей этой серии.
Æвар тестирование на большом монорепо, к которому он имеет доступ (больше, чем linux-2.6.git), показало снижение на 7,9%, поэтому общее ожидаемое улучшение должно быть где-то около 8%.

С Git 2.20 (Q4 2018) будет проще проверить, не существует ли объект, существующий в одном форке, как дельта против другого объекта, который не появляется в том же разветвленном хранилище.

Смотрите коммит fe0ac2f, коммит 108f530, коммит f64ba53 (16 августа 2018 г.) от Кристиана Кудера (chriscool).
. При поддержке: Джефф Кинг (peff) и Дуй Нгуен (pclouds)
. Смотрите коммит 9eb0986 , коммит 16d75fa , коммит 28b8a73 , коммит c8d521f (16 августа 2018 г.) от Джеффа Кинга (peff)
. При поддержке: Джефф Кинг (peff) и Дуй Нгуен (pclouds)
.

^{(Merged by Junio C Hamano -- [TG415] -- in commit f3504ea, 17 Sep 2018)}

pack-objects: переместите "layer" в "struct packing_data"

Это уменьшает размер struct object_entry с 88 байт до 80 и, следовательно, повышает эффективность упаковки объектов.

Например, в репозитории Linux с 12M объектами git pack-objects --all требуется дополнительная память 96 МБ, даже если функция слоя не используется.

Обратите внимание, что в Git 2.21 (февраль 2019 г.) исправлена небольшая ошибка: "git pack-objects" неправильно использовал неинициализированный мьютекс, который был исправлен. См.commit edb673c , commit 459307b (25 января 2019 г.) от Патрика Хогга ('')
. Помощник: Джунио С. Хамано (gitster)
.

^{(Merged by Junio C Hamano -- [TG421] -- in commit d243a32, 05 Feb 2019)}

pack-objects: переместить мьютекс чтения в структуру packing_data ac77d0c
("pack-objects: поле уменьшенного размера в структуре object_entry", 2018-04-14) добавлено дополнительное использование read_lock/read_unlock в новом представил oe_get_size_slow для обеспечения безопасности потоков при параллельных вызовах try_delta().
К сожалению, oe_get_size_slow также используется в серийном код, некоторые из которых вызывается до первого вызова ll_find_deltas.

Таким образом, мьютекс чтения не гарантируется для инициализации.

Решите это, переместив мьютекс чтения в packing_data и инициализируя это в prepare_packing_data, который инициализирован в cmd_pack_objects.

Git 2.21 (февраль 2019 г.) все еще находит другой способ уменьшить размер пакета с помощью "git pack-objects", изучающего другой алгоритм для вычисления набора объекты для отправки, которые обменивают полученный файл пакета, чтобы сохранить стоимость обхода в пользу небольших толчков.

pack-objects: создать настройку pack.useSparse
Флаг "--sparse" в "git pack-objects" меняет алгоритм используется для перечисления объектов одному, который быстрее для отдельных пользователи выдвигают новые объекты, которые меняют только маленький конус рабочий каталог.

Разреженный алгоритм не рекомендуется для сервера, который, вероятно, отправляет новые объекты, которые появляются во всем рабочем каталоге.
Создайте настройку "pack.useSparse", которая включает этот новый алгоритм.

Это позволяет "git push" использовать этот алгоритм без передачи --sparse помечает все четыре уровня run_command() звонки.

Если установлен флаг "--no-sparse", то этот параметр конфигурации переопределены. документация пакета конфигурации теперь включает в себя:

pack.useSparse:

Когда true, Git по умолчанию будет использовать опцию '--sparse' в     "git pack-objects", когда присутствует опция "--revs".
    Этот     Алгоритм только гуляет деревья, которые появляются в пути, которые вводят новые     объекты.

Это может иметь значительные преимущества в производительности, когда     вычисление пакета, чтобы отправить небольшое изменение.

Тем не менее, это возможно     что дополнительные объекты добавляются в упаковочный файл, если включены коммиты содержат определенные типы прямых переименований.

Смотрите "git push очень медленно для огромного репо" для конкретной иллюстрации.

Примечание. Как отмечено в Git 2.24, настройка, подобная pack.useSparse, все еще является экспериментальной.

См. commit aaf633c, commit c6cc4c5, commit ad0fb65, commit 31b1de6, commit b068d9a, commit 7211b9e (13 августа 2019 г.) от Деррика Столи (derrickstolee).
^{(Merged by Junio C Hamano -- [TG449] -- in commit f4f8dfe, 09 Sep 2019)}

repo-settings: создать настройку feature.experimental

Параметр feature.experimental включает в себя параметры конфигурации, которые не предназначены для использования по умолчанию, но могут использовать дополнительный тест g.

Обновите следующие параметры конфигурации, чтобы принять новые значения по умолчанию, и используйте структуру repo_settings, если еще не используете их:

• 'Pack.useSparse = истина'
• 'Fetch.negotiationAlgorithm = пропуск'