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

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

[Igor Vlasenko]

Вместо эпиграфа.

LDV> Правильнее пересобирать все компилируемые пакеты 
LDV> после обновления тулчейна, мы готовы к этому?
Rider> Да мы то готовы, готова ли сборочница ?


Уважаемые коллеги,
В последнее время в devel@ участились вопросы,
связанные с производительностью сборочницы.

Я хотел был обсудить алгоритмы сборочницы 
напрямую с Дмитрием, но, к сожалению, 
на конференции его не застал.

А между тем в 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 транзакций в сутки.

Да, это гораздо более простая, однопользовательская,
однонодная, нераспределенная сборочница,
однако на моих задачах она кроет нашу сборчницу
даже не как бык овцу, а еще на порядок сильнее.

В чем разница? Разница в алгоритмах.

Продолжение следует.

-- 

I V

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

[Dmitry V. Levin]

[-- Attachment #1: Type: text/plain, Size: 1406 bytes --]

On Wed, Feb 07, 2018 at 09:47:31PM +0200, Igor Vlasenko wrote:
[...]
> Имеем: на сопоставимом классе пакетов 
> autorepo-scripts на altair 
> выдает скорость в 20.000 транзакций в сутки.
> При этом girar на кластере, существенно превосходящем 
> altair по производительности,
> выдает скорость в 500 транзакций в сутки.
> 
> Да, это гораздо более простая, однопользовательская,
> однонодная, нераспределенная сборочница,
> однако на моих задачах она кроет нашу сборчницу
> даже не как бык овцу, а еще на порядок сильнее.
> 
> В чем разница? Разница в алгоритмах.

На самом деле всё ещё проще: разница в задачах.

Возьмём первый попавшийся на глаза пакет из недавней python-пачки:
http://git.altlinux.org/tasks/archive/done/_195/200021/logs/events.1.1.log

Что мы видим: всё задание обрабатывалось 48:08 - 36:53 = 11.25 минут, из
них собственно сборка заняла 41:17 - 37:43 = 3.5 минуты, всё остальное --
это разнообразное тестирование, изготовление индексов (около минуты), и
коммит (ещё около минуты).  Таким образом, большая часть времени обработки
небольшого задания уходит на тестирование (один только install check занял
3 минуты), которого в autorepo-scripts нет в принципе, потому что задача
другая.

Очевидно, чтобы ускорить обработку заданий, стадию тестирования предстоит
распараллелить.  Изготовление индексов и коммит тоже неплохо было бы
ускорить.


-- 
ldv

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 801 bytes --]

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

[Igor Vlasenko]

On Wed, Feb 07, 2018 at 11:51:55PM +0300, Dmitry V. Levin wrote:
> коммит (ещё около минуты).  Таким образом, большая часть времени обработки
> небольшого задания уходит на тестирование (один только install check занял
> 3 минуты), которого в autorepo-scripts нет в принципе, потому что задача
> другая.

Это не так. Тестирование в girar - это очень круто,
поэтому я по максимуму попытался перенести его в autorepo-scripts.

install check в autorepo-scripts таки есть:

см. tail -6 /usr/bin/autorepo-helper-build-srpms

autorepo_build "$@"
autorepo_calculate_unmets
autorepo_install_test

exit $exit_status

 
> Очевидно, чтобы ускорить обработку заданий, стадию тестирования предстоит
> распараллелить.  Изготовление индексов и коммит тоже неплохо было бы
> ускорить.

Да, да. Я об этом, и еще о других способах распараллелить. 
Подробнее надеюсь собраться и написмать отдельное письмо.

-- 

I V

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

[Alexey Tourbin]

2018-02-07 23:51 GMT+03:00 Dmitry V. Levin <ldv@altlinux.org>:
> On Wed, Feb 07, 2018 at 09:47:31PM +0200, Igor Vlasenko wrote:
> [...]
>> Имеем: на сопоставимом классе пакетов
>> autorepo-scripts на altair
>> выдает скорость в 20.000 транзакций в сутки.
>> При этом girar на кластере, существенно превосходящем
>> altair по производительности,
>> выдает скорость в 500 транзакций в сутки.
>>
>> Да, это гораздо более простая, однопользовательская,
>> однонодная, нераспределенная сборочница,
>> однако на моих задачах она кроет нашу сборчницу
>> даже не как бык овцу, а еще на порядок сильнее.
>>
>> В чем разница? Разница в алгоритмах.
>
> На самом деле всё ещё проще: разница в задачах.
>
> Возьмём первый попавшийся на глаза пакет из недавней python-пачки:
> http://git.altlinux.org/tasks/archive/done/_195/200021/logs/events.1.1.log
>
> Что мы видим: всё задание обрабатывалось 48:08 - 36:53 = 11.25 минут, из
> них собственно сборка заняла 41:17 - 37:43 = 3.5 минуты, всё остальное --
> это разнообразное тестирование, изготовление индексов (около минуты), и
> коммит (ещё около минуты).  Таким образом, большая часть времени обработки
> небольшого задания уходит на тестирование (один только install check занял
> 3 минуты), которого в autorepo-scripts нет в принципе, потому что задача
> другая.
>
> Очевидно, чтобы ускорить обработку заданий, стадию тестирования предстоит
> распараллелить.  Изготовление индексов и коммит тоже неплохо было бы
> ускорить.

Надо пропускать установку некоторых *-debuginfo пакетов. В них нет
%post-скриптов или триггеров, плохо устанавливаться они могут только
из-за файловых конфликтов.  Тогда, зная результаты установки основных
пакетов, можно выбрать только один или несколько *-debuginfo пакетов,
таких что они вытягивают все остальные.

Re: [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 транзакций в сутки.

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