[devel] I: git.alt update

[devel] I: git.alt update

[Dmitry V. Levin]

[-- Attachment #1: Type: text/plain, Size: 194 bytes --]

Hi,

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


-- 
ldv

[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]

Re: [devel] I: git.alt update

[Dmitry V. Levin]

[-- Attachment #1: Type: text/plain, Size: 449 bytes --]

On Wed, Oct 27, 2010 at 10:57:48AM +0400, Dmitry V. Levin wrote:
> Hi,
> 
> Сегодня и, возможно, последующие дни будет происходить ползучее обновление
> git.alt, поэтому просьба возможные отказы в обслуживании воспринимать
> соответствующим образом.

Для тех, кто работает со структурой TASK напрямую:
http://git.altlinux.org/people/ldv/packages/?p=girar-builder.git;a=blobdiff;f=TASK;hb=0.1-117-gd1c949a;hpb=0.1-116-gcb7491d


-- 
ldv

[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]

Re: [devel] I: git.alt update

[Kirill A. Shutemov]

On Wed, Oct 27, 2010 at 12:59:13PM +0400, Dmitry V. Levin wrote:
> On Wed, Oct 27, 2010 at 10:57:48AM +0400, Dmitry V. Levin wrote:
> > Hi,
> > 
> > Сегодня и, возможно, последующие дни будет происходить ползучее обновление
> > git.alt, поэтому просьба возможные отказы в обслуживании воспринимать
> > соответствующим образом.
> 
> Для тех, кто работает со структурой TASK напрямую:
> http://git.altlinux.org/people/ldv/packages/?p=girar-builder.git;a=blobdiff;f=TASK;hb=0.1-117-gd1c949a;hpb=0.1-116-gcb7491d

TASK_ID/build/repo, думаю, тоже стоит описать.

> 
> 
> -- 
> ldv



> _______________________________________________
> Devel mailing list
> Devel@lists.altlinux.org
> https://lists.altlinux.org/mailman/listinfo/devel


-- 
 Kirill A. Shutemov

Re: [devel] I: git.alt update

[Dmitry V. Levin]

[-- Attachment #1: Type: text/plain, Size: 686 bytes --]

On Wed, Oct 27, 2010 at 12:04:36PM +0300, Kirill A. Shutemov wrote:
> On Wed, Oct 27, 2010 at 12:59:13PM +0400, Dmitry V. Levin wrote:
> > On Wed, Oct 27, 2010 at 10:57:48AM +0400, Dmitry V. Levin wrote:
> > > Hi,
> > > 
> > > Сегодня и, возможно, последующие дни будет происходить ползучее обновление
> > > git.alt, поэтому просьба возможные отказы в обслуживании воспринимать
> > > соответствующим образом.
> > 
> > Для тех, кто работает со структурой TASK напрямую:
> > http://git.altlinux.org/people/ldv/packages/?p=girar-builder.git;a=blobdiff;f=TASK;hb=0.1-117-gd1c949a;hpb=0.1-116-gcb7491d
> 
> TASK_ID/build/repo, думаю, тоже стоит описать.

pushed


-- 
ldv

[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]

Re: [devel] I: git.alt update

[REAL]

Michael Shigorin пишет:
> On Thu, Oct 28, 2010 at 02:38:17PM +0400, Anton V. Boyarshinov wrote:
>> Давайте не будем так больше делать, а..
> 
> Дальше предстоит регулерятор в виде "не больше одного
> параллельного таска на логин"

Я за.

-- 

REAL aka Евгений Ростовцев, программист ЦНИТ КемГУ

Re: [devel] I: git.alt update

[Anton V. Boyarshinov]

Добрый день
С одной стороны, сегодня знаменательный день: в Сизифе заработала
паралелльная сборка.
С другой стороны, без малого 30 отдельных заданий по одному
пакету отправленных пользователем real резко снижают положительный
эффект. Они блокируют сборочницу для всех прочих не менее эффективно,
чем раньше блокировало одно большое задание :(

Давайте не будем так больше делать, а..
Антон

Re: [devel] I: git.alt update

[Michael Shigorin]

On Thu, Oct 28, 2010 at 02:38:17PM +0400, Anton V. Boyarshinov wrote:
> Давайте не будем так больше делать, а..

Дальше предстоит регулерятор в виде "не больше одного
параллельного таска на логин" и общая ручка "не больше
кол-ва ядер"?

-- 
 ---- WBR, Michael Shigorin <mike@altlinux.ru>
  ------ Linux.Kiev http://www.linux.kiev.ua/

Re: [devel] I: git.alt update

[Anton V. Boyarshinov]

On Thu, 28 Oct 2010 13:40:05 +0300 Michael Shigorin wrote:

> On Thu, Oct 28, 2010 at 02:38:17PM +0400, Anton V. Boyarshinov wrote:
> > Давайте не будем так больше делать, а..
> 
> Дальше предстоит регулерятор в виде "не больше одного
> параллельного таска на логин"
Было бы здорово.

> и общая ручка "не больше
> кол-ва ядер"?
Насколько я понимаю, количество паралелльных сборок имеет ручку и
фиксированно.

Re: [devel] I: git.alt update

[Andrey Rahmatullin]

[-- Attachment #1: Type: text/plain, Size: 546 bytes --]

On Thu, Oct 28, 2010 at 01:40:05PM +0300, Michael Shigorin wrote:
> > Давайте не будем так больше делать, а..
> Дальше предстоит регулерятор в виде "не больше одного
> параллельного таска на логин"
"и мы даже знаем этот логин"

-- 
WBR, wRAR
Powered by the ALT Linux fortune(6):

> [...] использовать в пакетах /etc/ld.so.conf.d/ ВМЕСТО
> традиционных записей в /etc/ld.so.conf пока рано.
Ok. Некоторые из нас уже успели заиспользовать "ВМЕСТО" эту
функциональность. В связи с этим ждите новую сборку XFree86.
		-- rider in devel@

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 490 bytes --]

Re: [devel] I: git.alt update

[Dmitry V. Levin]

[-- Attachment #1: Type: text/plain, Size: 345 bytes --]

On Thu, Oct 28, 2010 at 05:07:49PM +0600, Andrey Rahmatullin wrote:
> On Thu, Oct 28, 2010 at 01:40:05PM +0300, Michael Shigorin wrote:
> > > Давайте не будем так больше делать, а..
> > Дальше предстоит регулерятор в виде "не больше одного
> > параллельного таска на логин"
> "и мы даже знаем этот логин"

На каждый логин.


-- 
ldv

[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]

Re: [devel] I: git.alt update

[Terechkov Evgenii]

On Thu, 28 Oct 2010 14:38:17 +0400, "Anton V. Boyarshinov" <boyarsh@altlinux.org> wrote:

> С одной стороны, сегодня знаменательный день: в Сизифе заработала
> паралелльная сборка.

В одной стороны, это замечательно! Даже, пожалуй, УРА!

> С другой стороны, без малого 30 отдельных заданий по одному
> пакету отправленных пользователем real резко снижают положительный
> эффект. Они блокируют сборочницу для всех прочих не менее эффективно,
> чем раньше блокировало одно большое задание :(

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

-- 
                                                С уважением, Терешков
                                                Евгений.

Re: [devel] I: git.alt update

[Anton V. Boyarshinov]

On Thu, 28 Oct 2010 19:46:20 +0800 Terechkov Evgenii wrote:

> С другой стороны хотелось бы документации (хоть какой-то, кроме кода),
> описывающей, как оно работает. Чтобы ненароком не парализовать всё :-)
Я думаю, Диме (когда он закончит хакать сборочницу) будет нужнее
выспаться, а там уж и о документации можно будет поговорить..

Re: [devel] I: git.alt update

[Rinat Bikov]

28 октября 2010 г. 14:38 пользователь Anton V. Boyarshinov написал:
> Добрый день
> С одной стороны, сегодня знаменательный день: в Сизифе заработала
> паралелльная сборка.
Следующая стадия - параллельная установка  rpm/apt-get? :)

-- 
С уважением, Ринат Биков.

Re: [devel] I: git.alt update

[Anton Farygin]

28.10.2010 16:08, Rinat Bikov пишет:
> 28 октября 2010 г. 14:38 пользователь Anton V. Boyarshinov написал:
>> Добрый день
>> С одной стороны, сегодня знаменательный день: в Сизифе заработала
>> паралелльная сборка.
> Следующая стадия - параллельная установка  rpm/apt-get? :)

очень хотелось бы чаще чем раз в день иметь возможность забирать свежий 
сизиф.

лучше всего - сразу после сборки каждого задания.

Re: [devel] I: git.alt update

[Dmitry V. Levin]

[-- Attachment #1: Type: text/plain, Size: 1207 bytes --]

On Thu, Oct 28, 2010 at 07:46:20PM +0800, Terechkov Evgenii wrote:
> On Thu, 28 Oct 2010 14:38:17 +0400, "Anton V. Boyarshinov" <boyarsh@altlinux.org> wrote:
> 
> > С одной стороны, сегодня знаменательный день: в Сизифе заработала
> > паралелльная сборка.
> 
> В одной стороны, это замечательно! Даже, пожалуй, УРА!
> 
> > С другой стороны, без малого 30 отдельных заданий по одному
> > пакету отправленных пользователем real резко снижают положительный
> > эффект. Они блокируют сборочницу для всех прочих не менее эффективно,
> > чем раньше блокировало одно большое задание :(
> 
> С другой стороны хотелось бы документации (хоть какой-то, кроме кода),
> описывающей, как оно работает. Чтобы ненароком не парализовать всё :-)

Основное отличие: задания выполняются в порядке, который со стороны
выглядит как произвольный.  Другими словами, отправив на сборку 2 задания
одно за другим, вы не можете рассчитывать на то, что они будут собраны в
том или ином порядке.  Если вам нужна упорядоченная сборка, то объединяйте
несколько заданий в одно.

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


-- 
ldv

[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]

Re: [devel] I: git.alt update

[Денис Смирнов]

[-- Attachment #1: Type: text/plain, Size: 996 bytes --]

On Thu, Oct 28, 2010 at 04:37:59PM +0400, Dmitry V. Levin wrote:

DVL> Основное отличие: задания выполняются в порядке, который со стороны
DVL> выглядит как произвольный.  Другими словами, отправив на сборку 2 задания
DVL> одно за другим, вы не можете рассчитывать на то, что они будут собраны в
DVL> том или ином порядке.  Если вам нужна упорядоченная сборка, то объединяйте
DVL> несколько заданий в одно.

Это часто очень плохо. То есть, скажем, есть пакет A и есть B. Я хочу
обновить A, а потом пересобрать с ним B (причем эта пересборка --
необязательна).

Очевидно что мне важен порядок сборки. Однако от A могут зависеть также B,
C, D -- чей порядок сборки уже не важен. Важно чтобы A собрался раньше.

Все проблемы чудесно решила бы возможность для task'а сказать "пытаться
собрать этот task только после успешного завершения вон того task'а".

-- 
С уважением, Денис

http://mithraen.ru/
----------------------------------------------------------------------------

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [devel] I: git.alt update

[Dmitry V. Levin]

[-- Attachment #1: Type: text/plain, Size: 1256 bytes --]

On Thu, Oct 28, 2010 at 04:44:06PM +0400, Денис Смирнов wrote:
> On Thu, Oct 28, 2010 at 04:37:59PM +0400, Dmitry V. Levin wrote:
> 
> DVL> Основное отличие: задания выполняются в порядке, который со стороны
> DVL> выглядит как произвольный.  Другими словами, отправив на сборку 2 задания
> DVL> одно за другим, вы не можете рассчитывать на то, что они будут собраны в
> DVL> том или ином порядке.  Если вам нужна упорядоченная сборка, то объединяйте
> DVL> несколько заданий в одно.
> 
> Это часто очень плохо. То есть, скажем, есть пакет A и есть B. Я хочу
> обновить A, а потом пересобрать с ним B (причем эта пересборка --
> необязательна).
> 
> Очевидно что мне важен порядок сборки. Однако от A могут зависеть также B,
> C, D -- чей порядок сборки уже не важен. Важно чтобы A собрался раньше.
> 
> Все проблемы чудесно решила бы возможность для task'а сказать "пытаться
> собрать этот task только после успешного завершения вон того task'а".

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


-- 
ldv

[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]

Re: [devel] I: git.alt update

[Igor Zubkov]

2010/10/28 Anton Farygin:
> 28.10.2010 16:08, Rinat Bikov пишет:
>> 28 октября 2010 г. 14:38 пользователь Anton V. Boyarshinov написал:
>>>
>>> Добрый день
>>> С одной стороны, сегодня знаменательный день: в Сизифе заработала
>>> паралелльная сборка.
>>
>> Следующая стадия - параллельная установка  rpm/apt-get? :)
>
> очень хотелось бы чаще чем раз в день иметь возможность забирать свежий
> сизиф.
>
> лучше всего - сразу после сборки каждого задания.

Ну это можно сделать на http://prometheus.altlinux.org/. И даже
больше, я это уже давно планирую сделать. Технически, файлы которые
надо отдавать возле самого prometheus уже лежат. Нужно только rails
metal хрень для отдачи написать. Писать там не много, но приоритет
сейчас на другом.

А ещё, было бы реально классно что бы этот путь стоял по умолчанию у
apt при обновлении из Сизифа. Тогда можно будет собирать много-много
статистики. Но это в текущий момент это не получится.

-- 
Igor Zubkov
http://hi.im/ice

Re: [devel] I: git.alt update

[Anton Farygin]

28.10.2010 16:52, Igor Zubkov пишет:
> 2010/10/28 Anton Farygin:
>> 28.10.2010 16:08, Rinat Bikov пишет:
>>> 28 октября 2010 г. 14:38 пользователь Anton V. Boyarshinov написал:
>>>>
>>>> Добрый день
>>>> С одной стороны, сегодня знаменательный день: в Сизифе заработала
>>>> паралелльная сборка.
>>>
>>> Следующая стадия - параллельная установка  rpm/apt-get? :)
>>
>> очень хотелось бы чаще чем раз в день иметь возможность забирать свежий
>> сизиф.
>>
>> лучше всего - сразу после сборки каждого задания.
>
> Ну это можно сделать на http://prometheus.altlinux.org/. И даже
> больше, я это уже давно планирую сделать. Технически, файлы которые
> надо отдавать возле самого prometheus уже лежат. Нужно только rails
> metal хрень для отдачи написать. Писать там не много, но приоритет
> сейчас на другом.
>
> А ещё, было бы реально классно что бы этот путь стоял по умолчанию у
> apt при обновлении из Сизифа. Тогда можно будет собирать много-много
> статистики. Но это в текущий момент это не получится.

Меня интересует только rsync ;)

Re: [devel] I: git.alt update

[Anton V. Boyarshinov]

 
> Это часто очень плохо. То есть, скажем, есть пакет A и есть B. Я хочу
> обновить A, а потом пересобрать с ним B (причем эта пересборка --
> необязательна).
Так и в старой сборочнице нельзя было закладываться на
порядок отправки пакетов. Пакет A мог по какой-либо причине не
собраться и B собрался бы с его старой версией.

Re: [devel] I: git.alt update

[Денис Смирнов]

[-- Attachment #1: Type: text/plain, Size: 521 bytes --]

On Thu, Oct 28, 2010 at 05:01:08PM +0400, Anton V. Boyarshinov wrote:

AVB> Так и в старой сборочнице нельзя было закладываться на
AVB> порядок отправки пакетов. Пакет A мог по какой-либо причине не
AVB> собраться и B собрался бы с его старой версией.

Однако я бы такое сразу заметил, а здесь -- не факт.

Ладно, когда в следующий раз захочу -- напишу внешнюю запускалку task'ов
:)

-- 
С уважением, Денис

http://mithraen.ru/
----------------------------------------------------------------------------

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [devel] I: git.alt update

[Igor Vlasenko]

On Thu, Oct 28, 2010 at 04:50:26PM +0400, Dmitry V. Levin wrote:
DVL> Основное отличие: задания выполняются в порядке, который со стороны
DVL> выглядит как произвольный.  Другими словами, отправив на сборку 2 задания
DVL> одно за другим, вы не можете рассчитывать на то, что они будут собраны в
DVL> том или ином порядке.  Если вам нужна упорядоченная сборка, то объединяйте
DVL> несколько заданий в одно.

:(
 
> > Это часто очень плохо. То есть, скажем, есть пакет A и есть B. Я хочу
> > обновить A, а потом пересобрать с ним B (причем эта пересборка --
> > необязательна).
 
> > Очевидно что мне важен порядок сборки. Однако от A могут зависеть также B,
> > C, D -- чей порядок сборки уже не важен. Важно чтобы A собрался раньше.
> > 
> > Все проблемы чудесно решила бы возможность для task'а сказать "пытаться
> > собрать этот task только после успешного завершения вон того task'а".

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

:(
Это существенно хуже, чем было раньше :(

А если будет введено ограничение по пакету на логин,
то порядок будет гарантироваться?

Кто 1-2 пакета заливает, тот, наверное, и не почувствует разницы,

Но залить 20-40 пакетов, 1 не собрался --- это ужос.
Придется много раз подряд попусту паресобирать одни и те же пакеты :(
Неэффективно, долго, утомительно.

Мне бы хотелось в качестве замены хоть какую-то ручку -
например 
ssh git.alt task commit -- в частично собранном задании все собранные 
пакеты выложить в сизиф.
или особый статус таска, наподобие shared -- skipfail --
не обращать внимание на не собравшиеся пакеты,
все собранные пакеты выложить в сизиф.

-- 

Dr. Igor Vlasenko
--------------------
Topology Department
Institute of Math
Kiev, Ukraine

Re: [devel] I: git.alt update

[Alexey I. Froloff]

[-- Attachment #1: Type: text/plain, Size: 421 bytes --]

On Thu, Oct 28, 2010 at 05:48:46PM +0300, Igor Vlasenko wrote:
> Но залить 20-40 пакетов, 1 не собрался --- это ужос.
Пакуйте тщательнее.

> Придется много раз подряд попусту паресобирать одни и те же пакеты :(
> Неэффективно, долго, утомительно.
Неправда, сборочница уже давно не пересобирает "одни и те же
пакеты" без необходимости.

-- 
Regards,    --
Sir Raorn.   --- http://thousandsofhate.blogspot.com/

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [devel] I: git.alt update

[Igor Vlasenko]

On Thu, Oct 28, 2010 at 06:54:02PM +0400, Alexey I. Froloff wrote:
> On Thu, Oct 28, 2010 at 05:48:46PM +0300, Igor Vlasenko wrote:
> > Но залить 20-40 пакетов, 1 не собрался --- это ужос.
> Пакуйте тщательнее.
> 
> > Придется много раз подряд попусту паресобирать одни и те же пакеты :(
> > Неэффективно, долго, утомительно.
> Неправда, сборочница уже давно не пересобирает "одни и те же
> пакеты" без необходимости.

Это если ковыряться с единственной task.
проще перезалить.

Допустим, я за день собрал 40 пакетов и залил на ночь
в таск. По старой схеме утром в Сизифе 38 пакетов
и 2 с утра на доработку.
По новой схеме в сизифе 0. День впустую.

Старую схему можно сэмулировать, если, например, на ночь
залить пакеты повторно.
Или, если было k итераций, залить пакеты k раз.





-- 

Dr. Igor Vlasenko
--------------------
Topology Department
Institute of Math
Kiev, Ukraine

Re: [devel] I: git.alt update

[Alexey I. Froloff]

[-- Attachment #1: Type: text/plain, Size: 637 bytes --]

On Thu, Oct 28, 2010 at 06:28:37PM +0300, Igor Vlasenko wrote:
> Допустим, я за день собрал 40 пакетов и залил на ночь
> в таск. По старой схеме утром в Сизифе 38
неизвестно как собранных
> пакетов
половину из которых придётся опять пересобрать.

> Старую схему можно сэмулировать, если, например, на ночь
> залить пакеты повторно.
> Или, если было k итераций, залить пакеты k раз.
Это шикарно - лечить собственную криворукость ресурсами
сборочницы.

Хочу всем напомнить про таск с python 2.6 и особенно про действия
админисратора репозитария.

-- 
Regards,    --
Sir Raorn.   --- http://thousandsofhate.blogspot.com/

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

[devel] pockets [was: I: git.alt update]

[Igor Vlasenko]

On Thu, Oct 28, 2010 at 07:38:01PM +0400, Alexey I. Froloff wrote:
> > Старую схему можно сэмулировать, если, например, на ночь
> > залить пакеты повторно.
> > Или, если было k итераций, залить пакеты k раз.
> Это шикарно - лечить собственную криворукость ресурсами
> сборочницы.

Я ожидал такого ответа :)
Алексей, я извиняюсь, поддался удовольствию, как сейчас 
говорится, потроллить.

А если серьезно говорить, без этих k, то проблема в
том, что Сизиф+hasher для работы с библиотеками недостаточно,
нет вытеснений и удалений.

Эта проблема решается карманами, но их у нас нет,
и c ними не так просто. Я у себя организовывал карман, 
назовем его LocalPocket, и скрипты вытеснения,
чтобы сливать Сизиф+hasher в единый репозиторий.
В идеале можно было бы локальный incoming поднять.

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

Получилось намного практичнее заливать за ночь в Сизиф
и утром обновляться.

В общем, LocalPocket вещь теоретически правильная,
но как минимум пока на рабочей машине не вкручу SSD и хотя бы удвою 
оперативку, приходится использовать для слияния/вытеснения/удаления
Сизиф. 

То, что у нас есть (task) это совсем не pocket,
к сожалению.

И, по сути, Дмитрий предложил использовать task
там, где нужен pocket.

Мне для работы нужен pocket. для 1000 пакетов это не 
прихоть. На сборочнице его нет, локально - надо вложить в
машину еще мин. $500. Приловчился обходиться 
Сизифом -- и там засада с порядком сборки.

-- 

Dr. Igor Vlasenko
--------------------
Topology Department
Institute of Math
Kiev, Ukraine

Re: [devel] I: git.alt update

[Michael Shigorin]

On Thu, Oct 28, 2010 at 07:38:01PM +0400, Alexey I. Froloff wrote:
> Хочу всем напомнить про таск с python 2.6 и особенно про
> действия админисратора репозитария.

О, собери перл, а мы посмотрим.

-- 
 ---- WBR, Michael Shigorin <mike@altlinux.ru>
  ------ Linux.Kiev http://www.linux.kiev.ua/

Re: [devel] I: git.alt update

[Денис Смирнов]

[-- Attachment #1: Type: text/plain, Size: 988 bytes --]

On Thu, Oct 28, 2010 at 06:28:37PM +0300, Igor Vlasenko wrote:

IV> Допустим, я за день собрал 40 пакетов и залил на ночь
IV> в таск. По старой схеме утром в Сизифе 38 пакетов
IV> и 2 с утра на доработку.
IV> По новой схеме в сизифе 0. День впустую.

Нам, любителям роботов, все ни по чем :)

Руки не дошли, но собираюсь решать проблему так: создается пачка task'ов,
но не запускается.

Локально у себя описываются зависимости между task'ами, на это
натравливается уже имеющийся сортировщик -- и чудесненько, скрипт сам
будет смотреть какие таски уже DONE, и запускать новые.

Особенно это будет вкусно, если сделают параллельную сборку не "1 на
человека", а все-таки хотя бы round-robin scheduler. Тогда в случае если
на ночь стопку пакетов зальешь ты один, то вероятно даже очередь из
сотни-другой пакетов к утру спокойненько завершится.

-- 
С уважением, Денис

http://mithraen.ru/
----------------------------------------------------------------------------

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [devel] pockets [was: I: git.alt update]

[Alexey I. Froloff]

[-- Attachment #1: Type: text/plain, Size: 379 bytes --]

On Thu, Oct 28, 2010 at 07:22:12PM +0300, Igor Vlasenko wrote:
> Эта проблема решается карманами, ...
"Карманы" - это такое модное слово, которое должно решить
все-все-все проблемы.  Когда-нибудь в перспективе.  Как
отдалённое светлое будущее.

К сожалению чего-то подобного я и ожидал.  tl;dr

-- 
Regards,    --
Sir Raorn.   --- http://thousandsofhate.blogspot.com/

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [devel] I: git.alt update

[Igor Vlasenko]

On Fri, Oct 29, 2010 at 12:07:36AM +0400, Денис Смирнов wrote:
> Нам, любителям роботов, все ни по чем :)
> 
> Руки не дошли, но собираюсь решать проблему так: создается пачка task'ов,
> но не запускается.
> 
> Локально у себя описываются зависимости между task'ами, на это
> натравливается уже имеющийся сортировщик -- и чудесненько, скрипт сам
> будет смотреть какие таски уже DONE, и запускать новые.
> 
> Особенно это будет вкусно, если сделают параллельную сборку не "1 на
> человека", а все-таки хотя бы round-robin scheduler. Тогда в случае если
> на ночь стопку пакетов зальешь ты один, то вероятно даже очередь из
> сотни-другой пакетов к утру спокойненько завершится.

Да, хорошая штука была бы.
Если еще б ее в git.alt вкрутить.
что-то вроде
ssh git.alt task 55555 await 55551 55552 55553 55554

-- 

Dr. Igor Vlasenko
--------------------
Topology Department
Institute of Math
Kiev, Ukraine

Re: [devel] pockets [was: I: git.alt update]

[Michael Shigorin]

On Fri, Oct 29, 2010 at 12:08:40AM +0400, Alexey I. Froloff wrote:
> "Карманы" - это такое модное слово, которое должно решить
> все-все-все проблемы.  Когда-нибудь в перспективе.
> Как отдалённое светлое будущее.

У опенсусешников это давно уж настоящее, дяденька.

-- 
 ---- WBR, Michael Shigorin <mike@altlinux.ru>
  ------ Linux.Kiev http://www.linux.kiev.ua/

Re: [devel] pockets [was: I: git.alt update]

[Igor Vlasenko]

On Fri, Oct 29, 2010 at 12:08:40AM +0400, Alexey I. Froloff wrote:
> On Thu, Oct 28, 2010 at 07:22:12PM +0300, Igor Vlasenko wrote:
> > Эта проблема решается карманами, ...
> "Карманы" - это такое модное слово, которое должно решить
> все-все-все проблемы.  Когда-нибудь в перспективе.  Как
> отдалённое светлое будущее.

Почему. К сборочнице у меня доступа нет, но себе локально
карман сделал, и он мне очень помог. Когда я начинал 
собирать maven2, он мне ломал более 170 пакетов,
и по результатам пересборок в кармане снизил это число
до 70 перед заливкой в Сизиф.

Другое дело, что еще слишком прожорливый.
обновлю железо и буду смотреть, что можно улучшить.

-- 

Dr. Igor Vlasenko
--------------------
Topology Department
Institute of Math
Kiev, Ukraine

Re: [devel] I: git.alt update

[Dmitry V. Levin]

[-- Attachment #1: Type: text/plain, Size: 304 bytes --]

On Thu, Oct 28, 2010 at 04:37:59PM +0400, Dmitry V. Levin wrote:
> Особенности работы внутри всё равно сейчас продолжают меняться.
> О них можно будет рассказать, когда наступит стабилизация.

Перспективы стабилизации более чем туманны, ядро не выдерживает
нагрузку и идёт ко дну. :(


-- 
ldv

[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]

Re: [devel] I: git.alt update

[REAL]

Dmitry V. Levin пишет:
> Особенности работы внутри всё равно сейчас продолжают меняться.
> О них можно будет рассказать, когда наступит стабилизация.

Да, сейчас что-то явно нестабильное творится.

 > ssh git.alt task ls
ssh: connect to host git.altlinux.org port 222: Connection timed out

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

-- 

REAL aka Евгений Ростовцев, программист ЦНИТ КемГУ

Re: [devel] I: git.alt update

[Anton Farygin]

29.10.2010 04:14, Dmitry V. Levin пишет:
> On Thu, Oct 28, 2010 at 04:37:59PM +0400, Dmitry V. Levin wrote:
>> Особенности работы внутри всё равно сейчас продолжают меняться.
>> О них можно будет рассказать, когда наступит стабилизация.
>
> Перспективы стабилизации более чем туманны, ядро не выдерживает
> нагрузку и идёт ко дну. :(

А какое ядро у тебя там используется ?

Есть ли testcase, позволяющий воспроизвести идущее ко дну ядро ?

Re: [devel] I: git.alt update

[REAL]

Anton Farygin пишет:
>>> А ядро поменять не пробовали ?
>> там ovz :( Насколько я понимаю, Дима не готов тестировать на этой
>> машине новые ovz ядра.. Хотя, возможно, уже готов..
>>
>>> насколько я понимаю - для всего этого используется tmpfs ?
>> нет, это на ext3
> 
> Попробовал.

Я немного не по теме, но это всё как-то связано с этим?
 > ssh git.alt task ls
ssh_exchange_identification: Connection closed by remote host

Или это сейчас доступ к git.alt запрещён административно?

-- 

REAL aka Евгений Ростовцев, программист ЦНИТ КемГУ

Re: [devel] I: git.alt update

[Anton V. Boyarshinov]

> > Перспективы стабилизации более чем туманны, ядро не выдерживает
> > нагрузку и идёт ко дну. :(
> 
> А какое ядро у тебя там используется ?
2.6.18-ovz-rhel
 
> Есть ли testcase, позволяющий воспроизвести идущее ко дну ядро ?
Универсального (такого, чтоб работал на любой машине, независимо от
количества памяти, размеров fs и прочего), насколько я понимаю, нет.

Симптомы выглядят примерно так:
Если удалять копию репозитория, а потом воссоздавать её при помощи cp
-al, то для 5.0 повторы этого процесса выглядят правильно, то есть
первый проход занимает 10-15 секунд, последующие 2-5 секунд (так как
заполняются кэши).
Тот же процесс, выплоняемый для Сизифа (процентов на 30 большего, чем
5.0) выполняется около 30 секунд при первом проходе и при последующих
время выполнения быстро растёт (пятый проход уже может длиться пару
минут). Если продолжать в том же духе, машина умирает под грузом IO.

Вчера пробовали крутить настройки виртуальной памяти, насколько я
понимаю, не помогло. Вчера Дима собирался сегодня добавить в эту машину
RAM (сейчас там, если я правильно помню 6гиг).

Re: [devel] I: git.alt update

[REAL]

Anton Farygin пишет:
>> Я немного не по теме, но это всё как-то связано с этим?
>>  > ssh git.alt task ls
>> ssh_exchange_identification: Connection closed by remote host
>>
>> Или это сейчас доступ к git.alt запрещён административно?
> 
> Видимо, непосредственно связано - поток заданий убил ядро на сервере.

Понятно. Такой себе нечаянный DDoS ;)

-- 

REAL aka Евгений Ростовцев, программист ЦНИТ КемГУ

Re: [devel] I: git.alt update

[REAL]

Anton V. Boyarshinov пишет:
>> Насколько я понимаю, git.alt до ввода параллельной сборки не падал.
> Да, но проблема не в сборке как таковой, а в том, что для каждой
> паралелльной сборочницы надо по хорошему клонировать репозиторий в
> начале сборки каждого задания.. В arm-овой сборочнице это обходится при
> помощи костылей и подпорок (grep по логам и если похоже, что выбили
> репозиторий -- перезапуск задания) но это непромышленное решение..

А какое ограничение по количеству параллельных сборок?

-- 

REAL aka Евгений Ростовцев, программист ЦНИТ КемГУ

Re: [devel] I: git.alt update

[Anton V. Boyarshinov]

> время выполнения быстро растёт (пятый проход уже может длиться пару
> минут).
или даже больше 5 минут..

Re: [devel] I: git.alt update

[Anton Farygin]

29.10.2010 10:06, Anton V. Boyarshinov пишет:
>
>>> Перспективы стабилизации более чем туманны, ядро не выдерживает
>>> нагрузку и идёт ко дну. :(
>>
>> А какое ядро у тебя там используется ?
> 2.6.18-ovz-rhel
>
>> Есть ли testcase, позволяющий воспроизвести идущее ко дну ядро ?
> Универсального (такого, чтоб работал на любой машине, независимо от
> количества памяти, размеров fs и прочего), насколько я понимаю, нет.
>
> Симптомы выглядят примерно так:
> Если удалять копию репозитория, а потом воссоздавать её при помощи cp
> -al, то для 5.0 повторы этого процесса выглядят правильно, то есть
> первый проход занимает 10-15 секунд, последующие 2-5 секунд (так как
> заполняются кэши).
> Тот же процесс, выплоняемый для Сизифа (процентов на 30 большего, чем
> 5.0) выполняется около 30 секунд при первом проходе и при последующих
> время выполнения быстро растёт (пятый проход уже может длиться пару
> минут). Если продолжать в том же духе, машина умирает под грузом IO.
>
> Вчера пробовали крутить настройки виртуальной памяти, насколько я
> понимаю, не помогло. Вчера Дима собирался сегодня добавить в эту машину
> RAM (сейчас там, если я правильно помню 6гиг).

А ядро поменять не пробовали ?

насколько я понимаю - для всего этого используется tmpfs ?

Re: [devel] I: git.alt update

[Anton V. Boyarshinov]

> А ядро поменять не пробовали ?
там ovz :( Насколько я понимаю, Дима не готов тестировать на этой
машине новые ovz ядра.. Хотя, возможно, уже готов..

> насколько я понимаю - для всего этого используется tmpfs ?
нет, это на ext3

Re: [devel] I: git.alt update

[Anton Farygin]

29.10.2010 10:33, Anton V. Boyarshinov пишет:
>
>> А ядро поменять не пробовали ?
> там ovz :( Насколько я понимаю, Дима не готов тестировать на этой
> машине новые ovz ядра.. Хотя, возможно, уже готов..

Ядро первым делом надо поменять, от ovz надо отказываться на серверах с 
такой нагрузкой - зачем он там ?

У меня на сервере с ядром ovz постоянно вылезают разные подземные стуки, 
но там нет поддержки аппаратной виртуализации и не получается уйти на kvm ;(

>
>> насколько я понимаю - для всего этого используется tmpfs ?
> нет, это на ext3

Я сейчас попробую это воспроизвести на своих серверах, но что-то мне 
подсказывает, что std-def и un-def не будет подвержен такой проблеме.

Даже el 2.6.32 должен работать по идее стабильнее и быстрее, чем старое 
2.6.18.

Re: [devel] I: git.alt update

[Anton V. Boyarshinov]

On Fri, 29 Oct 2010 10:40:01 +0400 Anton Farygin wrote:

> 29.10.2010 10:33, Anton V. Boyarshinov пишет:
> >
> >> А ядро поменять не пробовали ?
> > там ovz :( Насколько я понимаю, Дима не готов тестировать на этой
> > машине новые ovz ядра.. Хотя, возможно, уже готов..
> 
> Ядро первым делом надо поменять, от ovz надо отказываться на серверах с 
> такой нагрузкой - зачем он там ?
Там контейнеры..

> У меня на сервере с ядром ovz постоянно вылезают разные подземные стуки, 
> но там нет поддержки аппаратной виртуализации и не получается уйти на kvm ;(

> Я сейчас попробую это воспроизвести на своих серверах, но что-то мне 
> подсказывает, что std-def и un-def не будет подвержен такой проблеме.
Возможно. aspsk@ обратил наше внимание на
http://bugzilla.openvz.org/1520

> Даже el 2.6.32 должен работать по идее стабильнее и быстрее, чем старое 
> 2.6.18.
Да, но контейнеры...

Re: [devel] I: git.alt update

[Anton Farygin]

29.10.2010 10:33, Anton V. Boyarshinov пишет:
>
>> А ядро поменять не пробовали ?
> там ovz :( Насколько я понимаю, Дима не готов тестировать на этой
> машине новые ovz ядра.. Хотя, возможно, уже готов..
>
>> насколько я понимаю - для всего этого используется tmpfs ?
> нет, это на ext3

Попробовал.

копирование и удаление всегда занимает примерно равное время (плюс-минус 
секунда) от 4 до 5 секунд и на 20 итерациях хуже не стало.

Ядро 2.6.32, ext4, диск подключен по фибре 300 мегабайт/секунду.

Сейчас синхронизирую сизиф на другой сервер и посмотрю что будет там - 
drbd + ocfs2 на обычных SATA дисках.

Re: [devel] I: git.alt update

[Anton Farygin]

29.10.2010 10:42, Anton V. Boyarshinov пишет:
> On Fri, 29 Oct 2010 10:40:01 +0400 Anton Farygin wrote:
>
>> 29.10.2010 10:33, Anton V. Boyarshinov пишет:
>>>
>>>> А ядро поменять не пробовали ?
>>> там ovz :( Насколько я понимаю, Дима не готов тестировать на этой
>>> машине новые ovz ядра.. Хотя, возможно, уже готов..
>>
>> Ядро первым делом надо поменять, от ovz надо отказываться на серверах с
>> такой нагрузкой - зачем он там ?
> Там контейнеры..

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

Re: [devel] I: git.alt update

[Anton Farygin]

29.10.2010 09:56, REAL пишет:
> Anton Farygin пишет:
>>>> А ядро поменять не пробовали ?
>>> там ovz :( Насколько я понимаю, Дима не готов тестировать на этой
>>> машине новые ovz ядра.. Хотя, возможно, уже готов..
>>>
>>>> насколько я понимаю - для всего этого используется tmpfs ?
>>> нет, это на ext3
>>
>> Попробовал.
>
> Я немного не по теме, но это всё как-то связано с этим?
>  > ssh git.alt task ls
> ssh_exchange_identification: Connection closed by remote host
>
> Или это сейчас доступ к git.alt запрещён административно?

Видимо, непосредственно связано - поток заданий убил ядро на сервере.

Re: [devel] I: git.alt update

[Anton V. Boyarshinov]

On Fri, 29 Oct 2010 13:56:50 +0800 REAL wrote:

> Я немного не по теме, но это всё как-то связано с этим?
>  > ssh git.alt task ls
> ssh_exchange_identification: Connection closed by remote host
> 
> Или это сейчас доступ к git.alt запрещён административно?
git.alt находится в одном из контейнеров на сервере, тяжёлую судьбу
которого мы обсуждаем.

Re: [devel] I: git.alt update

[Anton V. Boyarshinov]

> Контейнеры надо уносить с этого сервера. всё равно при высоком IO они 
> будут тормозить так, что мало не покажется.
git.alt интенсивно работает с этой fs и именно он и создаёт эту
нагрузку.. Если унести его на другой сервер, лучше не будет. С другой
стороны -- это повод оставить его одного на dedicated машине без всяких
соседей..

Re: [devel] I: git.alt update

[Anton Farygin]

29.10.2010 10:56, Anton V. Boyarshinov пишет:
>
>> Контейнеры надо уносить с этого сервера. всё равно при высоком IO они
>> будут тормозить так, что мало не покажется.
> git.alt интенсивно работает с этой fs и именно он и создаёт эту
> нагрузку.. Если унести его на другой сервер, лучше не будет. С другой
> стороны -- это повод оставить его одного на dedicated машине без всяких
> соседей..

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

По крайней мере на ovz...

Надо разносить на разные машины с единым хранилищем, подключенным чем-то 
быстрее чем Ethernet.

До этого момента я бы банально сборку отдал бы другой, отдельно 
выделенной для этого системе.

Насколько я понимаю, git.alt до ввода параллельной сборки не падал.

Re: [devel] I: git.alt update

[Anton Farygin]

29.10.2010 10:07, REAL пишет:
> Anton Farygin пишет:
>>> Я немного не по теме, но это всё как-то связано с этим?
>>> > ssh git.alt task ls
>>> ssh_exchange_identification: Connection closed by remote host
>>>
>>> Или это сейчас доступ к git.alt запрещён административно?
>>
>> Видимо, непосредственно связано - поток заданий убил ядро на сервере.
>
> Понятно. Такой себе нечаянный DDoS ;)

Да, и это на самом деле крайне плохо - видна вся мнимая надёжность ovz 
ядра и технологии в целом.

Впрочем, может быть на каком-то более специфичном оборудовании с менее 
высокой нагрузкой оно и работает.

Re: [devel] I: git.alt update

[Anton V. Boyarshinov]

> Надо разносить на разные машины с единым хранилищем, подключенным чем-то 
> быстрее чем Ethernet.
Если я правильно понимаю, наиболее интенсивно работающую с fs часть
сборочницы поместили непосредственно на едином хранилище (куда уж
быстрее). И оно утонуло..
 
> До этого момента я бы банально сборку отдал бы другой, отдельно 
> выделенной для этого системе.
Собственно сборка, если я правильно понимаю, идёт на других машинах.

>Насколько я понимаю, git.alt до ввода параллельной сборки не падал.
Да, но проблема не в сборке как таковой, а в том, что для каждой
паралелльной сборочницы надо по хорошему клонировать репозиторий в
начале сборки каждого задания.. В arm-овой сборочнице это обходится при
помощи костылей и подпорок (grep по логам и если похоже, что выбили
репозиторий -- перезапуск задания) но это непромышленное решение..

Re: [devel] I: git.alt update

[Anton Farygin]

29.10.2010 11:09, Anton V. Boyarshinov пишет:
>
>> Надо разносить на разные машины с единым хранилищем, подключенным чем-то
>> быстрее чем Ethernet.
> Если я правильно понимаю, наиболее интенсивно работающую с fs часть
> сборочницы поместили непосредственно на едином хранилище (куда уж
> быстрее). И оно утонуло..

Хранилища бывают разными. В данном случае, конечно же, ещё зависит и от 
ядра, от RAID контроллера и от самой системы.

>
>> До этого момента я бы банально сборку отдал бы другой, отдельно
>> выделенной для этого системе.
> Собственно сборка, если я правильно понимаю, идёт на других машинах.

Т.е - умирает только cp -al ???

>
>> Насколько я понимаю, git.alt до ввода параллельной сборки не падал.
> Да, но проблема не в сборке как таковой, а в том, что для каждой
> паралелльной сборочницы надо по хорошему клонировать репозиторий в
> начале сборки каждого задания.. В arm-овой сборочнице это обходится при
> помощи костылей и подпорок (grep по логам и если похоже, что выбили
> репозиторий -- перезапуск задания) но это непромышленное решение..

А сборочницы к репозитарию по NFS ходят ?

Re: [devel] I: git.alt update

[Anton V. Boyarshinov]

> >> До этого момента я бы банально сборку отдал бы другой, отдельно
> >> выделенной для этого системе.
> > Собственно сборка, если я правильно понимаю, идёт на других машинах.
> 
> Т.е - умирает только cp -al ???
Да. rsync не лучше (долго вычисляет список файлов), а вот специальный
клонировщик, который не делал бы это каждый раз с нуля, может оказаться
куда эффективнее, но его надо ещё написать, да так, чтоб не глючил
(пересоздание с нуля в целом надёжнее).

А регулярный cp -al убивает систему..

> А сборочницы к репозитарию по NFS ходят ?
Да. Да много ли им надо?

Re: [devel] I: git.alt update

[Anton Farygin]

29.10.2010 11:24, Anton V. Boyarshinov пишет:
>
>>>> До этого момента я бы банально сборку отдал бы другой, отдельно
>>>> выделенной для этого системе.
>>> Собственно сборка, если я правильно понимаю, идёт на других машинах.
>>
>> Т.е - умирает только cp -al ???
> Да. rsync не лучше (долго вычисляет список файлов), а вот специальный
> клонировщик, который не делал бы это каждый раз с нуля, может оказаться
> куда эффективнее, но его надо ещё написать, да так, чтоб не глючил
> (пересоздание с нуля в целом надёжнее).

rsync очень медленно работает, согласен.

>
> А регулярный cp -al убивает систему..

cp -al вполне себе оптимальный вариант. Если бы ядро не глючило.

А много-ли параллельных cp -al запускается одновременно ? Это 
воспроизводится на другом железе ?

>
>> А сборочницы к репозитарию по NFS ходят ?
> Да. Да много ли им надо?

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

Re: [devel] I: git.alt update

[Anton V. Boyarshinov]

 
> А много-ли параллельных cp -al запускается одновременно ? Это 
> воспроизводится на другом железе ?
В норме обычно 1, но иногда до 3. В норме это когда он 7 секунд
выполняется. А когда 5 минут, то 3 могут быть запросто :(

Re: [devel] I: git.alt update

[Vladimir Lettiev]

On Fri, Oct 29, 2010 at 11:24:23AM +0400, Anton V. Boyarshinov wrote:
> 
> > >> До этого момента я бы банально сборку отдал бы другой, отдельно
> > >> выделенной для этого системе.
> > > Собственно сборка, если я правильно понимаю, идёт на других машинах.
> > 
> > Т.е - умирает только cp -al ???
> Да. rsync не лучше (долго вычисляет список файлов), а вот специальный
> клонировщик, который не делал бы это каждый раз с нуля, может оказаться
> куда эффективнее, но его надо ещё написать, да так, чтоб не глючил
> (пересоздание с нуля в целом надёжнее).
> 
> А регулярный cp -al убивает систему..
> 
> > А сборочницы к репозитарию по NFS ходят ?
> Да. Да много ли им надо?

А нельзя ли как-то использовать unionfs, чтобы цеплять базовый сборочный
чрут в RO, а сверху монтировать файловую систему (tmpfs) для записи?

-- 
Vladimir Lettiev aka crux ✉ theCrux@gmail.com

Re: [devel] I: git.alt update

[Mykola S. Grechukh]

2010/10/29 Vladimir Lettiev <>:
> А нельзя ли как-то использовать unionfs, чтобы цеплять базовый сборочный
> чрут в RO, а сверху монтировать файловую систему (tmpfs) для записи?

aufs

-- 
Mykola Grechukh
RISC Group IT Solutions

Re: [devel] I: git.alt update

[Anton V. Boyarshinov]

> А нельзя ли как-то использовать unionfs, чтобы цеплять базовый сборочный
> чрут в RO, а сверху монтировать файловую систему (tmpfs) для записи?
Может быть и можно, но зачем? Сборка и так идёт в tmpfs. Проблема не в
сборке как таковой, а в создани копий репозитория для каждой сборочницы.

Re: [devel] I: git.alt update

[Mykola S. Grechukh]

2010/10/29 Anton V. Boyarshinov <>:
>
>> А нельзя ли как-то использовать unionfs, чтобы цеплять базовый сборочный
>> чрут в RO, а сверху монтировать файловую систему (tmpfs) для записи?
> Может быть и можно, но зачем? Сборка и так идёт в tmpfs. Проблема не в
> сборке как таковой, а в создани копий репозитория для каждой сборочницы.

То же самое, вероятно, можно делать с репозитарием вместо копирования.

-- 
Mykola Grechukh
RISC Group IT Solutions

Re: [devel] I: git.alt update

[Anton Farygin]

29.10.2010 11:36, Anton V. Boyarshinov пишет:
>
>> А нельзя ли как-то использовать unionfs, чтобы цеплять базовый сборочный
>> чрут в RO, а сверху монтировать файловую систему (tmpfs) для записи?
> Может быть и можно, но зачем? Сборка и так идёт в tmpfs. Проблема не в
> сборке как таковой, а в создани копий репозитория для каждой сборочницы.

Да и aufs и unionfs это те ещё глюки ;)

Re: [devel] I: git.alt update

[Damir Shayhutdinov]

>> А нельзя ли как-то использовать unionfs, чтобы цеплять базовый сборочный
>> чрут в RO, а сверху монтировать файловую систему (tmpfs) для записи?
> Может быть и можно, но зачем? Сборка и так идёт в tmpfs. Проблема не в
> сборке как таковой, а в создани копий репозитория для каждой сборочницы.

А нельзя копии репозитария делать через mount --bind? Ну или через
монтирование снапшотов, например NILFS?

Re: [devel] I: git.alt update

[REAL]

Anton Farygin пишет:
> Тогда, IMHO, выключить паралелльную сборку и решать вопрос с ядром, 
> благо testcase известен.

Не могу не поддержать.

-- 

REAL aka Евгений Ростовцев, программист ЦНИТ КемГУ

Re: [devel] I: git.alt update

[Anton V. Boyarshinov]

On Fri, 29 Oct 2010 12:07:26 +0400 Damir Shayhutdinov wrote:

> А нельзя копии репозитария делать через mount --bind? 
Нет, так как копии потому и копии, что должны оставаться неизменными
тогда, когда меняется основной репозиторий, иначе сборка будет ломаться.

>Ну или через
> монтирование снапшотов, например NILFS?
Хмм.. Это интересная идея. По соображениям производительности это может
быть хорошим решением, но требует прав root, что, вообще говоря,
нежелательно..

Re: [devel] I: git.alt update

[Anton V. Boyarshinov]

> То же самое, вероятно, можно делать с репозитарием вместо копирования.
Проблема в том, что решается не задача "сделать копию репозитория, чтоб
её можно было менять", а в том, чтоб сделать копию репозитория для
того, чтоб можно было менять основной репозиторий, не затрагивая
копию. Таким образом непонятно: что считать "основным репозиторием"
поверх которого имело бы смысл поднимать оверлей. 

Re: [devel] I: git.alt update

[Anton Farygin]

29.10.2010 12:51, Anton V. Boyarshinov пишет:
> On Fri, 29 Oct 2010 12:07:26 +0400 Damir Shayhutdinov wrote:
>
>> А нельзя копии репозитария делать через mount --bind?
> Нет, так как копии потому и копии, что должны оставаться неизменными
> тогда, когда меняется основной репозиторий, иначе сборка будет ломаться.

А mount --bind должен быть сделан для копии основого репозитория (или 
вообще не потребуется). Т.к. после каждого изменения (сборки каждого 
пакета) основной репозиторий должен быть скопирован (через cp -al, 
конечно) в архив, который и будут использовать задания.


В этом случае cp -al будет выполняться один раз после каждой сборки, а 
не перед каждой сборкой, как сейчас.

>
>> Ну или через
>> монтирование снапшотов, например NILFS?
> Хмм.. Это интересная идея. По соображениям производительности это может
> быть хорошим решением, но требует прав root, что, вообще говоря,
> нежелательно..

Насколько оно стабильное ? В Todo очень большой список...

Re: [devel] I: git.alt update

[Anton V. Boyarshinov]

On Fri, 29 Oct 2010 13:00:23 +0400 Anton Farygin wrote:

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

Re: [devel] I: git.alt update

[Anton Farygin]

29.10.2010 13:03, Anton V. Boyarshinov пишет:
> On Fri, 29 Oct 2010 13:00:23 +0400 Anton Farygin wrote:
>
>> В этом случае cp -al будет выполняться один раз после каждой сборки, а
>> не перед каждой сборкой, как сейчас.
> То есть столько же раз с точностью до количества неудачных сборок. Не
> спасёт..

Тогда, IMHO, выключить паралелльную сборку и решать вопрос с ядром, 
благо testcase известен.

у меня в сборочнице повис php, который нужен (там CVE исправили и много 
всего по мелочи)...

Re: [devel] I: git.alt update

[Dmitry V. Levin]

[-- Attachment #1: Type: text/plain, Size: 798 bytes --]

On Fri, Oct 29, 2010 at 09:39:23AM +0400, Anton Farygin wrote:
> 29.10.2010 04:14, Dmitry V. Levin пишет:
> >On Thu, Oct 28, 2010 at 04:37:59PM +0400, Dmitry V. Levin wrote:
> >>Особенности работы внутри всё равно 
> >>сейчас продолжают меняться.
> >>О них можно будет рассказать, когда 
> >>наступит стабилизация.
> >
> >Перспективы стабилизации более чем 
> >туманны, ядро не выдерживает
> >нагрузку и идёт ко дну. :(
> 
> А какое ядро у тебя там используется ?

2618-ovz-rhel-13M5115

> Есть ли testcase, позволяющий воспроизвести 
> идущее ко дну ядро ?

Да, достаточно просто включить girar-builder, через некоторое время ядро
зависнет примерно как в http://bugzilla.openvz.org/show_bug.cgi?id=1520
если cfq, и предположительно делает panic, если deadline.


-- 
ldv

[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]

Re: [devel] I: git.alt update

[Dmitry V. Levin]

[-- Attachment #1: Type: text/plain, Size: 1476 bytes --]

On Fri, Oct 29, 2010 at 10:06:19AM +0400, Anton V. Boyarshinov wrote:
> 
> > > Перспективы стабилизации более чем туманны, ядро не выдерживает
> > > нагрузку и идёт ко дну. :(
> > 
> > А какое ядро у тебя там используется ?
> 2.6.18-ovz-rhel
>  
> > Есть ли testcase, позволяющий воспроизвести идущее ко дну ядро ?
> Универсального (такого, чтоб работал на любой машине, независимо от
> количества памяти, размеров fs и прочего), насколько я понимаю, нет.
> 
> Симптомы выглядят примерно так:
> Если удалять копию репозитория, а потом воссоздавать её при помощи cp
> -al, то для 5.0 повторы этого процесса выглядят правильно, то есть
> первый проход занимает 10-15 секунд, последующие 2-5 секунд (так как
> заполняются кэши).
> Тот же процесс, выплоняемый для Сизифа (процентов на 30 большего, чем
> 5.0) выполняется около 30 секунд при первом проходе и при последующих
> время выполнения быстро растёт (пятый проход уже может длиться пару
> минут). Если продолжать в том же духе, машина умирает под грузом IO.

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

> Вчера пробовали крутить настройки виртуальной памяти, насколько я
> понимаю, не помогло. Вчера Дима собирался сегодня добавить в эту машину
> RAM (сейчас там, если я правильно помню 6гиг).

И почти вся эта память, судя по /proc/meminfo, Cached.


-- 
ldv

[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]

Re: [devel] I: git.alt update

[Dmitry V. Levin]

[-- Attachment #1: Type: text/plain, Size: 473 bytes --]

On Fri, Oct 29, 2010 at 10:40:01AM +0400, Anton Farygin wrote:
> 29.10.2010 10:33, Anton V. Boyarshinov пишет:
> >
> >>А ядро поменять не пробовали ?
> >там ovz :( Насколько я понимаю, Дима не 
> >готов тестировать на этой
> >машине новые ovz ядра.. Хотя, возможно, уже 
> >готов..
> 
> Ядро первым делом надо поменять, от ovz 
> надо отказываться на серверах с такой 
> нагрузкой - зачем он там ?

Цена отказа от ovz -- купить ещё один сервер.


-- 
ldv

[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]

Re: [devel] I: git.alt update

[Dmitry V. Levin]

[-- Attachment #1: Type: text/plain, Size: 1811 bytes --]

On Fri, Oct 29, 2010 at 10:51:53AM +0400, Anton Farygin wrote:
> 29.10.2010 10:42, Anton V. Boyarshinov пишет:
> >On Fri, 29 Oct 2010 10:40:01 +0400 Anton Farygin wrote:
> >>29.10.2010 10:33, Anton V. Boyarshinov пишет:
> >>>
> >>>>А ядро поменять не пробовали ?
> >>>там ovz :( Насколько я понимаю, Дима не 
> >>>готов тестировать на этой
> >>>машине новые ovz ядра.. Хотя, возможно, 
> >>>уже готов..
> >>
> >>Ядро первым делом надо поменять, от ovz 
> >>надо отказываться на серверах с
> >>такой нагрузкой - зачем он там ?
> >Там контейнеры..
> 
> Контейнеры надо уносить с этого сервера. 
> всё равно при высоком IO они будут 
> тормозить так, что мало не покажется.

Давайте лучше я обрисую картину, иначе ваши догадки будут далеки от
реальности.

На этом сервере есть раздаваемый readonly NFS и, грубо говоря, два
контейнера (не считая служебных, которые не создают нагрузки).
Два контейнера -- это git.alt и gitweb.
Контейнер под условным именем gitweb раздает git.alt по всем протоколам
кроме ssh.
Контейнер под условным именем git.alt реализует ssh-интерфейс и
обрабатывает задания, выполняя сложные расчеты, сопряженные с интенсивным
чтением c readonly NFS, раздаваемой с этого же сервера.
Интенсивная запись на ФС происходит в файловой системе за пределами
git.alt, эта ФС раздается по readonly NFS на сборочные узлы, где работает
hasher, собирающий пакеты и тестирующий их установку.

После внедрения параллельной обработки заданий возросла нагрузка в двух
местах:
- на чтение-запись в выделенной ФС, раздаваемой по readonly NFS;
- в контейнере git.alt;
Ядро 2.6.18-ovz-rhel под этой нагрузкой виснет/падает за пару часов.

Можно унести эти самые 2 контейнера с readonly NFS сервера, но для решения
этого вопроса потребуется еще один сервер.


-- 
ldv

[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]

Re: [devel] I: git.alt update

[Денис Смирнов]

[-- Attachment #1: Type: text/plain, Size: 462 bytes --]

On Thu, Oct 28, 2010 at 11:23:00PM +0300, Igor Vlasenko wrote:

IV> Да, хорошая штука была бы.
IV> Если еще б ее в git.alt вкрутить.
IV> что-то вроде
IV> ssh git.alt task 55555 await 55551 55552 55553 55554

Так можно не вкручивать, а самому написать обвязку которая будет указанные
задачи стартовать в определенном порядке.

-- 
С уважением, Денис

http://mithraen.ru/
----------------------------------------------------------------------------

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [devel] I: git.alt update

[Vladimir Lettiev]

On Fri, Oct 29, 2010 at 01:50:41PM +0400, Dmitry V. Levin wrote:
> On Fri, Oct 29, 2010 at 10:06:19AM +0400, Anton V. Boyarshinov wrote:
> > минут). Если продолжать в том же духе, машина умирает под грузом IO.
> 
> Это ложный след.  Если подкрутить настройки ФС, то и копирование Сизифа
> стабилизируется на нескольких секундах.  Ядро просто умирает через пару
> часов без видимой причины.

Вряд ли это ложный след. По крайне мере в приведённых ссылках на баги в ovz
говорится о heavy file operations.
Думаю параллельно с решением бага в ядре должна вестись работа над
оптимизацией алгоритмов сборочницы, для снижения нагрузки на дисковую
подсистему.
Например, в случае cp -al можно заменить на алгоритм, который рекурсивно обходит
все каталоги репозитория, делает ls в них и сравнивает с таким же выводом в
локальной копии, и в соответствии с полученной информацией удаляет/копирует
файлы. Нагрузка на дисковую подсистему минимальна.

p.s. Реализацию на perl этого алгоритма  я уже делал, когда мне требовалось
обрабатывать изменения в Sisyphus после обновления, и при этом не убивать
жёсткий диск повторным окрытием каждого файла на чтение метаинформации.

-- 
Vladimir Lettiev aka crux ✉ theCrux@gmail.com

Re: [devel] I: git.alt update

[Anton Farygin]

29.10.2010 13:53, Dmitry V. Levin пишет:
> On Fri, Oct 29, 2010 at 10:40:01AM +0400, Anton Farygin wrote:
>> 29.10.2010 10:33, Anton V. Boyarshinov пишет:
>>>
>>>> А ядро поменять не пробовали ?
>>> там ovz :( Насколько я понимаю, Дима не
>>> готов тестировать на этой
>>> машине новые ovz ядра.. Хотя, возможно, уже
>>> готов..
>>
>> Ядро первым делом надо поменять, от ovz
>> надо отказываться на серверах с такой
>> нагрузкой - зачем он там ?
>
> Цена отказа от ovz -- купить ещё один сервер.

Хороший вариант.

Я поговорю со Смирновым на эту тему.

Сейчас сервера на Intel ушли очень далеко вперёд от того, что стоит у 
нас и у вас.

Re: [devel] I: git.alt update

[George V. Kouryachy]

On Fri, Oct 29, 2010 at 02:13:21PM +0400, Dmitry V. Levin wrote:
> Давайте лучше я обрисую картину, иначе ваши догадки будут далеки от
> реальности.
> 
> На этом сервере есть раздаваемый readonly NFS и, грубо говоря, два
> контейнера (не считая служебных, которые не создают нагрузки).
> Два контейнера -- это git.alt и gitweb.
> Контейнер под условным именем gitweb раздает git.alt по всем протоколам
> кроме ssh.
> Контейнер под условным именем git.alt реализует ssh-интерфейс и
> обрабатывает задания, выполняя сложные расчеты, сопряженные с интенсивным
> чтением c readonly NFS, раздаваемой с этого же сервера.
> Интенсивная запись на ФС происходит в файловой системе за пределами
> git.alt, эта ФС раздается по readonly NFS на сборочные узлы, где работает
> hasher, собирающий пакеты и тестирующий их установку.
> 
> После внедрения параллельной обработки заданий возросла нагрузка в двух
> местах:
> - на чтение-запись в выделенной ФС, раздаваемой по readonly NFS;
> - в контейнере git.alt;
> Ядро 2.6.18-ovz-rhel под этой нагрузкой виснет/падает за пару часов.
Правильно ли я понимаю, что:

 1. Никакого NFS из контейнеров не монтируется, это сделано bind-ом, а NFS
    отдаётся с хост-системы внешним сборочникам?
 2. Раньше такой операции, как регулярное создание копии Сизифа для
    отдачи сборочнику по NFS, просто не было, а сейчас это делается для
    каждого (пакета/задания/whatever)?
 3. Объём чтения-записи в git.alt существенно ниже объёма чтения-записи
    при создании копии Сизифа?

Если да, то дело может быть банально в галлюцинациях дискового
контроллера, не спраляющегося с возросшим в несколько раз RW.

Года четыре назад была у меня похожая история: по отдельности
параллельная сборочница и зеркало работали, а вместе давали наутро
дохлый труп. Помог переезд на точно такую же машину, но с другой дисковой
подсистемой (емнип, SATA вместо SCSI).

-- 
			George V. Kouryachy (aka Fr. Br. George)
			mailto:george at altlinux_org

Re: [devel] I: git.alt update

[Dmitry V. Levin]

[-- Attachment #1: Type: text/plain, Size: 2131 bytes --]

On Fri, Oct 29, 2010 at 03:07:13PM +0400, George V. Kouryachy wrote:
> On Fri, Oct 29, 2010 at 02:13:21PM +0400, Dmitry V. Levin wrote:
> > Давайте лучше я обрисую картину, иначе ваши догадки будут далеки от
> > реальности.
> > 
> > На этом сервере есть раздаваемый readonly NFS и, грубо говоря, два
> > контейнера (не считая служебных, которые не создают нагрузки).
> > Два контейнера -- это git.alt и gitweb.
> > Контейнер под условным именем gitweb раздает git.alt по всем протоколам
> > кроме ssh.
> > Контейнер под условным именем git.alt реализует ssh-интерфейс и
> > обрабатывает задания, выполняя сложные расчеты, сопряженные с интенсивным
> > чтением c readonly NFS, раздаваемой с этого же сервера.
> > Интенсивная запись на ФС происходит в файловой системе за пределами
> > git.alt, эта ФС раздается по readonly NFS на сборочные узлы, где работает
> > hasher, собирающий пакеты и тестирующий их установку.
> > 
> > После внедрения параллельной обработки заданий возросла нагрузка в двух
> > местах:
> > - на чтение-запись в выделенной ФС, раздаваемой по readonly NFS;
> > - в контейнере git.alt;
> > Ядро 2.6.18-ovz-rhel под этой нагрузкой виснет/падает за пару часов.
> Правильно ли я понимаю, что:
> 
>  1. Никакого NFS из контейнеров не монтируется, это сделано bind-ом, а NFS
>     отдаётся с хост-системы внешним сборочникам?

Да.

>  2. Раньше такой операции, как регулярное создание копии Сизифа для
>     отдачи сборочнику по NFS, просто не было, а сейчас это делается для
>     каждого (пакета/задания/whatever)?

Да, раньше по NFS раздавался текущий Сизиф, который не клонировался.

>  3. Объём чтения-записи в git.alt существенно ниже объёма чтения-записи
>     при создании копии Сизифа?

Число операций записи действительно существенно ниже, чем при создании
копии Сизифа, объём вряд ли ниже, ну а объём чтения в git.alt существенно
выше, чем при создании копии Сизифа.

> Если да, то дело может быть банально в галлюцинациях дискового
> контроллера, не спраляющегося с возросшим в несколько раз RW.

В логах ядра никаких жалоб на контроллер нет.
 

-- 
ldv

[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]

Re: [devel] I: git.alt update

[Dmitry V. Levin]

[-- Attachment #1: Type: text/plain, Size: 1321 bytes --]

On Fri, Oct 29, 2010 at 02:39:51PM +0400, Vladimir Lettiev wrote:
> On Fri, Oct 29, 2010 at 01:50:41PM +0400, Dmitry V. Levin wrote:
> > On Fri, Oct 29, 2010 at 10:06:19AM +0400, Anton V. Boyarshinov wrote:
> > > минут). Если продолжать в том же духе, машина умирает под грузом IO.
> > 
> > Это ложный след.  Если подкрутить настройки ФС, то и копирование Сизифа
> > стабилизируется на нескольких секундах.  Ядро просто умирает через пару
> > часов без видимой причины.
> 
> Вряд ли это ложный след. По крайне мере в приведённых ссылках на баги в ovz
> говорится о heavy file operations.
> Думаю параллельно с решением бага в ядре должна вестись работа над
> оптимизацией алгоритмов сборочницы, для снижения нагрузки на дисковую
> подсистему.
> Например, в случае cp -al можно заменить на алгоритм, который рекурсивно обходит
> все каталоги репозитория, делает ls в них и сравнивает с таким же выводом в
> локальной копии, и в соответствии с полученной информацией удаляет/копирует
> файлы. Нагрузка на дисковую подсистему минимальна.

Рекурсивный обход всех каталогов репозитория -- это неминуемый stat на
каждый файл, если только не знать заранее, какие из этих файлов являются
каталогами.  Например,
$ find Sisyphus/ | wc -l
162679
$ find Sisyphus/ -not -name \*.rpm | wc -l
83


-- 
ldv

[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]

Re: [devel] I: git.alt update

[Kirill A. Shutemov]

On Fri, Oct 29, 2010 at 03:58:49PM +0400, Dmitry V. Levin wrote:
> On Fri, Oct 29, 2010 at 02:39:51PM +0400, Vladimir Lettiev wrote:
> > On Fri, Oct 29, 2010 at 01:50:41PM +0400, Dmitry V. Levin wrote:
> > > On Fri, Oct 29, 2010 at 10:06:19AM +0400, Anton V. Boyarshinov wrote:
> > > > минут). Если продолжать в том же духе, машина умирает под грузом IO.
> > > 
> > > Это ложный след.  Если подкрутить настройки ФС, то и копирование Сизифа
> > > стабилизируется на нескольких секундах.  Ядро просто умирает через пару
> > > часов без видимой причины.
> > 
> > Вряд ли это ложный след. По крайне мере в приведённых ссылках на баги в ovz
> > говорится о heavy file operations.
> > Думаю параллельно с решением бага в ядре должна вестись работа над
> > оптимизацией алгоритмов сборочницы, для снижения нагрузки на дисковую
> > подсистему.
> > Например, в случае cp -al можно заменить на алгоритм, который рекурсивно обходит
> > все каталоги репозитория, делает ls в них и сравнивает с таким же выводом в
> > локальной копии, и в соответствии с полученной информацией удаляет/копирует
> > файлы. Нагрузка на дисковую подсистему минимальна.
> 
> Рекурсивный обход всех каталогов репозитория -- это неминуемый stat на
> каждый файл, если только не знать заранее, какие из этих файлов являются
> каталогами. 

В данном случае, список (довольно короткий) каталогов известен заранее. Верно?

-- 
 Kirill A. Shutemov

Re: [devel] I: git.alt update

[Sergey Y. Afonin]

On Friday 29 October 2010, George V. Kouryachy wrote:

>  3. Объём чтения-записи в git.alt существенно ниже объёма чтения-записи
>     при создании копии Сизифа?
> 
> Если да, то дело может быть банально в галлюцинациях дискового
> контроллера, не спраляющегося с возросшим в несколько раз RW.
> 
> Года четыре назад была у меня похожая история: по отдельности
> параллельная сборочница и зеркало работали, а вместе давали наутро
> дохлый труп. Помог переезд на точно такую же машину, но с другой дисковой
> подсистемой (емнип, SATA вместо SCSI).
 
У нас наблюдается похожая ситуация на ovz-сервере и я тоже грешу на
то, что не справляется контроллер. До смерти не доходит, но, например, 
архивировние контейнеров приводит к тому, что кое-что начинает чрезмерно
тормозить. При этом есть возможность кардинально заменить контроллер,
и этот опыт планируется на выходные. Отпишусь о результате, как опыты
проведём.

-- 
С уважением, Сергей Афонин
asy@altlinux.ru

Re: [devel] I: git.alt update

[Vladimir Lettiev]

29 октября 2010 г. 15:58 пользователь Dmitry V. Levin
<ldv@altlinux.org> написал:
> On Fri, Oct 29, 2010 at 02:39:51PM +0400, Vladimir Lettiev wrote:
>> On Fri, Oct 29, 2010 at 01:50:41PM +0400, Dmitry V. Levin wrote:
>> > On Fri, Oct 29, 2010 at 10:06:19AM +0400, Anton V. Boyarshinov wrote:
>> > > минут). Если продолжать в том же духе, машина умирает под грузом IO.
>> >
>> > Это ложный след.  Если подкрутить настройки ФС, то и копирование Сизифа
>> > стабилизируется на нескольких секундах.  Ядро просто умирает через пару
>> > часов без видимой причины.
>>
>> Вряд ли это ложный след. По крайне мере в приведённых ссылках на баги в ovz
>> говорится о heavy file operations.
>> Думаю параллельно с решением бага в ядре должна вестись работа над
>> оптимизацией алгоритмов сборочницы, для снижения нагрузки на дисковую
>> подсистему.
>> Например, в случае cp -al можно заменить на алгоритм, который рекурсивно обходит
>> все каталоги репозитория, делает ls в них и сравнивает с таким же выводом в
>> локальной копии, и в соответствии с полученной информацией удаляет/копирует
>> файлы. Нагрузка на дисковую подсистему минимальна.
>
> Рекурсивный обход всех каталогов репозитория -- это неминуемый stat на
> каждый файл, если только не знать заранее, какие из этих файлов являются
> каталогами.  Например,
> $ find Sisyphus/ | wc -l
> 162679
> $ find Sisyphus/ -not -name \*.rpm | wc -l
> 83

Подумалось, кстати, что задача ещё больше упрощается если учесть, что apt
работает с индексами, и значит для каждого репозитария надо копировать только
индексы, а все пакеты сваливать в одну кучу (файловые конфликты, теоретически,
невозможны, т.к. каждая сборка пакета имеет своё уникальное имя)

-- 
Vladimir Lettiev aka crux <theCrux@gmail.com>

Re: [devel] I: git.alt update

[George V. Kouryachy]

On Fri, Oct 29, 2010 at 03:31:17PM +0400, Dmitry V. Levin wrote:
> Да, раньше по NFS раздавался текущий Сизиф, который не клонировался.
> 
>>  3. Объём чтения-записи в git.alt существенно ниже объёма чтения-записи
>>     при создании копии Сизифа?
> 
> Число операций записи действительно существенно ниже, чем при создании
> копии Сизифа, объём вряд ли ниже, ну а объём чтения в git.alt существенно
> выше, чем при создании копии Сизифа.

>> Если да, то дело может быть банально в галлюцинациях дискового
>> контроллера, не спраляющегося с возросшим в несколько раз RW.
> 
> В логах ядра никаких жалоб на контроллер нет.
У меня тоже не было, оно умирало перед тем, как пожаловаться.

Предложение от Антона Бояршинова:
На самом деле не нужно создавать _копию_ Сизифа. Нужно, чтобы были
правильные индексы, и чтобы были как минимум все файлы, упомянутые в
индексах. То есть вместо cp -al можно делать cp -ul, что существенно
снижает нагрузку. А rm -rf && cp -al (или rsync --delete-after
--size-only) можно предпринимать только изредка, по праздникам.

-- 
			George V. Kouryachy (aka Fr. Br. George)
			mailto:george at altlinux_org

Re: [devel] I: git.alt update

[Dmitry V. Levin]

[-- Attachment #1: Type: text/plain, Size: 1024 bytes --]

On Fri, Oct 29, 2010 at 06:13:51PM +0400, Kharitonov A. Dmitry wrote:
>  29.10.2010 13:46, Dmitry V. Levin пишет:
> >On Fri, Oct 29, 2010 at 09:39:23AM +0400, Anton Farygin wrote:
> >>29.10.2010 04:14, Dmitry V. Levin пишет:
> >>>On Thu, Oct 28, 2010 at 04:37:59PM +0400, Dmitry V. Levin wrote:
> >>>>Особенности работы внутри всё равно
> >>>>сейчас продолжают меняться.
> >>>>О них можно будет рассказать, когда
> >>>>наступит стабилизация.
> >>>Перспективы стабилизации более чем
> >>>туманны, ядро не выдерживает
> >>>нагрузку и идёт ко дну. :(
> >>А какое ядро у тебя там используется ?
> >2618-ovz-rhel-13M5115
> >
> >>Есть ли testcase, позволяющий воспроизвести
> >>идущее ко дну ядро ?
> >Да, достаточно просто включить girar-builder, 
> >через некоторое время ядро
> >зависнет примерно как в 
> >http://bugzilla.openvz.org/show_bug.cgi?id=1520
> >если cfq, и предположительно делает panic, 
> >если deadline.
> Память тестировали?

Да, уже более чем полгода как тестируем. :)


-- 
ldv

[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]

Re: [devel] I: git.alt update

[Kharitonov A. Dmitry]

  29.10.2010 13:46, Dmitry V. Levin пишет:
> On Fri, Oct 29, 2010 at 09:39:23AM +0400, Anton Farygin wrote:
>> 29.10.2010 04:14, Dmitry V. Levin пишет:
>>> On Thu, Oct 28, 2010 at 04:37:59PM +0400, Dmitry V. Levin wrote:
>>>> Особенности работы внутри всё равно
>>>> сейчас продолжают меняться.
>>>> О них можно будет рассказать, когда
>>>> наступит стабилизация.
>>> Перспективы стабилизации более чем
>>> туманны, ядро не выдерживает
>>> нагрузку и идёт ко дну. :(
>> А какое ядро у тебя там используется ?
> 2618-ovz-rhel-13M5115
>
>> Есть ли testcase, позволяющий воспроизвести
>> идущее ко дну ядро ?
> Да, достаточно просто включить girar-builder, через некоторое время ядро
> зависнет примерно как в http://bugzilla.openvz.org/show_bug.cgi?id=1520
> если cfq, и предположительно делает panic, если deadline.
Память тестировали?

Re: [devel] I: git.alt update

[Anton V. Boyarshinov]

> Предложение от Антона Бояршинова:
> На самом деле не нужно создавать _копию_ Сизифа. Нужно, чтобы были
> правильные индексы, и чтобы были как минимум все файлы, упомянутые в
> индексах. То есть вместо cp -al можно делать cp -ul, что существенно
> снижает нагрузку. А rm -rf && cp -al (или rsync --delete-after
> --size-only) можно предпринимать только изредка, по праздникам.
Добравшись до компьютера дополню: я глубоко уважаю Диму как Security
Guru, но менять link counter у 40000 инод только для того, чтоб
немедленно поменять его обратно у 39 с лишним тысяч инод это
преступление перед лицом ядра операционной системы и она имеет полное
право мстить. Что она и делает. 

Мне, как прикладнику, очевидно, что если система дохнет от
нашено кода, надо оптимизировать узкие места. Изменение rm && cp -al на
cp -ul и rsync --delete-after --size-only раз в n заданий снизит
нагрузку на кэш и io как минимум на порядок. И ничего помирать не будет.

Антон
PS вообще говоря, теперь я считаю, что решение принятое в армовой
паралелльной сборочнице (ничего не клонировать) было правильным. Чем
раньше мы узнаём о том, что из под нас выбили важную для сборки часть
Сизифа, тем лучше (быстрее можно начать следующую итерацию, которая
всё равно понадобится). Только надо бы добавить различение между "нет
файла -- выбили сизиф" и "nos such file.. в процессе собственно сборки"

Re: [devel] I: git.alt update

[Anton V. Boyarshinov]

On Fri, 29 Oct 2010 16:47:20 +0400 Vladimir Lettiev wrote:

> Подумалось, кстати, что задача ещё больше упрощается если учесть, что apt
> работает с индексами, и значит для каждого репозитария надо копировать только
> индексы, а все пакеты сваливать в одну кучу (файловые конфликты, теоретически,
> невозможны, т.к. каждая сборка пакета имеет своё уникальное имя)
+ много

Re: [devel] I: git.alt update

[Kharitonov A. Dmitry]

  29.10.2010 18:12, Dmitry V. Levin пишет:
> On Fri, Oct 29, 2010 at 06:13:51PM +0400, Kharitonov A. Dmitry wrote:
>>   29.10.2010 13:46, Dmitry V. Levin пишет:
>>> On Fri, Oct 29, 2010 at 09:39:23AM +0400, Anton Farygin wrote:
>>>> 29.10.2010 04:14, Dmitry V. Levin пишет:
>>>>> On Thu, Oct 28, 2010 at 04:37:59PM +0400, Dmitry V. Levin wrote:
>>>>>> Особенности работы внутри всё равно
>>>>>> сейчас продолжают меняться.
>>>>>> О них можно будет рассказать, когда
>>>>>> наступит стабилизация.
>>>>> Перспективы стабилизации более чем
>>>>> туманны, ядро не выдерживает
>>>>> нагрузку и идёт ко дну. :(
>>>> А какое ядро у тебя там используется ?
>>> 2618-ovz-rhel-13M5115
>>>
>>>> Есть ли testcase, позволяющий воспроизвести
>>>> идущее ко дну ядро ?
>>> Да, достаточно просто включить girar-builder,
>>> через некоторое время ядро
>>> зависнет примерно как в
>>> http://bugzilla.openvz.org/show_bug.cgi?id=1520
>>> если cfq, и предположительно делает panic,
>>> если deadline.
>> Память тестировали?
> Да, уже более чем полгода как тестируем. :)
В рабочем режиме могут некоторые области никогда не использоваться. 
Стоит прогнать тест -- вдруг оно? и не придётся искать ошибки в 
правильно написанных программах.

Re: [devel] I: git.alt update

[Michael Shigorin]

On Fri, Oct 29, 2010 at 01:46:35PM +0400, Dmitry V. Levin wrote:
> > А какое ядро у тебя там используется ?
> 2618-ovz-rhel-13M5115

Засунь для пробы 2.6.32-ovz-smp?
У меня сборочницу пока выдерживает.

-- 
 ---- WBR, Michael Shigorin <mike@altlinux.ru>
  ------ Linux.Kiev http://www.linux.kiev.ua/

Re: [devel] I: git.alt update

[Michael Shigorin]

On Fri, Oct 29, 2010 at 10:51:53AM +0400, Anton Farygin wrote:
> >>Ядро первым делом надо поменять, от ovz надо отказываться на
> >>серверах с такой нагрузкой - зачем он там ?
> >Там контейнеры..

1) ну lxc на крайняк;

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

2) если грамотно разносить I/O по шпинделям, то три сборочницы
   с одним терминальным сервером на не шибко какой железке жили.

-- 
 ---- WBR, Michael Shigorin <mike@altlinux.ru>
  ------ Linux.Kiev http://www.linux.kiev.ua/

Re: [devel] I: git.alt update

[Денис Смирнов]

[-- Attachment #1: Type: text/plain, Size: 475 bytes --]

On Fri, Oct 29, 2010 at 05:38:18PM +0300, Michael Shigorin wrote:

MS> 2) если грамотно разносить I/O по шпинделям, то три сборочницы
MS>    с одним терминальным сервером на не шибко какой железке жили.

Небось еще xfs :) А еще напомню про журнал на отдельном шпинделе (или
лучше на SSD)...

Кстати дома я от xfs отказался в пользу ext4.

-- 
С уважением, Денис

http://mithraen.ru/
----------------------------------------------------------------------------

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [devel] I: git.alt update

[Dmitry V. Levin]

[-- Attachment #1: Type: text/plain, Size: 1714 bytes --]

On Fri, Oct 29, 2010 at 03:06:27PM +0300, Kirill A. Shutemov wrote:
> On Fri, Oct 29, 2010 at 03:58:49PM +0400, Dmitry V. Levin wrote:
> > On Fri, Oct 29, 2010 at 02:39:51PM +0400, Vladimir Lettiev wrote:
> > > On Fri, Oct 29, 2010 at 01:50:41PM +0400, Dmitry V. Levin wrote:
> > > > On Fri, Oct 29, 2010 at 10:06:19AM +0400, Anton V. Boyarshinov wrote:
> > > > > минут). Если продолжать в том же духе, машина умирает под грузом IO.
> > > > 
> > > > Это ложный след.  Если подкрутить настройки ФС, то и копирование Сизифа
> > > > стабилизируется на нескольких секундах.  Ядро просто умирает через пару
> > > > часов без видимой причины.
> > > 
> > > Вряд ли это ложный след. По крайне мере в приведённых ссылках на баги в ovz
> > > говорится о heavy file operations.
> > > Думаю параллельно с решением бага в ядре должна вестись работа над
> > > оптимизацией алгоритмов сборочницы, для снижения нагрузки на дисковую
> > > подсистему.
> > > Например, в случае cp -al можно заменить на алгоритм, который рекурсивно обходит
> > > все каталоги репозитория, делает ls в них и сравнивает с таким же выводом в
> > > локальной копии, и в соответствии с полученной информацией удаляет/копирует
> > > файлы. Нагрузка на дисковую подсистему минимальна.
> > 
> > Рекурсивный обход всех каталогов репозитория -- это неминуемый stat на
> > каждый файл, если только не знать заранее, какие из этих файлов являются
> > каталогами. 
> 
> В данном случае, список (довольно короткий) каталогов известен заранее. Верно?

Да, конечно, структура каталогов фиксирована, поэтому задача о клонировании
решается без необходимости делать stat на все файлы.  На тестах вроде бы
работает правильно.


-- 
ldv

[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]

Re: [devel] I: git.alt update

[Dmitry V. Levin]

[-- Attachment #1: Type: text/plain, Size: 948 bytes --]

On Fri, Oct 29, 2010 at 06:19:02PM +0400, Anton V. Boyarshinov wrote:
[...]
> PS вообще говоря, теперь я считаю, что решение принятое в армовой
> паралелльной сборочнице (ничего не клонировать) было правильным. Чем
> раньше мы узнаём о том, что из под нас выбили важную для сборки часть
> Сизифа, тем лучше (быстрее можно начать следующую итерацию, которая
> всё равно понадобится). Только надо бы добавить различение между "нет
> файла -- выбили сизиф" и "nos such file.. в процессе собственно сборки"

Достоверно отличить ситуацию "Сизиф изменился" от ситуации "произошла
какая-то ошибка" непросто.  Помимо самой сборки и тестовой установки
пакетов, где ничего другого, кроме как грепать логи на тему ключевых
фраз-признаков изменившегося репозитория, не остается, есть ещё некоторое
количество скриптов gb-task-*, которые были написаны в расчете на
стабильный репозиторий.  Получается заведомо нестабильная система.


-- 
ldv

[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]

Re: [devel] I: git.alt update

[Anton Farygin]

29.10.2010 18:38, Michael Shigorin пишет:
> On Fri, Oct 29, 2010 at 10:51:53AM +0400, Anton Farygin wrote:
>>>> Ядро первым делом надо поменять, от ovz надо отказываться на
>>>> серверах с такой нагрузкой - зачем он там ?
>>> Там контейнеры..
>
> 1) ну lxc на крайняк;
>
>> Контейнеры надо уносить с этого сервера. всё равно при высоком
>> IO они будут тормозить так, что мало не покажется.
>
> 2) если грамотно разносить I/O по шпинделям, то три сборочницы
>     с одним терминальным сервером на не шибко какой железке жили.

Подозреваю, что там это не прокатит. Я не зря сказал про хорошее 
дисковое хранилище на фибре.

Re: [devel] I: git.alt update

[Dmitry V. Levin]

[-- Attachment #1: Type: text/plain, Size: 1561 bytes --]

On Thu, Oct 28, 2010 at 04:37:59PM +0400, Dmitry V. Levin wrote:
> On Thu, Oct 28, 2010 at 07:46:20PM +0800, Terechkov Evgenii wrote:
> > On Thu, 28 Oct 2010 14:38:17 +0400, Anton V. Boyarshinov wrote:
> > 
> > > С одной стороны, сегодня знаменательный день: в Сизифе заработала
> > > паралелльная сборка.
> > 
> > В одной стороны, это замечательно! Даже, пожалуй, УРА!
> > 
> > > С другой стороны, без малого 30 отдельных заданий по одному
> > > пакету отправленных пользователем real резко снижают положительный
> > > эффект. Они блокируют сборочницу для всех прочих не менее эффективно,
> > > чем раньше блокировало одно большое задание :(
> > 
> > С другой стороны хотелось бы документации (хоть какой-то, кроме кода),
> > описывающей, как оно работает. Чтобы ненароком не парализовать всё :-)
> 
> Основное отличие: задания выполняются в порядке, который со стороны
> выглядит как произвольный.  Другими словами, отправив на сборку 2 задания
> одно за другим, вы не можете рассчитывать на то, что они будут собраны в
> том или ином порядке.  Если вам нужна упорядоченная сборка, то объединяйте
> несколько заданий в одно.

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


-- 
ldv

[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]

Re: [devel] I: git.alt update

[Sergey Y. Afonin]

On Friday 29 October 2010, Sergey Y. Afonin wrote:

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

В общем, эффект есть от переноса /var/lib/vz с Intel SRCS16 на Infortrend
EonStor A12U-G2421. Тормоза при архивировании заметны всё равно, но пропали
отвалы приложений по таймауту. EonStor подключен через LSI Logic 53c1030,
U160 (U320 не завелось, видимо, из-за кабеля).

-- 
С уважением, Сергей Афонин
asy@altlinux.ru

Re: [devel] I: git.alt update

[Dmitry V. Levin]

[-- Attachment #1: Type: text/plain, Size: 698 bytes --]

On Wed, Oct 27, 2010 at 10:57:48AM +0400, Dmitry V. Levin wrote:
> Сегодня и, возможно, последующие дни будет происходить ползучее обновление
> git.alt, поэтому просьба возможные отказы в обслуживании воспринимать
> соответствующим образом.

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

Если кто-то знает, как заставить ядро ещё более агрессивно кэшировать
dentry и inode, чем оно делает по умолчанию, расскажите --
это позволит увеличить производительность обработки заданий.


-- 
ldv

[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]

Re: [devel] I: git.alt update

[Vladimir V. Kamarzin]

>>>>> On 03 Nov 2010 at 11:14 "DVL" == Dmitry V Levin writes:

DVL> Если кто-то знает, как заставить ядро ещё более агрессивно кэшировать
DVL> dentry и inode, чем оно делает по умолчанию, расскажите --
DVL> это позволит увеличить производительность обработки заданий.

Наверное можно снизить vm.vfs_cache_pressure

-- 
vvk

Re: [devel] I: git.alt update

[Dmitry V. Levin]

[-- Attachment #1: Type: text/plain, Size: 481 bytes --]

On Wed, Nov 03, 2010 at 11:48:20AM +0500, Vladimir V. Kamarzin wrote:
> >>>>> On 03 Nov 2010 at 11:14 "DVL" == Dmitry V Levin writes:
> 
> DVL> Если кто-то знает, как заставить ядро ещё более агрессивно кэшировать
> DVL> dentry и inode, чем оно делает по умолчанию, расскажите --
> DVL> это позволит увеличить производительность обработки заданий.
> 
> Наверное можно снизить vm.vfs_cache_pressure

Можно, конечно, но на этом сервере нет pressure на cache.


-- 
ldv

[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]

Re: [devel] I: git.alt update

[Kirill A. Shutemov]

On Wed, Nov 03, 2010 at 09:14:56AM +0300, Dmitry V. Levin wrote:
> Если кто-то знает, как заставить ядро ещё более агрессивно кэшировать
> dentry и inode, чем оно делает по умолчанию, расскажите --
> это позволит увеличить производительность обработки заданий.

С dhash_entries не игрался?

-- 
 Kirill A. Shutemov

Re: [devel] I: git.alt update

[Dmitry V. Levin]

[-- Attachment #1: Type: text/plain, Size: 906 bytes --]

On Wed, Nov 03, 2010 at 09:03:44AM +0200, Kirill A. Shutemov wrote:
> On Wed, Nov 03, 2010 at 09:14:56AM +0300, Dmitry V. Levin wrote:
> > Если кто-то знает, как заставить ядро ещё более агрессивно кэшировать
> > dentry и inode, чем оно делает по умолчанию, расскажите --
> > это позволит увеличить производительность обработки заданий.
> 
> С dhash_entries не игрался?

Нет ещё.  Дефолтные значения на этом сервере такие:
Dentry cache hash table entries: 4194304 (order: 13, 33554432 bytes)
Inode-cache hash table entries: 2097152 (order: 12, 16777216 bytes)

В коде написано, что allocation size ограничено 1/16 total memory.
Другими словами, можно указать ядру при загрузке в качестве dhash_entries и
ihash_entries очень большие числа, и тогда оно всё равно съест не более
1/8 всей памяти?  Интересно, скорость работы этих кэшей заметно снизится
из-за увеличения размера?


-- 
ldv

[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]

Re: [devel] I: git.alt update

[Alexey Tourbin]

On Wed, Nov 03, 2010 at 09:14:56AM +0300, Dmitry V. Levin wrote:
> On Wed, Oct 27, 2010 at 10:57:48AM +0400, Dmitry V. Levin wrote:
> > Сегодня и, возможно, последующие дни будет происходить ползучее обновление
> > git.alt, поэтому просьба возможные отказы в обслуживании воспринимать
> > соответствующим образом.
> 
> Основное обновление завершено.  Обработка заданий сейчас идет в три
> сборочных потока (плюс один завершающий).  Наверное, эксперименты с
> алгоритмом распараллеливания обработки будут продолжаться, но сбоев
> и простоев больше быть не должно.

А какой принцип работы параллельной сборки?
Гарантируется ли строгая (логическая) сериализация заданий?

Например, параллельно собирались два задания - glibc и rpm,
и закончили собираться одновременно.  Как определить, сколько
и какие именно задания будут завершены?

> Если кто-то знает, как заставить ядро ещё более агрессивно кэшировать
> dentry и inode, чем оно делает по умолчанию, расскажите --
> это позволит увеличить производительность обработки заданий.

Re: [devel] I: git.alt update

[Dmitry V. Levin]

[-- Attachment #1: Type: text/plain, Size: 2084 bytes --]

On Mon, Nov 22, 2010 at 10:12:09AM +0300, Alexey Tourbin wrote:
> On Wed, Nov 03, 2010 at 09:14:56AM +0300, Dmitry V. Levin wrote:
> > On Wed, Oct 27, 2010 at 10:57:48AM +0400, Dmitry V. Levin wrote:
> > > Сегодня и, возможно, последующие дни будет происходить ползучее обновление
> > > git.alt, поэтому просьба возможные отказы в обслуживании воспринимать
> > > соответствующим образом.
> > 
> > Основное обновление завершено.  Обработка заданий сейчас идет в три
> > сборочных потока (плюс один завершающий).  Наверное, эксперименты с
> > алгоритмом распараллеливания обработки будут продолжаться, но сбоев
> > и простоев больше быть не должно.
> 
> А какой принцип работы параллельной сборки?

girar-task-run поставляет задания в состоянии AWAITING;

N=3 экземпляра gb-toplevel-build выбирают задания в состоянии AWAITING,
приоритет имеет задание с меньшим номером;

выбранное задание переводится в состояние BUILDING, и для него клонируется
репозиторий;

для каждого аккаунта, зарегистрированного в системе, может быть не более
одного задания в состоянии BUILDING;

собранные test-only задания переводятся в состояние TESTED,
остальные собранные задания переводятся в состояние PENDING;

gb-toplevel-commit выбирает задания в состоянии PENDING c номером итерации
не менее чем максимальный номер итерации всех заданий в состоянии
BUILDING и PENDING для данного репозитория в данный момент времени,
приоритет имеет задание с меньшим номером;

если репозиторий, для которого задание было собрано, отличается от
репозитория, на котором оно было собрано, то задание переводится в в
состояние AWAITING с увеличенным номером итерации;

задание переводится в состояние COMMITTING, репозиторий обновляется,
и выполнение задания завершается.

> Гарантируется ли строгая (логическая) сериализация заданий?

А что это значит?

> Например, параллельно собирались два задания - glibc и rpm,
> и закончили собираться одновременно.  Как определить, сколько
> и какие именно задания будут завершены?

По алгоритму, приведенному выше.


-- 
ldv

[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]

Re: [devel] I: git.alt update

[Kharitonov A. Dmitry]

  22.11.2010 19:43, Dmitry V. Levin пишет:
> если репозиторий, для которого задание было собрано, отличается от 
> репозитория, на котором оно было собрано, то задание переводится в в 
> состояние AWAITING с увеличенным номером итерации; 
Наверное правильнее сравнивать не репозиторий целиком, а сравнивать 
только пакеты, учавствующие в сборке.

Re: [devel] I: git.alt update

[Igor Vlasenko]

On Mon, Nov 22, 2010 at 07:43:34PM +0300, Dmitry V. Levin wrote:
> если репозиторий, для которого задание было собрано, отличается от
> репозитория, на котором оно было собрано, то задание переводится в в
> состояние AWAITING с увеличенным номером итерации;

Да...

[...]
#33267 AWAITING #1.2 sisyphus srpm=perl-Algorithm-CheckDigits-0.50-alt2.1.src.rpm
#33266 BUILDING #1.3 [locked] sisyphus srpm=perl-Algorithm-C3-0.08-alt1.1.src.rpm

Выходит, заливка пакетов по алфавиту оказалась
worst case для сборочницы, которая зря делала по 3 пересборки
каждого пакета.

Утешает, что по алфавиту залил только perl-[A-C]*.

Господа, берите на заметку!
тасуйте алфавитные списки shaf'ом перед заливкой.

Пример для girar-nmu utils.
girar-nmu-task-for-each `grep 'perl-[dD].*' nmunames.perl | shuf`

-- 

Dr. Igor Vlasenko
--------------------
Topology Department
Institute of Math
Kiev, Ukraine

Re: [devel] I: git.alt update

[Igor Vlasenko]

On Mon, Nov 22, 2010 at 07:43:34PM +0300, Dmitry V. Levin wrote:
> если репозиторий, для которого задание было собрано, отличается от
> репозитория, на котором оно было собрано, то задание переводится в в
> состояние AWAITING с увеличенным номером итерации;

смотрю на
#33272 AWAITING #1.2 sisyphus srpm=perl-Apache-AuthCookie-3.12-alt1.1.src.rpm
#33271 AWAITING #1.2 sisyphus srpm=perl-Any-Moose-0.13-alt2.1.src.rpm
#33270 BUILDING #1.2 [locked] sisyphus srpm=perl-AnyEvent-5.22-alt1.1.src.rpm
ощущение, что сборка идет в 3 потока, но каждый поток в 2 итерации,
в результате сборка в 2 раза медленнее однопоточной.

> если репозиторий, для которого задание было собрано, отличается от
> репозитория, на котором оно было собрано

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

-- 

Dr. Igor Vlasenko
--------------------
Topology Department
Institute of Math
Kiev, Ukraine

Re: [devel] I: git.alt update

[Dmitry V. Levin]

[-- Attachment #1: Type: text/plain, Size: 622 bytes --]

On Mon, Nov 22, 2010 at 10:01:38PM +0300, Kharitonov A. Dmitry wrote:
>  22.11.2010 19:43, Dmitry V. Levin пишет:
> >если репозиторий, для которого задание 
> >было собрано, отличается от репозитория, 
> >на котором оно было собрано, то задание 
> >переводится в в состояние AWAITING с 
> >увеличенным номером итерации; 
> Наверное правильнее сравнивать не 
> репозиторий целиком, а сравнивать только 
> пакеты, учавствующие в сборке.

Нет, к сожалению, такая оптимизация была бы неправильной, поскольку любое
изменение в репозитории теоретически может повлиять на результат обработки
задания.


-- 
ldv

[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]

Re: [devel] I: git.alt update

[Dmitry V. Levin]

[-- Attachment #1: Type: text/plain, Size: 740 bytes --]

On Mon, Nov 22, 2010 at 09:01:47PM +0200, Igor Vlasenko wrote:
> On Mon, Nov 22, 2010 at 07:43:34PM +0300, Dmitry V. Levin wrote:
> > если репозиторий, для которого задание было собрано, отличается от
> > репозитория, на котором оно было собрано, то задание переводится в в
> > состояние AWAITING с увеличенным номером итерации;
> 
> Да...
> 
> [...]
> #33267 AWAITING #1.2 sisyphus srpm=perl-Algorithm-CheckDigits-0.50-alt2.1.src.rpm
> #33266 BUILDING #1.3 [locked] sisyphus srpm=perl-Algorithm-C3-0.08-alt1.1.src.rpm
> 
> Выходит, заливка пакетов по алфавиту оказалась
> worst case для сборочницы, которая зря делала по 3 пересборки
> каждого пакета.

Какая разница, по алфавиту были залиты пакеты или нет?


-- 
ldv

[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]

Re: [devel] I: git.alt update

[Igor Vlasenko]

On Mon, Nov 22, 2010 at 11:59:50PM +0300, Dmitry V. Levin wrote:
> Какая разница, по алфавиту были залиты пакеты или нет?

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

сорри. пытаюсь понять.

Субъективно долго что-то собираются пакеты.
С другой стороны, хороший стресс-тест для сборочницы.

-- 

Dr. Igor Vlasenko
--------------------
Topology Department
Institute of Math
Kiev, Ukraine

Re: [devel] I: git.alt update

[Dmitry V. Levin]

[-- Attachment #1: Type: text/plain, Size: 1936 bytes --]

On Mon, Nov 22, 2010 at 09:40:41PM +0200, Igor Vlasenko wrote:
> On Mon, Nov 22, 2010 at 07:43:34PM +0300, Dmitry V. Levin wrote:
> > если репозиторий, для которого задание было собрано, отличается от
> > репозитория, на котором оно было собрано, то задание переводится в в
> > состояние AWAITING с увеличенным номером итерации;
> 
> смотрю на
> #33272 AWAITING #1.2 sisyphus srpm=perl-Apache-AuthCookie-3.12-alt1.1.src.rpm
> #33271 AWAITING #1.2 sisyphus srpm=perl-Any-Moose-0.13-alt2.1.src.rpm
> #33270 BUILDING #1.2 [locked] sisyphus srpm=perl-AnyEvent-5.22-alt1.1.src.rpm
> ощущение, что сборка идет в 3 потока, но каждый поток в 2 итерации,
> в результате сборка в 2 раза медленнее однопоточной.

Нет, это утверждение не верно, поскольку
- последующие итерации выполняются быстрее
- итерации для разных заданий выполняются параллельно

Не забывайте, что сборочница обрабатывает задания от разных пользователей.

Мне кажется, что вы не вполне понимаете, для чего была реализована
параллелизация.  Раньше в обработке заданий было узкое место: одно
длительное задание блокировало всю очередь.  Теперь, для того, чтобы
заблокировать очередь, требуется три длительных задания от трех различных
пользователей.  Производительность сборочницы в среднем тоже немного
выросла, в основном за счет параллельной обработки длительных и
неудачных заданий.

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

> > если репозиторий, для которого задание было собрано, отличается от
> > репозитория, на котором оно было собрано
> 
> Оптимизацией была бы либо честная однопоточность, т.е. вообще
> не пытаться собирать под логин параллельно,
> либо критерий выбора -- из списка доступных 
> сначала попытаться выбрать то, чего нет в репозитории текущего BUILDING.

Ничего не понял.


-- 
ldv

[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]

Re: [devel] I: git.alt update

[Igor Vlasenko]

On Tue, Nov 23, 2010 at 12:15:01AM +0300, Dmitry V. Levin wrote:
> Ничего не понял.

Сорри, сорри. Торможу с непросыпу, не обращайте внимания.
Мне уже спать давно пора, но скрипт никак не заканчивается и 
не заканчивается.

...
 $ ssh git.alt task ls | wc -l
    302    1513   22096
 $ ssh git.alt task ls | wc -l
    312    1563   22877
 $ ssh git.alt task ls | wc -l
    323    1619   23662
 $ ssh git.alt task ls | wc -l
    340    1705   24854
 $ ssh git.alt task ls | wc -l
    343    1721   25111
...

-- 

Dr. Igor Vlasenko
--------------------
Topology Department
Institute of Math
Kiev, Ukraine

Re: [devel] I: git.alt update

[Dmitry V. Levin]

[-- Attachment #1: Type: text/plain, Size: 460 bytes --]

On Mon, Nov 22, 2010 at 11:24:36PM +0200, Igor Vlasenko wrote:
> On Tue, Nov 23, 2010 at 12:15:01AM +0300, Dmitry V. Levin wrote:
> > Ничего не понял.
> 
> Сорри, сорри. Торможу с непросыпу, не обращайте внимания.
> Мне уже спать давно пора, но скрипт никак не заканчивается и 
> не заканчивается.
> 
> ...
>  $ ssh git.alt task ls | wc -l
>     302    1513   22096

Как это у вас "wc -l" выводит 3 числа?  Чем это вы его накормили?


-- 
ldv

[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]

Re: [devel] I: git.alt update

[Alexey Tourbin]

On Mon, Nov 22, 2010 at 07:43:34PM +0300, Dmitry V. Levin wrote:
> > А какой принцип работы параллельной сборки?
> 
> girar-task-run поставляет задания в состоянии AWAITING;
> 
> N=3 экземпляра gb-toplevel-build выбирают задания в состоянии AWAITING,
> приоритет имеет задание с меньшим номером;
> 
> выбранное задание переводится в состояние BUILDING, и для него клонируется
> репозиторий;
> 
> для каждого аккаунта, зарегистрированного в системе, может быть не более
> одного задания в состоянии BUILDING;
> 
> собранные test-only задания переводятся в состояние TESTED,
> остальные собранные задания переводятся в состояние PENDING;
> 
> gb-toplevel-commit выбирает задания в состоянии PENDING c номером итерации
> не менее чем максимальный номер итерации всех заданий в состоянии
> BUILDING и PENDING для данного репозитория в данный момент времени,
> приоритет имеет задание с меньшим номером;
> 
> если репозиторий, для которого задание было собрано, отличается от
> репозитория, на котором оно было собрано, то задание переводится в в
> состояние AWAITING с увеличенным номером итерации;

То есть задание вступает в силу (коммитится), только если текущий
репозиторий равен клонированному репозиторию в задании?  Это хорошо.

С другой стороны, смотри.  Узнать, что репозиторий изменился (и что
придётся проигрывать всё задание заново) можно гораздо раньше, чем
в самом конце при попытке коммита задания.

Это также наводит на мысль, что клонировать репозиторий нет необходимости.
Достаточно иметь операцию

lock_repo_for_reading,check_the_repo_is_unchanged,otherwise_fail_and_schedule_task_for_reiteration

Далее нарезать girar-builder, чтобы некоторые куски выполнялись под этим
локом, а некоторые - без него. Наример, gb-remote-build нужно разрезать на
две части: первая часть выполнятеся под локом, она готовит чрут для сборки
(в том числе выгребает пакеты из репозитория).  Вторая часть просто
собирает пакет - упрощенно говоря 'hsh-run rpmbuild ...', лок на
репозиторий для этого не нужен.

> задание переводится в состояние COMMITTING, репозиторий обновляется,
> и выполнение задания завершается.
> > Гарантируется ли строгая (логическая) сериализация заданий?
> А что это значит?

Это понятие из теории СУБД.  Транзакции могут выполняться параллельно,
но с точки зрения самой транзакции она выполняется как бы эксклюзивно,
а результат параллельного выполнения должен быть такой, как если бы
транзакции выполнялись в каком-либо порядке.  Иначе возникают неприятные
побочные эффекты (самый известный и простой - продать два билета на одно
место).

В girar-builder сериализация важна, потому что это единственный надёжный
способ контролировать целостность репозитория.  А именно, girar-builder
работает по следующему принципу: репозиторий переводится из текущего
состояния в (предполагаемое) новое состояние: A->A'.  Вычисляется некая
сложная характирестическая функция: H(A), H(A').  Далее принимается
решение, проходит контроль целостности или нет.

То есть, в конечном счете, все задания должны выстраиваться в линейную
очередь (хотя бы при коммите), то есть H(A) должно вычисляться для
текущего репозитория.  А параллельно коммитить никак нельзя, потому что
тогда просто нет надёжной модели/надёжного способа контроля целостности.

> > Например, параллельно собирались два задания - glibc и rpm,
> > и закончили собираться одновременно.  Как определить, сколько
> > и какие именно задания будут завершены?
> 
> По алгоритму, приведенному выше.

Т.е. одно коммитится, все остальные идут на реитерацию.

Re: [devel] I: git.alt update

[Dmitry V. Levin]

[-- Attachment #1: Type: text/plain, Size: 2734 bytes --]

On Tue, Nov 23, 2010 at 02:11:02AM +0300, Alexey Tourbin wrote:
[...]
> С другой стороны, смотри.  Узнать, что репозиторий изменился (и что
> придётся проигрывать всё задание заново) можно гораздо раньше, чем
> в самом конце при попытке коммита задания.

Вопрос в том, всегда ли интересно узнать это гораздо раньше?
Я полагаю, что сборку задания имеет смысл довести до конца,
не интересуясь изменением репозитория, в двух случаях:
- задание test-only (его всё равно не придется коммитить);
- номер итерации задания равен 1 (не факт, что оно вообще соберется);

> Это также наводит на мысль, что клонировать репозиторий нет необходимости.
> Достаточно иметь операцию
> 
> lock_repo_for_reading,check_the_repo_is_unchanged,otherwise_fail_and_schedule_task_for_reiteration
> 
> Далее нарезать girar-builder, чтобы некоторые куски выполнялись под этим
> локом, а некоторые - без него. Наример, gb-remote-build нужно разрезать на
> две части: первая часть выполнятеся под локом, она готовит чрут для сборки
> (в том числе выгребает пакеты из репозитория).  Вторая часть просто
> собирает пакет - упрощенно говоря 'hsh-run rpmbuild ...', лок на
> репозиторий для этого не нужен.

Пожалуй, можно так сделать, и обработка задания тогда будет прерываться
быстрее, чем сейчас.  Но что это даст на практике?  Сейчас, судя по
таймингам в логах сборки, задание с номером итерации > 1 проводит очень
много времени в gb-task-gen-testrepo, и с этим пока ничего не получается
сделать.  apt -- наш главный тормоз как при вычислении зависимостей
(high startup costs), так и при вычислении индексов.

$ egrep '^(Mem|Buffers|Cached|Active|Inactive|Slab)' /proc/meminfo
MemTotal:     24627408 kB
MemFree:       1032952 kB
Buffers:        737652 kB
Cached:       20408488 kB
Active:        5720820 kB
Inactive:     15464156 kB
Slab:          2271392 kB

> > задание переводится в состояние COMMITTING, репозиторий обновляется,
> > и выполнение задания завершается.
> > > Гарантируется ли строгая (логическая) сериализация заданий?
> > А что это значит?
> 
> Это понятие из теории СУБД.  Транзакции могут выполняться параллельно,
> но с точки зрения самой транзакции она выполняется как бы эксклюзивно,
> а результат параллельного выполнения должен быть такой, как если бы
> транзакции выполнялись в каком-либо порядке.  Иначе возникают неприятные
> побочные эффекты (самый известный и простой - продать два билета на одно
> место).

В этом смысле да, такая сериализация заданий гарантируется.
При условии что gb-task-validate-state и кэширование в
gb-remote-build/gb-remote-check-install реализовано правильно, конечно.

> Т.е. одно коммитится, все остальные идут на реитерацию.

Да.


-- 
ldv

[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]

Re: [devel] I: git.alt update

[Dmitry V. Levin]

[-- Attachment #1: Type: text/plain, Size: 504 bytes --]

On Mon, Nov 22, 2010 at 11:12:02PM +0200, Igor Vlasenko wrote:
> Субъективно долго что-то собираются пакеты.
> С другой стороны, хороший стресс-тест для сборочницы.

Я уже нашел и исправил одну неоптимальность: при наличии очень большого
числа заданий одного пользователя в состоянии awaiting сборочница тратила
на выбор задания больше времени, чем следовало.

Похоже что фоновая нагрузка сборочнице обеспечена надолго:

$ git.alt task ls --user=viy --state=awaiting |wc -l
465


-- 
ldv

[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]

Re: [devel] I: git.alt update

[Dmitry V. Levin]

[-- Attachment #1: Type: text/plain, Size: 671 bytes --]

On Tue, Nov 23, 2010 at 02:57:30AM +0300, Dmitry V. Levin wrote:
> On Mon, Nov 22, 2010 at 11:12:02PM +0200, Igor Vlasenko wrote:
> > Субъективно долго что-то собираются пакеты.
> > С другой стороны, хороший стресс-тест для сборочницы.
> 
> Я уже нашел и исправил одну неоптимальность: при наличии очень большого
> числа заданий одного пользователя в состоянии awaiting сборочница тратила
> на выбор задания больше времени, чем следовало.
> 
> Похоже что фоновая нагрузка сборочнице обеспечена надолго:
> 
> $ git.alt task ls --user=viy --state=awaiting |wc -l
> 465

Эта очередь заданий уже обработана, больше никаких багов пока не вылезло.


-- 
ldv

[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]

Re: [devel] I: git.alt update

[Igor Vlasenko]

On Thu, Nov 25, 2010 at 01:40:15AM +0300, Dmitry V. Levin wrote:
> On Tue, Nov 23, 2010 at 02:57:30AM +0300, Dmitry V. Levin wrote:
> > On Mon, Nov 22, 2010 at 11:12:02PM +0200, Igor Vlasenko wrote:
> > > Субъективно долго что-то собираются пакеты.
> > > С другой стороны, хороший стресс-тест для сборочницы.
> > 
> > Я уже нашел и исправил одну неоптимальность: при наличии очень большого
> > числа заданий одного пользователя в состоянии awaiting сборочница тратила
> > на выбор задания больше времени, чем следовало.
> > 
> > Похоже что фоновая нагрузка сборочнице обеспечена надолго:
> > 
> > $ git.alt task ls --user=viy --state=awaiting |wc -l
> > 465
> 
> Эта очередь заданий уже обработана, больше никаких багов пока не вылезло.

Может будет полезно, приходило письмо счастья,
похоже на то, что могут случаться проблемы с синхрогизацией.

Subject: [#33942] FAILED srpm=fix-mime-charset-0.5.3-alt3.1.src.rpm

http://git.altlinux.org/tasks/33942/task/log.1.1

2010-Nov-25 00:59:32 :: task #33942 for sisyphus started by viy:
#100 build fix-mime-charset-0.5.3-alt3.1.src.rpm
2010-Nov-25 00:59:32 :: waiting for a shared lock on Sisyphus
2010-Nov-25 00:59:52 :: acquired a shared lock on Sisyphus
2010-Nov-25 00:59:54 :: cloned Sisyphus
2010-Nov-25 00:59:55 :: [x86_64] #100 fix-mime-charset-0.5.3-alt3.1.src.rpm: build start
2010-Nov-25 00:59:55 :: [i586] #100 fix-mime-charset-0.5.3-alt3.1.src.rpm: build start
Failed to fetch file:/home/bee10/gb-repo/noarch/base/pkglist.classic  Size mismatch
E: Some index files failed to download, they have been ignored, or old ones used instead.
2010-Nov-25 01:00:01 :: [i586] fix-mime-charset-0.5.3-alt3.1.src.rpm: remote: initroot failed
2010-Nov-25 01:00:01 :: [i586] #100 fix-mime-charset-0.5.3-alt3.1.src.rpm: build FAILED
Failed to fetch file:/home/bee10/gb-repo/noarch/base/pkglist.classic  Size mismatch
E: Some index files failed to download, they have been ignored, or old ones used instead.
2010-Nov-25 01:00:01 :: [x86_64] fix-mime-charset-0.5.3-alt3.1.src.rpm: remote: initroot failed
2010-Nov-25 01:00:01 :: [x86_64] #100 fix-mime-charset-0.5.3-alt3.1.src.rpm: build FAILED
2010-Nov-25 01:00:01 :: [i586] build FAILED
2010-Nov-25 01:00:02 :: [x86_64] build FAILED
2010-Nov-25 01:00:02 :: task #33942 for sisyphus FAILED



-- 

Dr. Igor Vlasenko
--------------------
Topology Department
Institute of Math
Kiev, Ukraine

Re: [devel] I: git.alt update

[Dmitry V. Levin]

[-- Attachment #1: Type: text/plain, Size: 1910 bytes --]

On Thu, Nov 25, 2010 at 12:46:03AM +0200, Igor Vlasenko wrote:
> Может будет полезно, приходило письмо счастья,
> похоже на то, что могут случаться проблемы с синхрогизацией.
> 
> Subject: [#33942] FAILED srpm=fix-mime-charset-0.5.3-alt3.1.src.rpm
> 
> http://git.altlinux.org/tasks/33942/task/log.1.1
> 
> 2010-Nov-25 00:59:32 :: task #33942 for sisyphus started by viy:
> #100 build fix-mime-charset-0.5.3-alt3.1.src.rpm
> 2010-Nov-25 00:59:32 :: waiting for a shared lock on Sisyphus
> 2010-Nov-25 00:59:52 :: acquired a shared lock on Sisyphus
> 2010-Nov-25 00:59:54 :: cloned Sisyphus
> 2010-Nov-25 00:59:55 :: [x86_64] #100 fix-mime-charset-0.5.3-alt3.1.src.rpm: build start
> 2010-Nov-25 00:59:55 :: [i586] #100 fix-mime-charset-0.5.3-alt3.1.src.rpm: build start
> Failed to fetch file:/home/bee10/gb-repo/noarch/base/pkglist.classic  Size mismatch
> E: Some index files failed to download, they have been ignored, or old ones used instead.
> 2010-Nov-25 01:00:01 :: [i586] fix-mime-charset-0.5.3-alt3.1.src.rpm: remote: initroot failed
> 2010-Nov-25 01:00:01 :: [i586] #100 fix-mime-charset-0.5.3-alt3.1.src.rpm: build FAILED
> Failed to fetch file:/home/bee10/gb-repo/noarch/base/pkglist.classic  Size mismatch
> E: Some index files failed to download, they have been ignored, or old ones used instead.
> 2010-Nov-25 01:00:01 :: [x86_64] fix-mime-charset-0.5.3-alt3.1.src.rpm: remote: initroot failed
> 2010-Nov-25 01:00:01 :: [x86_64] #100 fix-mime-charset-0.5.3-alt3.1.src.rpm: build FAILED
> 2010-Nov-25 01:00:01 :: [i586] build FAILED
> 2010-Nov-25 01:00:02 :: [x86_64] build FAILED
> 2010-Nov-25 01:00:02 :: task #33942 for sisyphus FAILED

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


-- 
ldv

[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]

[devel] [JT] Re: I: git.alt update

[Michael Shigorin]

On Thu, Nov 25, 2010 at 01:59:55AM +0300, Dmitry V. Levin wrote:
> > Subject: [#33942] FAILED srpm=fix-mime-charset-0.5.3-alt3.1.src.rpm
> > http://git.altlinux.org/tasks/33942/task/log.1.1
> Если бы я не получил такое же письмо счастье (которое успешно
> пропустил), то я бы сказал, что этого не может быть в принципе.
> Репозиторий клонируется только тогда, когда он находится в
> консистентном состоянии.

Это специальный пакет, который когда-то собирался для заказчика,
которого конкретно покусал hiddenman@.

Возможно, пора удалить из сизифа, хотя если на нём вылазят
такие спецэффекты -- то может, как раз лучше и оставить ;-)

-- 
 ---- WBR, Michael Shigorin <mike@altlinux.ru>
  ------ Linux.Kiev http://www.linux.kiev.ua/

Re: [devel] I: git.alt update

[Michael Shigorin]

On Mon, Nov 22, 2010 at 11:57:40PM +0300, Dmitry V. Levin wrote:
> Нет, к сожалению, такая оптимизация была бы неправильной,
> поскольку любое изменение в репозитории теоретически может
> повлиять на результат обработки задания.

Я когда-то предлагал оставлять "на будущее" ресурсоёмкость сборки
(user/system time) и то, какие пакеты были установлены в чрут.
С тем, чтобы по возможности пользоваться закэшированной
информацией и применять более дорогие тесты только при
необходимости -- бишь если список пакетов по факту изменился,
то содержимое кэша признаётся невалидным вместе со сделанным
предварительным выводом.

К сожалению, тот контекст уже давно выветрился из головы и более
предметно выразить мыслю не могу, но это была комбинация
изобретательского принципа "сделай заранее" и закона 80/20.

-- 
 ---- WBR, Michael Shigorin <mike@altlinux.ru>
  ------ Linux.Kiev http://www.linux.kiev.ua/