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. Дорого это или очень дорого? Я не знаю. Автомобиль, могущий производить впечатление на красивых женщин, стоит примерно столько же. > Без оптимизации или без спонсора, явно - > не обойтись ;) Ни у кого нет подруги - > дочери нефтяного магната ?