Re: [devel] I: [[Girar/Parallel]]

[Michael Shigorin <mike@altlinux.org>]

On Thu, Apr 12, 2018 at 08:46:28PM +0300, Igor Vlasenko wrote:
> оформил цикл писем по улучшению сборочницы в страничку 
> https://www.altlinux.org/Girar/Parallel

Спасибо!  Так получилось наконец прочесть эту сагу
(заодно повоевал с лишними запятыми и отформатировал).

---

Про уменьшение Tm ещё продумываются софтовые меры
(патчилка индексов имени at@) и аппаратные (машинка
с процессором вида "меньше, да быстрее ядер" и SSD).

>>> чтобы не тормозить сотни тысяч ради одного

У нас, к сожалению, не так редок "научный" подход к решению
задач вместо "инженерного" -- например, каждому hello
резервируются ресурсы, достаточные для сборки boost или LO.
Это при том, что несложно фиксировать CPU/RAM/time по опыту
предыдущих сборок и неожиданности обрабатывать как исключения.
Проблема "всего лишь" в том, что никто до сих пор не взялся
ещё и такое сделать, развернуть и отвечать за результат.

Есть ещё идея, которую можно условно назвать "hasherd":
когда задачи не распихиваются по исполнителям, а разбираются
ими из очереди (заодно так должно стать удобней и маневрировать
мощностью, и делать её сильно неравномерной -- например, держать
узлы с множеством более медленных ядер и с меньшим количеством
более быстрых ядер, аналогично по памяти; всё это может особенно
сильно проявиться на не-x86, как мне кажется).

>>> В импорт только Mass_Rebuild и попадает?

Конкретно федорины mass rebuild, которые являются предельно
топорным методом решения той же задачи, что у нас решена пусть
и не идеально, но куда технологичней -- и впрямь не хочется
видеть ни в репо, ни в %changelog (это и sisyphus-cybertalk@,
и выхлоп apt-cache show -- волны от кирпича круглые, однако).

И у этой оптимизации есть большой плюс: для неё никого ждать
не надо. :)

>>> "Уже сейчас сборочница иногда простаивает [...]"

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

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

>>> [install check] По сути-бесполезная проверка

Скорее "слишком дорогая для синхронной", но ловившая,
насколько знаю, реальные ошибки.

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

>>> К примеру, чтобы выполнить тест на символы в бинарниках,
>>> надо распаковать rpm

Угу, а при сборке он у нас ещё вообще не запакованный есть
-- бери списки файлов из заголовков только что собранных бинарных
пакетов да выгребай содержимое из %buildroot (заодно можно другим
хукам отдавать вроде приёмных скриптов prometheus, но тут важно
не переоптимизировать до слишком тесной связности).

-- 
 ---- WBR, Michael Shigorin / http://altlinux.org
  ------ http://opennet.ru / http://anna-news.info