Bug 39276 - girar task run --limits [small|normal(default)|large] option
Summary: girar task run --limits [small|normal(default)|large] option
Status: NEW
Alias: None
Product: Infrastructure
Classification: Infrastructure
Component: girar (show other bugs)
Version: unspecified
Hardware: x86_64 Linux
: P5 enhancement
Assignee: placeholder@altlinux.org
QA Contact: Andrey Cherepanov
URL:
Keywords:
Depends on:
Blocks: 39324 39328 39614
  Show dependency tree
 
Reported: 2020-11-12 23:26 MSK by viy
Modified: 2021-06-21 01:31 MSK (History)
6 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description viy 2020-11-12 23:26:03 MSK
Еще раз всплыла проблема неадаптируемых лимитов сборочницы, о том, что пакеты разные и нет одного универсального лимита для всех пакетов
которая ранее встречалась редко и поэтому заметалась под ковер,
как, к примеру, в https://bugzilla.altlinux.org/show_bug.cgi?id=31683
(я тоже не особо страдал из-за отсутствия решения, так как в случае чего
удалял пакет из Сизифа и собирал в autoimports).

Но сейчас проблема всплыла в java. Я об ней писал в
https://lists.altlinux.org/pipermail/devel/2020-October/212079.html
После добавления armh noarch пакеты java должны пересобираться и на этой архитектуре, но сборка на armh и сама по себе у нас медленная,
и там умолчальной сейчас не-JIT JVM, что еще тормозит и выводит сборку за лимиты, соответственно, сборочница убивает задания раньше, чем они успели собраться.
Таких заданий уже скопилась небольшая очередь,
#259882 FAILED #1 sisyphus srpm=jruby-1.7.22-alt2_10jpp8.src.rpm
#259809 FAILED #2 sisyphus srpm=batik-1.11-alt1_3jpp8.src.rpm srpm=fop-2.4-alt1_1jpp8.src.rpm
#259709 FAILED #1 sisyphus srpm=jakarta-activation-1.2.2-alt1_1jpp9.src.rpm
#259499 FAILED #2 sisyphus srpm=jogl2-2.3.2-alt3_9jpp8.src.rpm
#259490 NEW #1 p9 srpm=java-10-openjdk-10.0.2.13-alt2_7jpp9.src.rpm
#259439 FAILED #2 sisyphus srpm=sbt-0.13.1-alt6_9.1jpp8.src.rpm
#259324 FAILED #1 sisyphus srpm=java-9-openjdk-9.0.4.11-alt4_6jpp8.src.rpm
#257261 FAILED #2 p9 srpm=java-9-openjdk-9.0.4.11-alt2_6jpp8.M90P.1.src.rpm

С этой статистикой можно оценить число пострадавших пактов в Сизифе в 30-120 шт.

Предлагаю, как самый ленивый вариант, ввести набор опций для управления лимитами, к примеру, wlimit_time_elapsed => --limit-time-elapsed large
с дискретным набором значений (normal=0/large=1 или normal(default)=0/small=1/large=2)
и примитивной реализацией:

сгенерировать на сборочных массив псевдопользователей с разными лимитами
и вычислять нужный номер псевдопользователя по опциям нужный номер псевдопользователя.
No=No-as-before+(Total pseudousers before)*(limit-time-elapsed)+(Total before)^2*(limit-time-idle)+ ... (Total before)^N*(limit-N)

Упрощая - завести в hasher-priv каждого сборочного узла еще 2 псевдопользователя
с номерами +100 и +200
к примеру normal -- обычный номер hasher (к примеру, 0),
small - номер hasher +100
large - номер hasher +200
и таким образом при сборке выбирать номер с нужным лимитом.

Пригодится как пользователям, желающим уменьшить какой-то лимит (если в пакете есть тенденция зависать в тестах), так и желающим увеличить какой-то лимит.
Comment 1 Dmitry V. Levin 2020-11-20 18:42:19 MSK
Все такие изменения быстро не делаются.
Comment 2 viy 2020-11-20 22:02:53 MSK
(Ответ для Dmitry V. Levin на комментарий #1)
> Все такие изменения быстро не делаются.

я думаю, что пара месяцев в запасе есть.
Comment 3 viy 2021-01-18 05:17:44 MSK
С time-idle limit мне помог хак от zerg' - добавить в спек 
(while true; do date; sleep 7m; done) &
который, хоть и безобразное решение, но позволяет обходить лимиты сборочницы.
а вот с wlimit_time_elapsed там все глухо,
так что проблема по прежнему серьезная.
в частности, по wlimit_time_elapsed не собирается бутстрапный jvm 9 в p9.
А он нужен и сам по себе, и чтобы ним собрать jvm 10 которым собрать jvm 11.
Comment 4 Andrey Cherepanov 2021-01-18 09:31:56 MSK
(Ответ для viy на комментарий #2)
> (Ответ для Dmitry V. Levin на комментарий #1)
> > Все такие изменения быстро не делаются.
> 
> я думаю, что пара месяцев в запасе есть.

Пара месяцев прошла. Дима, мы из-за отсутствия openjdk-11 не можем использовать в p9 javafx для сторонних приложений.
Comment 5 Dmitry V. Levin 2021-01-18 12:17:29 MSK
(In reply to Andrey Cherepanov from comment #4)
> (Ответ для viy на комментарий #2)
> > (Ответ для Dmitry V. Levin на комментарий #1)
> > > Все такие изменения быстро не делаются.
> > 
> > я думаю, что пара месяцев в запасе есть.
> 
> Пара месяцев прошла. Дима, мы из-за отсутствия openjdk-11 не можем
> использовать в p9 javafx для сторонних приложений.

Мне кажется, что ваши усилия направлены по неправильному адресу.
Comment 6 Dmitry V. Levin 2021-02-06 19:32:53 MSK
В результате никто не захотел кодить костыли для удобной сборки пакетов, которые не собираются за 8 часов.  Это ненормально, таких пакетов не должно быть.