[devel] ресурсоёмкое тестирование пакетов

Ср Май 20 16:46:10 MSD 2009

On Wed, May 20, 2009 at 09:41:55AM +0400, Anton Farygin wrote:
> Alexey Tourbin пишет:
> >А также ясно, что основная проблема с 
> >ресурсами и с распараллеливанием
> >лежит в другой плоскости.  Она связана не 
> >со сборкой самих заданий, а с
> >тестовой пересборкой репозитария для 
> >каждого задания.
> >
> >Тестовая пересборка сизифа для каждого 
> >задания -- это очень круто (то
> >есть, это challenge).  Дольно сложно будет 
> >реализовать её оптимально.
> >С другой стороны, тестовая пересборка 
> >дает наиболее полное представление
> >о целостности репозитария (то есть, дает 
> >комплексную оценку пригодности
> >пакетов).  Мы же не в крестики-нолики 
> >играем, а хотим поддерживать
> >целостный репозитарий.  Это дорогое 
> >развлечение.
> 
> Кстати, тогда уж целью стоит объявлять 
> выявление и устранение изменений в 
> результатах пересборки после каждого 
> нового пакета.
> 
> Например, после появления glibc, каждый 
> пересобранный пакет уже не равен 
> существующему пакету в репозитории (по 
> зависимостям).

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

Такая модель данных в основном уже продумана.  Она называется
"метарепозитарий".  Метарепозитарий описывает состояния пакетов в
репозитарии.  Для пакетов, которые прошли тестовую пересборку, вводится
специальное "фантомное состояние".  Все фантомные состояния, которые
возникают в результате тестовой пересборки пакетов, должны явно
фиксироваться в метарпозитарии.  Метарепозитарий позволяет
интроспективно отслеживать изменения свойств (существующих) пакетов,
когда эти изменения обусловлены изменениями в сборочной среде.
Метарепозитарий позволяет выяснить, какие именно пакеты/задания влияют
на результат сборки существующих пакетов.

С философской точки зрения, метарепозитарий позволяет частично
предсказывать будущее; точнее, делать наиболее обоснованные
предсказания.  Эти предсказания полностью никогда сбываться не будут,
но у них будет правильное направление.  Я не буду подробнее
останавливаться на философских аспектах.

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

Такую пересобиралку несложно реализовать (когда будет реализовано всё
остальное), но, скорее всего, её не следует реализовывать.  Во-первых,
они будет генерировать очень большой трафик.  Более того, если для
пересобиралки задать слишком жесткие условия, то процесс пересборки
никогда не закончится (например, новый gcc будет пересобран с новой
glibc; тогда уже нужно опять пересобирать glibc с новым gcc и т.д.).
Во-вторых, я считаю, что сборкой пакетов должны заниматься люди, а не
роботы.

> Тогда можно и параллелить (аккуратно, 
> естественно).

У тебя есть навязчивая идея, что нужно распараллеливать сборку.
У ldv есть навязчивая идея, что ACL нужно проверять до, а не после
сборки пакета.  Нам нужно осовободиться от навязчивых идей.  Я считаю,
что самое главное -- это поддержка целостности репозитарий (и я не
отношу это к навязчивой идее).  Всякие оптимизации -- это вторично.

> Да, а железа для этого нужно, судя по 
> всему - раз в 50 больше, чем сейчас. С 
> учётом того, что сейчас пересборка 
> сизифа занимает порядка трёх суток (72 
> часа), а мы не можем допустить, что бы у 
> нас пакет собирался более чем разумное 
> время (в данном контексте, думаю, один час 
> - вполне разумно), то текущее количество 
> сборочных серверов нужно умножить на 72 
> (на самом деле - больше, нужно считать 
> overhead на постановку задач/сеть).

Существуют оценки потребности в железе для полной пересборки сизифа.
Эти оценки основываются на двух простых постулатах: 1) некоторые вещи
распараллелить нельзя; 2) некоторые другие вещи распараллелить можно.
В частности, речь идет о том, что тестовую сборку отдельного пакета
распараллелить или ускорить почти никак нельзя, а пересборка репозитария
очень хорошо поддается распараллеливанию.  Тогда мы устанавливаем время
полной пересборки репозитария на уровне самого сложного пакета (где-то
два-три часа) и смотрим, сколько ещё нужно ресурсов, чтобы эа зто же самое
время успеть пересобрать все пакеты попроще.

Для одной архитектуры получается оценка 57 процессорных ядер (в
предположении, что ядра дают линейное распараллеливание).

> С учётом того, что в данный момент (по 
> словам ldv) задействовано 4 сервера, для 
> полной автоматизации этого процесса 
> необходимо порядка 288 серверов.

Для полной пересборки сизифа на двух архитектурах требуется 57*2=114
ядер, в большую сторону это округляются до 128.  Следовательно требуется
32 четырехядерных процессора.  Я беру процессоры класса Nehalem Xeon,
потому что другие процессоры брать нет смысла.  Это получается 16
двухпроцессорных лезвий.  Теперь можно округлить в меньшую сторону.
Сейчас выпускаются корпуса высотой 7U, в которые входит 10 лезвий.
Это примерно то, что нам нужно.

Впрочем, я не специалист по железу.

> Это чуть меньше половины кластера СКИФ 
> Т-60, который считается одним из самых 
> мощных в России и стоил порядка 10 
> миллионов долларов. И потребляет порядка 
> 0.5 мегаватта энергии в час.

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

Посмотрим, сколько это _минимум_ может стоить.  Процессор Xeon E5520
стоит $457, к нему нужно минимум 12G памяти.  12G DDR-III kit стоит $265.
Всего нужно 32 таких комплекта.  Получается 32*(457+265)=$23k на
микросхемы.  Цена всего вместе может быть где-то в районе $50k.
Дорого это или очень дорого?  Я не знаю.  Автомобиль, могущий
производить впечатление на красивых женщин, стоит примерно столько же.

> Без оптимизации или без спонсора, явно - 
> не обойтись ;) Ни у кого нет подруги - 
> дочери нефтяного магната ?
----------- следующая часть -----------
Было удалено вложение не в текстовом формате...
Имя     : отсутствует
Тип     : application/pgp-signature
Размер  : 197 байтов
Описание: отсутствует
Url     : <http://lists.altlinux.org/pipermail/devel/attachments/20090520/906f04f9/attachment-0001.bin>