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

[Anton Farygin <rider@basealt.ru>]

On 27.08.2020 05:29, Igor Vlasenko wrote:
> 1. incoming/girar: проблема видна была издалека.
> ________________________________________________
<skip>
> Не надо жалеть сборочницу, это робот, который работает за электроэнергию.
> "Жалеть" сборочницу и издеваться над людьми --- это и есть извращение.
> Сборочницу не надо "жалеть", ее надо переписать для улучшения
> производительности. Тогда хорошо будет всем.
>
>
Игорь, спасибо за интересное и длинное письмо по этому важному вопросу.

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

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

Но нужно понимать, что эта клёвая фича основана на использовании в 
качестве базы данных файловой системы.

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

Живёт это всё сейчас, вроде как, на ext4 (я могу ошибаться). 
Максимальное количество inodes у ext4 2^32 - 4,294,967,295

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

Т.е. - условно мы можем записать около 26 тысяч сборочных заданий в 
архив, а после этого из него придётся удалять что-то старое для того, 
что бы записать что-то новое.

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


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

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

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

Что касается лично моего мнения по тому сборочному заданию с perl - на 
мой взгляд, увеличение релиза в пакете для rebuild - это нормальная 
практика и я не вижу в этом ничего плохого, скорее даже наоборот - в 
этом есть некоторый смысл, т.к. (я про это уже неоднократно писал) - в 
процессе rebuild пакет становится другим и было бы неплохо научиться его 
отличать по имени файла, а не только по его содержимому.

авторы фичи с DistTag обещали добавить что-то в имена файлов, но пока 
это всё остановилось на обещаниях.

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