Фиксирование репо git, которое замедляется из-за больших двоичных файлов
У нас есть репозиторий 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 для повышения производительности
Ответы
Ответ 1
Пока ваши вопросы задают вопрос о том, как сделать ваш текущий репо более эффективным, я не думаю, что это возможно.
Следуйте советам толпы:
- Извлеките свои большие двоичные файлы из своего репо.
- Перенесите среду вашего разработчика на образ виртуальной машины: https://www.virtualbox.org/
- Используйте этот Python script для очистки вашего репо этих больших двоичных блоков (я использовал его для своего репо, и он отлично работал) https://gist.github.com/1433794
Ответ 2
Вы должны использовать другой механизм для хранения больших двоичных файлов, если они сгенерированы из того, что вы могли бы просто не хранить, а только код, который их генерирует, в противном случае я предлагаю переместить все их в один каталог и управлять им с помощью rsync или svn в зависимости от ваших потребностей.