[devel] Сборочница. VII. Алгоритмы ускорения сборки Больших Транзакций.

* [devel] Сборочница. VII. Алгоритмы ускорения сборки Больших Транзакций.
@ 2018-03-03 13:02 Igor Vlasenko
  2018-03-05  4:14 ` Андрей Бергман
  0 siblings, 1 reply; 7+ messages in thread
From: Igor Vlasenko @ 2018-03-03 13:02 UTC (permalink / raw)
  To: devel

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

Продолжаю цикл писем, посвященный предложениям по улучшению
нашей сборочницы.

VII. Алгоритмы ускорения сборки Больших Транзакций.

Большие транзакции естественно возникают при обновлении
многих языковых экосистем. У нас на слуху perl и python,
сейчас добавился texlive, но это только потому, что они
хорошо представлены в Сизифе и регулярно обновляются.

На самом деле это типичная проблема. Просто ранее 
большинство языковых экосистем у нас были представлены
только базовым компилятором или интерпретатором и ограниченным набором
основных библиотек. На самом деле такая ситуация не очень
хороша. Это как дать пользователю базовую систему
(ядро+shell+cc) и сказать, а дальше собирайте сами.
Тем не менее, большинство предпочтет полноценный дистрибутив.
Но сейчас ALTLinux вырастает из детских штанишек,
и у него растут требования к поддержке, в. т. ч.
различных языковых экосистем.
Поэтому Большие Транзакции (как пересборка питона с 3000+ пакетов)
все чаще и чаще посещают нашу сборочницу.

К сожалению, наша сборочница к ним не готова.
30 суток на обработку питона или 10 суток на обработку texlive
нельзя назвать адекватным ответом задаче.

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

Однако в параллельной сборочнице сборку Больших Транзакций
тоже можно ускорить. Но в данном случае автоматические
алгоритмы предлагаю использовать в сочетании со специальной
разметкой пакетов транзакции человеком.

Именно, часть subtask'ов в task'е надо пометить как синхронные.

Синхронный subtask означает, что, пока синхронный subtask и
все ему предыдущие не собраны, параллельная сборочница не пытается
собрать subtask'и, следующие за синхронным.

К примеру, при обновлении perl я помечу самый первый subtask в
транзакции, perl, как синхронный.
Все остальные subtask'и в обновлении perl я помечать (как синхронный)
не буду, пусть сборочница пытается их собрать параллельно.

Для полноты опишу алгоритм.
У транзакции есть пул собранных пакетов, в начале пустой.
Субтаски могут иметь флаг "синхронный",
а внутри состояния "ожидает", "собирается", "собран", "ошибка сборки",
"в пуле" (собранные пакеты добавлены в пул).
есть указатель головы сборки.

Начиная с головы, субтаски ставятся в параллельную сборку с текущим
пулом по порядку номеров в числе имеющихся параллельных потоков
сборки, но лишь до тех пор, пока не встретится "синхронный"
или "ошибка сборки" субтаск.
Если первый же субтаск, на который указывает текущий указатель,
"синхронный" или "ошибка сборки", он единственный отправляется
на сборку, неудача сборки делает всю транзакцию FAILED.
Собранные субтаски добавляются в пул, указатель инкрементируется.
(есть тонкости как реализовывать, синхронно проще, асинхронно быстрее).

Алгоритм прост, небольшая дополнительная сложность пользователю,
что нужно еще разметить транзакцию и запустить не как по умолчанию,
а со специальной опцией --parallelize.

Зато вместо 10 суток результат будет через 10 часов.

-- 

I V

^ permalink raw reply	[flat|nested] 7+ messages in thread