Алгоритмы параллельной обработки пакетов для сборочницы дистрибутива (Игорь Власенко, OSSDEVCONF-2021) — различия между версиями
Материал из 0x1.tv
StasFomin (обсуждение | вклад) |
StasFomin (обсуждение | вклад) |
||
Сейчас можно проигнорировать запросы «крупнотоннажных» пользователей, рассудив что текущая сборочница по скорости устраивает большинство, и является критическим сервисом, работающим 24/7, поэтому к ней применим принцип «работает — не трогай». Это со временем приведёт к проблемам всего дистрибутива. А пока докладчик сейчас находится в положении «паникёров 1940—1941 года». Таких никто никогда не любил. Их было положено игнорировать и изолировать, чтобы не портили общую благостную картину «дружбы народов с отдельными недостатками», пока не грянула беда.
{{----}}
[[File:{{#setmainimage:Алгоритмы параллельной обработки пакетов для сборочницы дистрибутива (Игорь Власенко, OSSDEVCONF-2021)!.jpg}}|center|640px]]
{{LinksSection}}
<!-- <blockquote>[©]</blockquote> -->
{{fblink|2976454599274208}}
<references/>
{{stats|disqus_comments=0|refresh_time=2021-08-31T16:47:13.191835|vimeo_plays=0|youtube_plays=0}}
[[Категория:OSSDEVCONF-2021]]
[[Категория:ALT Linux]] |
Версия 08:02, 27 октября 2021
- Докладчик
- Игорь Власенко
В докладе будут описаны алгоритмы параллелизации обработки заданий в сборочнице и параллелизации сборки внутри одного задания, позволяющие в десятки, а в некоторых случаях при наличии вычислительных мощностей и в сотни раз ускорить обаботку заданий в официальной сборочнице ALT Linux, а также будут обсуждаться психологические причины, мешающие их внедрению.
Содержание
Видео
Презентация
Thesis
В настоящее время сборочница достаточно медленна и неудобна на задачах большого объёма, таких, как обновление perl или python, или при обработке большого числа мелких задач, к примеру — обновление java, которое выполняются последовательно и растягивается на многие часы, а то и сутки, хотя при хорошей параллелизации могли бы быть обработаны за несколько минут.
В то же время для большинства пользователей работа со сборочницей сейчас всё ещё находится в зоне комфорта. Можно предположить, что субъективная комфортная скорость работы сборочницы связана с его скоростью подготовки пакетов. То есть если человек за 8 часов подготовил 2 пакета и сборочница обработала их за 4 часа, то она достаточно быстрая. Если же человек за 8 часов подготовил 10 пакетов, и сборочница обработала их за 10 часов, то это уже субъективно медленная сборочница. Тот факт, что «крупнозадачные» пользователи страдают, показывает, что бутылочное горлышко пропускной способности сборочницы достигается слишком легко. У здорового дистрибутива пакетная масса растёт, и это только вопрос времени, когда в постоянных пробках окажутся и задания обычных пользователей. Альтернативно, плохая сборочница может стать (и становится, на примере p9-p10) фактором, тормозящим рост пакетной массы дистрибутива и, тем самым, угнетающим его развитие.
Общедистрибутивная сборочница по своей природе сложна для независимой разработки. Обычный опенсорсный проект можно форкнуть и пользоваться, сборочницу форкнуть можно, но пользоваться придётся старой, если не удастся убедить принять изменения. Чтобы не писать код «в стол», первым шагом надеюсь убедить в необходимости изменений. Хороший правитель не рубит голову гонцу, принёсшему дурные вести. Хороший полководец не пропускает сообщение, что передовые отряды терпят потери.
Сейчас можно проигнорировать запросы «крупнотоннажных» пользователей, рассудив что текущая сборочница по скорости устраивает большинство, и является критическим сервисом, работающим 24/7, поэтому к ней применим принцип «работает — не трогай». Это со временем приведёт к проблемам всего дистрибутива. А пока докладчик сейчас находится в положении «паникёров 1940—1941 года». Таких никто никогда не любил. Их было положено игнорировать и изолировать, чтобы не портили общую благостную картину «дружбы народов с отдельными недостатками», пока не грянула беда.
Примечания и ссылки
Plays:0
Comments:0