From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Message-ID: <4D4DB3BD.6060307@altlinux.com> Date: Sat, 05 Feb 2011 23:31:57 +0300 From: Anton Farygin User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.9pre) Gecko/20100817 Thunderbird/3.1.3pre MIME-Version: 1.0 To: ALT Linux Team development discussions References: <4D4C0377.1080203@altlinux.ru> <4D4C0A45.6020709@altlinux.com> <4D4C13B6.1030300@altlinux.ru> <4D4C14DB.90306@altlinux.com> <4D4C15E9.9030509@altlinux.ru> <4D4C1991.3030601@altlinux.com> <20110204193443.GF11630@altlinux.org> <4D4CD360.8060704@altlinux.com> <4D4DA94F.6010403@altlinux.com> <20110205200330.GB1824@altlinux.org> In-Reply-To: <20110205200330.GB1824@altlinux.org> Content-Type: text/plain; charset=windows-1251; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [devel] =?windows-1251?b?8+blIOTg4u3uIO3lIO4g5O7q8+zl7fLg9ujo?= 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: Sat, 05 Feb 2011 20:30:28 -0000 Archived-At: List-Archive: List-Post: 05.02.2011 23:03, Dmitry V. Levin пишет: > On Sat, Feb 05, 2011 at 10:47:27PM +0300, Anton Farygin wrote: >> 05.02.2011 10:09, Aleksey Novodvorsky пишет: >>> 5 февраля 2011 г. 7:34 пользователь Anton Farygin написал: >>>> 04.02.2011 22:34, Dmitry V. Levin пишет: >>>>> Т.н. карманы можно было бы реализовать >>>>> ещё в прошлом году. Параллельная >>>>> обработка заданий была реализована в >>>>> первую очередь как первый шаг на >>>>> пути к реализации этих карманов. Потом >>>>> мы столкнулись с непреодоленными >>>>> до сих пор организационно-техническими >>>>> преградами, о необходимости >>>>> преодоления которых все >>>>> заинтересованные, надеюсь, помнят >>>>> постоянно. >>>> >>>> Т.е. - если я правильно понял этот тонкий >>>> намёк - у нас сейчас тонкое место >>>> - это отсутствие необходимых серверных >>>> мощностей и каналов связи. >>> >>> Да. Это главная и застарелая проблема, >>> которая не решается парой серверов. >> >> А каким количеством серверов она >> решается ? > > Это зависит от постановки задачи. Например, от того, сколько карманов в > единицу времени требуется обрабатывать одновременно (в среднем и > максимально). Давай будем считать, что собирать пакеты на данный момент нужно в два кармана в еденицу времени (ровно для того, что бы заложить в архитектуру распараллеливание сборок). Реализация параллельной обработки показала, что большой > объем вычислительных мощностей требуется не только для сборки самих > пакетов на вычислительных узлах, но также и для вычисления нового > состояния репозитория с последующими проверками целостности. Сейчас все > такие вычисления централизованы, и мне очевидно, что система начинает > заметно проседать уже при параллельном вычислении двух состояний разных > репозиториев. Очевидно, что система, рассчитанная на _одновременную_ > обработку нескольких заданий с вычислением репозиториев, должна > распределять по узлам не только сборку самих пакетов, но и все сложные > вычисления по репозиториям. Опыт показал, что качество кэширования > радикально влияет на производительность системы, производящей вычисления > над репозиторием. Это значит, что последовательная обработка двух разных > репозиториев на одном узле заметно снижает производительность этой > обработки. Мне кажется, что в обработке состояний репозитория ещё масса возможностей для ускорения, одно из которых - безусловно, кеширование различных состояний процесса обработки.. Кстати, не факт что для карманов нужно предоставлять полную копию используемого репозитория, зачастую достаточно показать результаты сборки task'а в таком виде, который можно отдать apt'у в качестве sources.list. Т.е. - мне кажется что в случае с карманами не надо гарантировать стабильность той среды, в которой этот самый карман сформирован, в любом случае он предоставляется для пользователей того или иного репозитория, и сам карман должен развиваться одновременно с тем репозиторием (в идеальном случае - автоматически). Как следствие этого совсем не обязательно формировать новый репозиторий для целевой ветки и выполнять на нём все тесты.