From: Igor Vlasenko <vlasenko@imath.kiev.ua> To: devel@lists.altlinux.org Subject: [devel] Сборочница (III): Зачем ускорять? Date: Sat, 17 Feb 2018 19:27:35 +0200 Message-ID: <20180217172735.GA30426@dad.imath.kiev.ua> (raw) Уважаемые господа, в предыдущих письмах я писал о том, что сборочница медленная, и о том, как ее можно существенно ускорить, без покупки нового железа, только за счет внесения изменений в алгоритм ее работы. В этом письме хочу рассмотреть вопрос, зачем ее надо ускорять. Моими уважаемыми оппонентами в этом вопросе выступили Алексей и Дмитрий, которые привели аргументы 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
next reply other threads:[~2018-02-17 17:27 UTC|newest] Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top 2018-02-17 17:27 Igor Vlasenko [this message] 2018-02-18 0:01 ` Dmitry V. Levin 2018-02-19 15:25 ` Igor Vlasenko
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=20180217172735.GA30426@dad.imath.kiev.ua \ --to=vlasenko@imath.kiev.ua \ --cc=devel@lists.altlinux.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: link
ALT Linux Team development discussions This inbox may be cloned and mirrored by anyone: git clone --mirror http://lore.altlinux.org/devel/0 devel/git/0.git # If you have public-inbox 1.1+ installed, you may # initialize and index your mirror using the following commands: public-inbox-init -V2 devel devel/ http://lore.altlinux.org/devel \ devel@altlinux.org devel@altlinux.ru devel@lists.altlinux.org devel@lists.altlinux.ru devel@linux.iplabs.ru mandrake-russian@linuxteam.iplabs.ru sisyphus@linuxteam.iplabs.ru public-inbox-index devel Example config snippet for mirrors. Newsgroup available over NNTP: nntp://lore.altlinux.org/org.altlinux.lists.devel AGPL code for this site: git clone https://public-inbox.org/public-inbox.git