[devel] Сборочница (III): Зачем ускорять?
Igor Vlasenko
vlasenko на imath.kiev.ua
Сб Фев 17 20:27:35 MSK 2018
Уважаемые господа,
в предыдущих письмах я писал о том, что сборочница медленная,
и о том, как ее можно существенно ускорить, без покупки нового
железа, только за счет внесения изменений в алгоритм ее работы.
В этом письме хочу рассмотреть вопрос, зачем ее надо ускорять.
Моими уважаемыми оппонентами в этом вопросе выступили
Алексей и Дмитрий, которые привели аргументы 2-х классов.
1) примеры перегрузки сборочницы некорректные, так как представляют
собой неправильные практики майнтайнерства.
2) не надо гнаться за производительностью, превышающей средний трафик.
зачем сборочнице простаивать?
Начну разбор с 1-го класса возражений.
Более обще,
> Сборка пакета имеет смысл, если она меняет что-то у пользователя. Если
> на стороне пользователя ничего не меняется, то вы создаете
> бессмысленный шум. Но есть большая индустрия "очистки спеков" и т.п.,
> которая, за неимением лучшего, выдается за "разработку". Вы выступаете
> апологетом порочных практик, исходя из примитивно понятых базовых
> показателей. Возможно даже вы делаете это добросовестно.
и более конкретно,
> Очевидно, что публиковать якобы новые сборки пакетов, в которых
> ничего не меняется, не просто не нужно, но и вредно.
[...]
> Слепо пересобирать чужие сборки из-за записи в %changelog'е вида
> - Rebuilt for https://fedoraproject.org/wiki/Fedora_NN_Mass_Rebuild
> не просто не нужно, но и вредно.
По поводу импорта, я уже много писал, не хочу повторяться.
Однако, неужели в других дистрибутивах ни багов не чинят, ни пакетов
не обновляют и не улучшают? В импорт только Mass_Rebuild и попадает?
Да, есть недостаток индивидуального подхода к каждому кусту.
Это как копать картошку трактором,
по сравнению с ротой стройбата с лопатами.
Проблема в том, что нас мало, не тянем мы на роту,
максимум на два взвода. Поэтому, tractor it is.
Другой критикуемый пример -- пересборка python-*
без BR: python-modules-setuptools-tests.
Кто-то предлагал, зачем рубить шашкой все пакеты,
проще сделать хак и забыть.
Вот пример, когда-то сделал хак и забыл, а оно зажило своей жизнью
и начало разрастаться по Сизифу.
https://bugzilla.altlinux.org/show_bug.cgi?id=34535
Когда увидел, был в шоке! Когда понял, что это такое и зачем,
облегченно вздохнул. /Да, это ужас, но не Ужас-Ужас./
Но шашкой или топором, в будущем вырубить это надо.
Кто-то предлагал, давайте изменения накапливать в git-ах,
а в сборочницу не отправлять. Так в этом случае крайним
окажется giter - там места не хватит.
Отправлять в Сизиф, а не копить у себя -
это сейчас хорошая, годная стратегия.
Это как "Вы скорбите по тем временам, когда мужчины
были настоящими мужчинами и сами писали драйверы устройств?"
Мужики перевелись? Нет.
Раньше железо было дорого, а сейчас дешево.
Раньше писать драйвер было осмысленно, сейчас проще выбросить
и купить подходящее -- редкое, очень редкое железо дорого
настолько, чтобы писать к нему драйвер было осмысленно.
Раньше пакетов было мало, и майнтайнеры могли позволить себе
держать их в голове. А сейчас пакетов много, и между ними надо
постоянно переключаться. Отсюда и новый ритм -
сделал, отправил, забыл.
Что делать, такие времена, такие нравы.
Продолжу разбор по 2-му классу возражений.
2а)
> Понимаете, в чем дело. Время всё равно уходит, а сборочица всё равно
> простаивает. И показатель несколько тысяч транзакций в сутки всё равно
> не нужен. То есть вы занимаетесь неправильной задачей оптимизации.
"Уже сейчас сборочница иногда простаивает. А если мы сборочницу
оптимизируем, то она начнет простаивать гораздо чаще.
А простаивать неправильно."
Будет простаивать --- хорошо, освободившиеся мощности можно занять под
тот же супербихайв: пересборка + полное сборочностное
тестирование пакетов из Сизифа. Роботы можно подключить,
майнтайнеры потянутся, если сборка там будет быстрее, чем локально.
2b)
> Вряд ли мы хотим решать задачу принимать в Сизиф 60*60*24/2==43200
> транзакций в сутки (в среднем по 2 секунды на транзакцию), это число
> более чем в 2 раза превышает число исходных пакетов в нынешнем Сизифе.
> Такая задача сама по себе не выглядит осмысленной.
Как раз очень даже осмысленная задача. 43200 транзакций в сутки --
это не ожидаемый трафик, а желаемая пиковая мощность,
следствием которой является повышение "отзывчивости" сборочницы,
что приводит к повышению производительности труда ее пользователей.
На эту тему есть хорошая притча.
Приходит сисадмин к директору
с предложением расширить канал доступа в интернет.
Директор посмотрел обоснование и сказал: с таким
трафиком, как у нас, мы не расширять,
а еще в 100 раз ужать канал можем,
чтобы приблизить ширину канала к реальному трафику,
заодно и деньги сэкономим.
Сисадмин сказал: смешивать трафик и ширину канала
(пиковую мощность) некорректно.
Рассмотрим к примеру унитаз.
Трафик у него относительно небольшой,
однако ширину канала у него стараются делать как можно больше.
Да. большую часть времени он простаивает.
Но если в нем появляется трафик, то его нужно
как можно быстрее пропустить через устройство,
для чего к нему и подводят такой широкий канал.
Если же канал сузить, то трафик будет проходить
за время, неприемлемое для пользователя.
Если в офисе веб-страница загружается за 10 мин,
то, формально, в офисе есть интернет.
Если в туалете унитаз сливается за 10 мин,
то, формально, в офисе есть туалет.
Если в сборочнице легкая транзакция обрабатывается 3 суток,
то, формально, сборочница в порядке.
При этом сотрудник был на 3 суток лишен обратной связи
и был вынужден переключиться на другие задачи.
И я понимаю сотрудников, которые в такой ситуации призывают
* тяжелые сайты не посещать
* по большому не ходить
* пакеты в сборочницу лишний раз не заливать.
Но лучше все-таки прислушаться к тревожному звонку
и обратиться к админу/сантехнику/разработчику. Заранее.
--
I V
Подробная информация о списке рассылки Devel