Re: [devel] incoming/girar: проблема производительности.

[Michael Shigorin <mike@altlinux.org>]

On Thu, Aug 27, 2020 at 05:29:53AM +0300, Igor Vlasenko wrote:
> Года 3 назад я написал ряд писем в devel@, которые описывали
> алгоритмы параллелизации работы сборочницы, которые позволили
> бы существенно (на порядки) повысить ее производительность.
> Содержимое этих писем доступно на
> https://www.altlinux.org/Girar/Parallel .

Игорь, спасибо, что наконец рассказал эту историю!
Мы уж действительно переживали -- что с тобой,
а предположить было не из чего.

2 rider: спасибо и за твой рассказ; про архив думал упомянуть,
         хорошо, что сперва прочёл и второе письмо.

> Дмитрий заинтересовался, но не совсем тем, чем хотелось,
> а вопросом, нельзя ли как-то уменьшить число релизов от моих
> роботов, что я в итоге сделал для импорта из федоры и магейи,
> и начал делать для java.

Немножко поправлю: Дима тогда возмутился тем, что на альт
начинают фактически оказывать прямое влияние политики выпуска
Fedora Project -- например, пересборка всего перед каждым
выпуском (осмысленность такого вообще и конкретно у нас --
отдельный интересный вопрос, который когда-то в ключе
(не)использования результатов тестовых пересборок поднимал
led@; но сейчас только сошлюсь на этот факт).

> В итоге серверную часть girar будет намного легче сопровождать,
> и можно будет думать о внедрении современных стандартов,
> вроде динамической балансировки нагрузки, менеджеров нод и других
> атрибутов современного кластера.

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

> Сейчас у меня, возможно, получится объяснить.

Ух! :)

> Но я после недели обсуждений с Дмитрием так и не смог пробить
> #36531 в апстрим hasher :(. В итоге форкнул свою копию hasher
> и свернул свою разработку прототипа локальной сборочницы. :(

Free software, каким мы его знаем и любим.

> Поскольку Дмитрий, похоже, считал, что медленная сборочница --
> это не баг, а фича, то на заливающих большое число пакетов
> будет смотреть, как на спамеров сборочницы.

Насколько помню, в сопутствующих обсуждениях в devel@ было два
момента: чужие полиси и опасения по поводу смешивания генерата
и рукоделия (вопрос качества при этом многогранный и ни разу
не однозначный в любую сторону, не хочу сейчас вздымать его).

> Надо сказать, Дмитрий и раньше злоупотреблял своим положением
> администратора сборочницы, но когда речь шла об одиночных
> пакетах, то обычно была какая-то польза или хотя бы повод,
> а вреда от остановки task'а особого не было, одиночный пакет
> можно потом перезалить хоть через полгода, сделанная работа
> не пропадет зря.  В случае же с транзакциями все наоборот.

Как наверняка знают наиболее продвинутые из нас -- власть
развращает, а уж абсолютная и несменяемая -- это как раз
либо монархия, либо тирания.

  Предлагаю такое правило: если Дима решает помочь с задачей,
  то есть настолько точно знает лучше, как её сделать, что
  вмешивается без вопросов -- значит, Дима берёт на себя
  ответственность за её решение или отмену.

> Эмоции в корректной форме можно было выразить анекдотом:

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

> Через неделю улучшенные скрипты были готовы, можно было продолжать.
> Но вместо обновления получился цирк, так как Дмитрий
> продолжил мне помогать, а я слова не мог сказать, поскольку
> боялся поддаться эмоциям и начать выражаться нецензурно.

Если что -- пиши, позвоню, изложишь в любом виде.
Постараюсь перевести.

> Проблема была в том, что и Дмитрий действовал не со зла и не
> нарочно, но получилось по пословице "простота хуже воровства".

Дима, предлагаю ещё один приём.  Представь, что ты -- Путин,
а несколько процентов команды -- оппозиция.  Не те идиоты,
которые вообще не слушают и только орут "Левин, уходи",
а люди вроде тебя, в целом настроенные конструктивно,
но близко к сердцу принимающие твои ошибки, особенно
оформленные как вроде бы помощь.

И у тебя есть выбор -- или таких расстрелять/выслать/посадить
(но тем лишиться их рук и голов), или налаживать диалог даже
с теми, кто не демократии вместо димакратии требует -- а всего-то
не мешать, считая по старой привычке, что разбираешься во всём
(каждый из нас за эти двадцать лет прошёл свой большой путь,
вряд ли найдётся два схожих).

> Вернемся к истокам. Сборочница рассчитана на условного майнтайнера
> с относительно малым числом но достаточно глубоко сопровождаемых
> пакетов, для которого производительность сборочницы не играет особой
> роли. Пример такого майнтайнера -- сам Дмитрий.
> Для него сборочница комфортна.
> 
> Со мной Дмитрий пытался оптимизировать майнтайнера к сборочнице,
> а я хотел наоборот. Что же мне мешает оптимизироваться?

Ну есть и оптимизация на производительность, но она сосредоточена
скорее в пересборочнице, результаты работы которой отбрасываются
(и это сильно другой инвариант).  И там цель не "как можно
быстрее", а "уложиться с пересборкой всего сизифа в одни сутки"
(здесь, возможно, ещё один заранее не очевидный тебе подводный
камень насчёт роста репозмитория).

> Мешает то, что его оптимизация майнтайнера к сборочнице
> сводится к экономии машинного времени сборочницы
> за счет растраты времени майнтайнера.

Это советский подход, да.

> Рассмотрим, к примеру, наше новое полиси по заполнению лицензий.

По поводу этого непрозрачного изменения в быте майнтейнера
у меня к Диме тоже большие вопросы -- честно говоря, и от
Лёши тогда ожидал услышать хотя бы постфактум пояснение
необходимости срочно внедрять _блокирующую_ проверку,
но так его и не услышал.

> Не надо жалеть сборочницу, это робот, который работает за электроэнергию.
> "Жалеть" сборочницу и издеваться над людьми --- это и есть извращение.
> Сборочницу не надо "жалеть", ее надо переписать для улучшения
> производительности. Тогда хорошо будет всем.

В общем, Дима, перевожу на русский без мата: у тебя уже МАЗ
бастует, причём именно в результате твоих действий (даже не
бездействия), зато без накачки из сопредельных проектов.

-- 
 ---- WBR, Michael Shigorin / http://altlinux.org
  ------ http://opennet.ru / http://anna-news.info