Pull to refresh

Проблемы с производительностью Git на большом репозитории

Reading time 2 min
Views 15K
Джошуа Редстоун (Joshua Redstone) пожаловался в листе рассылки Git на некоторые проблемы с производительностью, которые возникли у Facebook на большом репозитории. Они создали синтетический репозиторий и провели тесты.

Тестовый репозиторий
4 млн коммитов, линейная история и около 1,3 млн файлов. Размер папки .git — около 15 ГБ, её упаковали командой repack:

git repack -a -d -f --max-pack-size=10g --depth=100 --window=250

Процесс занял около двух суток на хорошей машине (много памяти, SSD). Размер индексного файла составил 191 МБ.

Скорость работы Git в таком репозитории совсем не радует. Результаты выполнения команд на сервере с обычным HDD и >10 ГБ RAM (команды повторялись несколько раз, с «горячим» кэшем ОС они работают быстрее, чем в первый раз):

git status
39 минут с «холодным» кэшем, 24 секунды с «горячим» кэшем;

git blame
44 минуты и 11 минут;

git add (добавление пары символов в конце файла и добавление его)
7 секунд и 5 секунд;

git commit -m "foo bar3" --no-verify --untracked-files=no –quiet --no-status
41 минута и 20 секунд.

Разработчики из Facebook говорят, что такие результаты им не подходят, и просят совета, как исправить ситуацию. Вероятно, под Git нужно выделять специализированные отдельные серверы, и как-то поддерживать на уровне файловой системы, чтобы ускорить отдельные операции (например, определять, какие файлы изменились). Придётся либо переписывать код Git для поддержки отдельных серверов, либо создавать надстройку со скриптами как своеобразный интерфейс доступа.

Коллега Редстоуна пояснил, что снижение производительности объясняются большим количеством структур O(n) в Git, что на больших размерах вызывает проблемы. Сам индексный файл полностью переписывается с нуля при малейшем изменении, а в большом проекте его размер превышает 100 МБ. Кроме того, Git использует lstat для проверки изменения файлов, так что на миллионе файлов возникают тормоза с дисковыми операциями, особенно в холодном кэше.

В общем, разработчики из Facebook намекают на то, что хорошо бы переписать Git для улучшения производительности. Разделить репозиторий на несколько частей они отказываются.
Tags:
Hubs:
+38
Comments 64
Comments Comments 64

Articles