From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: To: devel@lists.altlinux.org References: <20200827022952.GA8129@dad.imath.kiev.ua> From: Anton Farygin Organization: BaseALT Message-ID: <5acc7f44-c122-d4ab-c67b-85275232f482@basealt.ru> Date: Thu, 27 Aug 2020 10:27:11 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.1.1 MIME-Version: 1.0 In-Reply-To: <20200827022952.GA8129@dad.imath.kiev.ua> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: ru Subject: Re: [devel] =?utf-8?b?aW5jb21pbmcvZ2lyYXI6INC/0YDQvtCx0LvQtdC80LAg?= =?utf-8?b?0L/RgNC+0LjQt9Cy0L7QtNC40YLQtdC70YzQvdC+0YHRgtC4Lg==?= X-BeenThere: devel@lists.altlinux.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: ALT Linux Team development discussions List-Id: ALT Linux Team development discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Aug 2020 07:27:11 -0000 Archived-At: List-Archive: List-Post: On 27.08.2020 05:29, Igor Vlasenko wrote: > 1. incoming/girar: проблема видна была издалека. > ________________________________________________ > Не надо жалеть сборочницу, это робот, который работает за электроэнергию. > "Жалеть" сборочницу и издеваться над людьми --- это и есть извращение. > Сборочницу не надо "жалеть", ее надо переписать для улучшения > производительности. Тогда хорошо будет всем. > > Игорь, спасибо за интересное и длинное письмо по этому важному вопросу. Я вот тоже чуть чуть сбоку пытаюсь пилить какую-то аналитику по сборочнице и, на самом деле, хочу сказать что большая пропускная способность сборочницы может вылезти боком в другом месте - в архиве. Предлагаю считать постулатом тот факт, что архив состояний репозитория на каждое сборочное задание - это отличная и очень удобная фича, отказываться от которой очень не хочется. Но нужно понимать, что эта клёвая фича основана на использовании в качестве базы данных файловой системы. Т.е. - для экономии места старые пакеты хардлинкаются в новое место и в него уже добавляются изменения из сборочного задания. Очень простая и очень надёжная схема, при которой риск потери данных минимален и всегда можно взять консистентное состояние репозитория за любой момент времени. Живёт это всё сейчас, вроде как, на ext4 (я могу ошибаться). Максимальное количество inodes у ext4 2^32 - 4,294,967,295 Каждый новый таск в репозиторий приводит к тому, что на файловой системе появляется около 160 тысяч (а может быть и больше, я давно не смотрел цифры) новых записей. Т.е. - условно мы можем записать около 26 тысяч сборочных заданий в архив, а после этого из него придётся удалять что-то старое для того, что бы записать что-то новое. Дальше можно порассуждать на предмет смены файловой системы, но я (для зеркала архива) проводил сравнение и более-менее рабочим вариантом оказалась только zfs, которая работает быстрее всего остального подобного, но сильно медленнее ext4. Вообще, конечно, наверняка можно переделать архитектуру архива, например уложить все эти хардлинки в базу данных, но в этом случае будет регресс в плане юзабилити архива - он станет доступен только по http, без возможности смонтировать. В общем, я бы начал именно отсюда, но у Димы наверняка есть какой-то план работ по сборочнице, про который не знает никто, кроме тех, кто принимает участие в её разработки. С другой стороны, если весь perl собирается в одном задании, о мои рассуждения о том, что есть какая-то проблема с архивом - ничтожны, и в данном случае проблема в чём-то другом. Что касается лично моего мнения по тому сборочному заданию с perl - на мой взгляд, увеличение релиза в пакете для rebuild - это нормальная практика и я не вижу в этом ничего плохого, скорее даже наоборот - в этом есть некоторый смысл, т.к. (я про это уже неоднократно писал) - в процессе rebuild пакет становится другим и было бы неплохо научиться его отличать по имени файла, а не только по его содержимому. авторы фичи с DistTag обещали добавить что-то в имена файлов, но пока это всё остановилось на обещаниях. И ещё пару слов про автоматическую пересборку для мелких исправлений пакетов: есть (не)маленькая проблема с тем, что в результате такой пересборки может получится не просто изменение тэга License, но и вообще другой пакет, с другим содержимым и работающий иначе, чем до пересборки.  Просто потому, что необходимые ему для сборки пакеты меняются в тех местах, в которых сборочница отследить эти изменения не может.