[devel] I: https://www.altlinux.org/Girar/Parallel

[devel] I: https://www.altlinux.org/Girar/Parallel

[Igor Vlasenko]

Уважаемые господа,

оформил цикл писем по улучшению сборочницы
в страничку 

https://www.altlinux.org/Girar/Parallel

-- 

I V

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

[Michael Shigorin]

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

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

[Dmitry V. Levin]

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

On Thu, Apr 12, 2018 at 11:09:24PM +0300, Michael Shigorin wrote:
[...]
> У нас, к сожалению, не так редок "научный" подход к решению
> задач вместо "инженерного" -- например, каждому hello
> резервируются ресурсы, достаточные для сборки boost или LO.

Ох уж эти воздыхатели по "инженерному" подходу.
Там уже такой overcommit памяти, что ждите oom killer'а.

> Это при том, что несложно фиксировать CPU/RAM/time по опыту
> предыдущих сборок и неожиданности обрабатывать как исключения.

В моде machine learning?


-- 
ldv

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

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

[Michael Shigorin]

On Fri, Apr 13, 2018 at 04:40:29PM +0300, Dmitry V. Levin wrote:
> > У нас, к сожалению, не так редок "научный" подход к решению
> > задач вместо "инженерного" -- например, каждому hello
> > резервируются ресурсы, достаточные для сборки boost или LO.
> Ох уж эти воздыхатели по "инженерному" подходу.
> Там уже такой overcommit памяти, что ждите oom killer'а.

Дим, ты ведь не оспариваешь то, что:
- ресурсов каждого отдельного pegasus* достаточно для сборки
  любого отдельного пакета в сизифе;
- их же совершенно избыточно для сборки большинства пакетов;
- запуск задач с планированием потребления ресурсов скорее
  понизит (если даже не исключит) риск oom, а не наоборот?

> > Это при том, что несложно фиксировать CPU/RAM/time по опыту
> > предыдущих сборок и неожиданности обрабатывать как исключения.
> В моде machine learning?

Это к cray@ надо было.  Здесь предлагаю всего лишь брать
последнее, даже не тенденцию, и накидывать ефрейторский запас
(пусть полтора-два раза).  Вылезло и взорвалось -- выставляем
исключение, отправляем на "толстую" сборку (или удваиваем).

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

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

[Andrey Savchenko]

On Fri, 13 Apr 2018 16:40:29 +0300 Dmitry V. Levin wrote:
> On Thu, Apr 12, 2018 at 11:09:24PM +0300, Michael Shigorin wrote:
> [...]
> > У нас, к сожалению, не так редок "научный" подход к решению
> > задач вместо "инженерного" -- например, каждому hello
> > резервируются ресурсы, достаточные для сборки boost или LO.
> 
> Ох уж эти воздыхатели по "инженерному" подходу.
> Там уже такой overcommit памяти, что ждите oom killer'а.

Если вероятность oom будет низкой, но не нулевой, zswap (или zram
по выбору) будут очень кстати. Держать 2/3 памяти пустой ради очень
редких случаев коллизий — тоже не дело.

Best regards,
Andrew Savchenko