Дженкинс git плагин – soooo медленный иногда

Из журнала Дженкинса берется следующее:

00:00:03.135 > git fetch --tags --progress git@github.com:some_org/some_repo.git +refs/heads/*:refs/remotes/origin/* 00:03:49.659 > git rev-parse origin/master^{commit} # timeout=10 

Я смущен, почему этот тайм-аут происходит, потому что запуск git fetch на том же компьютере с одним и тем же пользователем занимает от 5 до 10 секунд.

Я использую последнюю версию этой версии Git (2.1.2) и последней версии gitplugin.

Мысли?

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

Примечание: скорость git-fetch должна улучшиться снова с Git 2.2+ (ноябрь 2014 г.)

См. Commit cbe7333 , Джефф Кинг ( peff ):

refs: speed up is_refname_available

Наша файловая система ref storage не разрешает конфликты D / F (каталог / файл) ; поэтому, если существует « refs/heads/a/b », мы не разрешаем существование « refs/heads/a » (и наоборот).
Это, естественно, выпадает из-за неактивных ссылок, где файловая система выполняет условие. Но для упакованных ссылок нам нужно сделать чек.

Мы делаем это, итерируя по всему пространству имен упакованных-refs и проверяя, создает ли каждое имя конфликт. Если у вас очень много ссылок, это довольно неэффективно , так как в итоге вы делаете большое количество сравнений с неинтересными битами дерева ref (например, мы знаем, что все « refs/tags » неинтересны в примере выше, но мы проверяем каждую запись в нем).

Вместо этого давайте воспользуемся тем фактом, что у нас есть упакованные refs, хранящиеся как trie структур ref_entry .
Мы можем найти каждый компонент предлагаемого refname при прохождении через дерево, проверяя конфликты D / F, когда мы идем. Для определения refname глубины N (т. refname 4 в приведенном выше примере) нам нужно только посетить N узлов. И при каждом посещении мы можем бинарно искать имена M на этом уровне, для полной сложности O(N lg M) . (« M » различно на каждом уровне, конечно, но мы можем взять наихудший случай « M » в качестве границы).

В патологическом случае извлечения 30 000 свежих ссылок в хранилище с 8,5 млн. Рефсов это снизило время запуска «git fetch» ​​с десятков минут до 30 секунд .

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

Обратите внимание, что тесты, которые мы добавляем, на первый взгляд кажутся избыточными с тем, что уже находится в t3210. Однако ранние тесты не являются надежными; они запускаются с включенными reflogs, что означает, что мы фактически не тестируем is_refname_available вообще!
Операции будут по-прежнему терпеть неудачу, поскольку в логах будут обнаружены конфликты D / F в файловой системе.
Чтобы получить истинный тест, мы должны отключить reflogs (но мы не хотим делать это для всего скрипта, потому что его включение должно было охватывать некоторые другие случаи).