[devel] Почему сборочница тормозит: корень зла в алогритмах.

[Alexey Tourbin]

2018-02-07 22:47 GMT+03:00 Igor Vlasenko <vlasenko на imath.kiev.ua>:
> Вместо эпиграфа.
>
> LDV> Правильнее пересобирать все компилируемые пакеты
> LDV> после обновления тулчейна, мы готовы к этому?

> А между тем в devel@ уже всеръез обсуждается,
> что пакеты в Сизиф часто заливать не стоит,
> вместо этого надо локально копить коммиты
> и выкладывать их только в случае особых обстоятельств.

Сборка пакета имеет смысл, если она меняет что-то у пользователя. Если
на стороне пользователя ничего не меняется, то вы создаете
бессмысленный шум. Но есть большая индустрия "очистки спеков" и т.п.,
которая, за неимением лучшего, выдается за "разработку". Вы выступаете
апологетом порочных практик, исходя из примитивно понятых базовых
показателей. Возможно даже вы делаете это добросовестно.

> Хотел бы поделиться опытом, какой должна быть
> высокопроизводительная сборочница.
>
> Проблемы с производительностью сборочницы,
> с которыми сейчас столкнулся широкий круг майнтайнеров,
> у меня начались, наверное, раньше всех.
> Когда число моих пакетов стало больше 2 тыс.,
> мне в Сизифе стало тесно, а со сборочницей- неудобно,
> и я сделал отдельный репозиторий (autoimports)
> и свою сборочницу (autorepo-scripts), в которую
> постарался по возможности перенести возможности gitrar:
> сборку на 2 архтектуры, проверку на unmets, на устанавливаемость.
> В планах проверка на удаляемость пакета (на работу %pre/postun).
>
> На машине altair, раскочегаренная на все 32 ядра,
> сборочница на задаче обновления autoimports со CPAN обрабатывает
> более 4000 perl пакетов менее чем за 2 часа.
> Дадим консервативную оценку скорости в 850 транзакций в час.
>
> При этом, если я заливаю похожие пакеты perl в Сизиф,
> то они проходят со скоростью около 200 транзакций в сутки.
> Похожую скорость можно наблюдать в идущей последние
> дни пересборке python без setuptools-tests,
> запущенной Станиславом Левиным.
> Учитывая, что girar многопользовательский,
> оценим его скорость в 500 транзакций в сутки.
>
> Имеем: на сопоставимом классе пакетов
> autorepo-scripts на altair
> выдает скорость в 20.000 транзакций в сутки.
> При этом girar на кластере, существенно превосходящем
> altair по производительности,
> выдает скорость в 500 транзакций в сутки.

Понимаете, в чем дело.  Время всё равно уходит, а сборочица всё равно
простаивает. И показатель несколько тысяч транзакций в сутки всё равно
не нужен. То есть вы занимаетесь неправильной задачей оптимизации.
Правильной задачей оптимизации является увеличения качества
репозитория, но просто пока нет подходящей метрики.  Если знать на
пару шагов вперед, чтó ломают входящие пакеты, то можно было бы
посуточно откатывать некоторые транзакции (я пытался описать это в
терминах задержки коллапса пси-функции).  То есть ваша мысль работает
в неправильном направлении, как если бы увеличение скорости обработки
заданий решило все наши проблемы.