У нас есть репозиторий git, содержащий как исходный код, так и двоичные файлы. Голый репо теперь достиг ~ 9 ГБ, и клонирование требует много времени. Большую часть времени тратится на "remote: Compressing objects". После коммита с новой версией одного из более крупных двоичных файлов выборка занимает много времени, а также сжигает объекты на сервере.
После прочтения git pull без отдаленного сжатия объектов Я подозреваю, что дельта-сжатие двоичных файлов тоже вредит нам, но я не уверен на 100%, как чтобы исправить это.
Каковы конкретные шаги по исправлению голого репо на сервере? Мое предположение:
- Добавьте записи типа '*.zip -delta' для всех расширений, которые я хочу в .git/info/attributes.
- Запустить 'git repack', но с какими параметрами? Будет ли -adF перепаковать все, и оставить меня с репо, где дельта-компрессия никогда не выполнялась по указанным типам файлов?
- Запустить 'git чернослив. Я думал, что это было сделано автоматически, но запустил его, когда я играл с голой клоню указанного репо, уменьшил размер на ~ 2 ГБ.
- Клонирование репо, добавление и фиксация .gitattributes с теми же записями, что и я добавил в .git/info/attributes на голом репо
Я что-то на что-то?
Update:
Некоторые интересные результаты теста. Сегодня я начал голой клон проблемного репо. Наш не очень мощный сервер с 4 ГБ RAM исчерпал память и начал заменять. Через 3 часа я сдался...
Затем я вместо этого клонировал голый репо из моей современной рабочей копии. Клонирование того, что между рабочими станциями заняло ~ 5 минут. Затем я подтолкнул его к серверу как новое репо. Клонирование этого репо заняло всего 7 минут.
Если я правильно интерпретирую это, лучшее упакованное репо работает намного лучше, даже не отключая дельта-сжатие для двоичных файлов. Я предполагаю, что это означает, что приведенные выше шаги действительно являются тем, что я хочу сделать в краткосрочной перспективе, но, кроме того, мне нужно выяснить, как ограничить объем памяти git, который разрешен для упаковки/сжатия на сервере, поэтому я может избежать обмена.
В случае, если это имеет значение: сервер работает git 1.7.0.4, а рабочие станции работают 1.7.9.5.
Обновление 2:
Я сделал следующие шаги в своем тестовом режиме и подумал, что я смогу сделать их на сервере (после резервного копирования)
-
Ограничить использование памяти при упаковке объектов
git config pack.windowMemory 100m
git config pack.packSizeLimit 200m -
Отключить дельта-сжатие для некоторых расширений
echo '*.tar.gz -delta' → информация/атрибуты
echo '*.tar.bz2 -delta' → информация/атрибуты
echo '*.bin -delta' → информация/атрибуты
echo '*.png -delta' → info/attributes -
Хранить репозиторий и собирать мусор
git repack -a -d -F --window-memory 100m - max-pack-size 200m
git gc
Обновление 3:
Некоторые неожиданные побочные эффекты после этой операции: Проблемы после попытки переупаковать репозиторий git для повышения производительности