[devel] robots VS sisyphus

[devel] robots VS sisyphus

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

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

В итоге единственное чем _мешает_ массовый импорт из федоры
пользователям/мантейнерам -- то что наш apt плохо масштабируется. И чем
больше пакетов, тем он тормознее.

И решать надо именно эту проблему.

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

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

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

Re: [devel] масштабируемость репозитория

[Dmitry V. Levin]

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

On Sat, Dec 24, 2011 at 01:15:15AM +0400, Денис Смирнов wrote:
> В итоге единственное чем _мешает_ массовый импорт из федоры
> пользователям/мантейнерам -- то что наш apt плохо масштабируется. И чем
> больше пакетов, тем он тормознее.

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

Есть два независимых метода борьбы с этим торможением:
- Сделать apt существенно быстрее, чтобы эффект торможения не так сильно
раздражал; мы думаем над этим.
- Разделить пакетную базы на части.  Критериев, по которым можно было бы
делить, я полагаю, каждый может назвать несколько.  Самым безболезненным
типом деления является выделение кластеров пакетов по критерию
независимости: если есть некоторое подмножество пакетов, которое не
используется для установки и сборки всех остальных пакетов, то его можно
было бы выделить без риска потерять связность репозитория.  Если такое
подмножество достаточно велико, то и компенсация эффекта торможения тоже
будет достаточно заметна.  Примером такого кластера, наверное, является
множество debuginfo-пакетов.  Интересно, существуют ли какие-то другие
крупные кластеры этого типа?


-- 
ldv

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

Re: [devel] масштабируемость репозитория

[Paul Wolneykien]

24.12.2011 03:17, Dmitry V. Levin пишет:
> On Sat, Dec 24, 2011 at 01:15:15AM +0400, Денис Смирнов wrote:
>> В итоге единственное чем _мешает_ массовый импорт из федоры
>> пользователям/мантейнерам -- то что наш apt плохо масштабируется. И чем
>> больше пакетов, тем он тормознее.
> 
> apt масштабируется пропорционально размеру индексов.  Так что, строго
> говоря, тормознее он становится не столько вследствие импорта из федоры,
> сколько от роста пакетной базы.
> 
> Есть два независимых метода борьбы с этим торможением:
> - Сделать apt существенно быстрее, чтобы эффект торможения не так сильно
> раздражал; мы думаем над этим.
> - Разделить пакетную базы на части.  Критериев, по которым можно было бы
> делить, я полагаю, каждый может назвать несколько.  Самым безболезненным
> типом деления является выделение кластеров пакетов по критерию
> независимости: если есть некоторое подмножество пакетов, которое не
> используется для установки и сборки всех остальных пакетов, то его можно
> было бы выделить без риска потерять связность репозитория.

  Мне кажется, что сборка — это всё таки специфический случай: тот, кто
собирает пакеты уже готов идти на определённые затраты ресурсов и может
подключит все индексы. Может быть стоит искать кластеры только по
критерию локально-независимой устанавливаемости?

> Если такое
> подмножество достаточно велико, то и компенсация эффекта торможения тоже
> будет достаточно заметна.  Примером такого кластера, наверное, является
> множество debuginfo-пакетов.  Интересно, существуют ли какие-то другие
> крупные кластеры этого типа?

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

  Возможно, выпуском таких облегчённых версий могут заниматься роботы.
Их задачей может стать «прогрызание» плотной ткани репозитория вокруг
тех областей, в которых намечаются кластеры. В результате надкусывания
пакета, образуются две его версии: тежёлая и лёгкая. Лёгкая идёт в один
кластер, а тяжёлая — в другой. Общее число пакетов станет больше, но
появятся кластеры.

Re: [devel] масштабируемость репозитория

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

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

On Sat, Dec 24, 2011 at 03:17:03AM +0400, Dmitry V. Levin wrote:

DVL> apt масштабируется пропорционально размеру индексов.  Так что, строго
DVL> говоря, тормознее он становится не столько вследствие импорта из федоры,
DVL> сколько от роста пакетной базы.

Да.

DVL> Есть два независимых метода борьбы с этим торможением:
DVL> - Сделать apt существенно быстрее, чтобы эффект торможения не так сильно
DVL> раздражал; мы думаем над этим.

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

Проблема №1 -- ряд операций (таких как apt-cache) выполняют ненужно
большой объем работ перед запуском.

Проблема №2 -- операции вида apt-get install/remove (одни из самых частых)
требуют вычисления этого кэша в любом случае. Возможно ли вычислять его
инкрементально?

DVL> - Разделить пакетную базы на части.  Критериев, по которым можно было бы
DVL> делить, я полагаю, каждый может назвать несколько.  Самым безболезненным
DVL> типом деления является выделение кластеров пакетов по критерию
DVL> независимости: если есть некоторое подмножество пакетов, которое не
DVL> используется для установки и сборки всех остальных пакетов, то его можно
DVL> было бы выделить без риска потерять связность репозитория.  Если такое
DVL> подмножество достаточно велико, то и компенсация эффекта торможения тоже
DVL> будет достаточно заметна.  Примером такого кластера, наверное, является
DVL> множество debuginfo-пакетов.  Интересно, существуют ли какие-то другие
DVL> крупные кластеры этого типа?

1. Игры.
2. Дополнительные репозитории с массовыми импортами пакетов какого-то
типа:
- если собирать весь CPAN, то можно переносить в main/contrib только то,
  на что у кого-то есть buildrequires;
- если собирать массово содержимое hackage -- аналогично, в основном его
  содержимое будет нужно для сборки с самим собой;
- те же массовые импороты библиотек из fedora;
3. В принципе можно вообще попытаться отделить в отдельную компоненту
"листья", которе никому не нужны для сборки. Их много.
4. Таки пакеты необходимые только для сборки -- *devel*. Это не ускорит
сборочницу, но ускорит работу apt у большинства "обычных пользователей".

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

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


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

Re: [devel] масштабируемость репозитория

[Alexei Takaseev]

----- Исходное сообщение -----
> От: "Денис Смирнов" <mithraen@freesource.info>
> Кому: "ALT Linux Team development discussions" <devel@lists.altlinux.org>
> Отправленные: Суббота, 24 Декабрь 2011 г 19:21:49
> Тема: Re: [devel] масштабируемость репозитория
> 
> 1. Игры.
> 2. Дополнительные репозитории с массовыми импортами пакетов какого-то
> типа:
> - если собирать весь CPAN, то можно переносить в main/contrib только
> то,
>   на что у кого-то есть buildrequires;
> - если собирать массово содержимое hackage -- аналогично, в основном
> его
>   содержимое будет нужно для сборки с самим собой;
> - те же массовые импороты библиотек из fedora;
> 3. В принципе можно вообще попытаться отделить в отдельную компоненту
> "листья", которе никому не нужны для сборки. Их много.
> 4. Таки пакеты необходимые только для сборки -- *devel*. Это не
> ускорит
> сборочницу, но ускорит работу apt у большинства "обычных
> пользователей".

5. debuginfo-пакеты, которые составляют до 50% нынешнего количества пакетов, и которые не нужны 99.999% _пользователям_ репозитария.

Re: [devel] масштабируемость репозитория

[Igor Vlasenko]

On Sat, Dec 24, 2011 at 03:17:03AM +0400, Dmitry V. Levin wrote:
> множество debuginfo-пакетов.  Интересно, существуют ли какие-то другие
> крупные кластеры этого типа?

*-javadoc пакеты, 
ls *-javadoc-* | wc -l
968

-- 

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

Re: [devel] масштабируемость репозитория

[thecrux]

On Sat, Dec 24, 2011 at 03:17:03AM +0400, Dmitry V. Levin wrote:
> - Разделить пакетную базы на части.  Критериев, по которым можно было бы
> делить, я полагаю, каждый может назвать несколько.  Самым безболезненным
> типом деления является выделение кластеров пакетов по критерию
> независимости: если есть некоторое подмножество пакетов, которое не
> используется для установки и сборки всех остальных пакетов, то его можно
> было бы выделить без риска потерять связность репозитория.  Если такое
> подмножество достаточно велико, то и компенсация эффекта торможения тоже
> будет достаточно заметна.  Примером такого кластера, наверное, является
> множество debuginfo-пакетов.  Интересно, существуют ли какие-то другие
> крупные кластеры этого типа?

Если смотеть по группам пакетам, то заметны такие крупные массивы, которые
кажутся вполне изолируемыми (данные с sisyphus.ru)

* Games/* 526
* Development/Java 1011
* Development/Perl 1409
* Development/Python 1103
* Development/Kernel + System/Kernel and hardware 60+358
* System/Servers 471

Конечно не уверен на счёт изолируемости python, т.к. он используется во
многих desktop-приложениях.
Можно попробовать также выделить Gnome и KDE, т.к. редко на одной системе
задействованы сразу оба набора, но это задача явно нетривиальная.

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

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

Re: [devel] масштабируемость репозитория

[thecrux]

On Sat, Dec 24, 2011 at 03:17:03AM +0400, Dmitry V. Levin wrote:
> On Sat, Dec 24, 2011 at 01:15:15AM +0400, Денис Смирнов wrote:
> > В итоге единственное чем _мешает_ массовый импорт из федоры
> > пользователям/мантейнерам -- то что наш apt плохо масштабируется. И чем
> > больше пакетов, тем он тормознее.
> 
> apt масштабируется пропорционально размеру индексов.  Так что, строго
> говоря, тормознее он становится не столько вследствие импорта из федоры,
> сколько от роста пакетной базы.

А если прямо сейчас создать категорию stage и все новые пакеты помещать
в эту категорию, за исключением возможно переименованнах пакетов или новых
версий библиотек (вроде boost)?

Также начать перенос в unsupported всех пакетов, которые в данный момент
на nobody@ или зависят от пакетов из этой категории.

Создать некое полиси по процедуре переноса из категории stage в main.
Например, наличие анонса в sisyphus@ с информацией об этом пакете, из
которого было бы ясно, что человек имеет представление о том, что собрал.
Наличие по крайней мере одного co-maintainer'а у пакета, отсутстсвие
критических багов...

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

Re: [devel] масштабируемость репозитория

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

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

On Sat, Dec 24, 2011 at 03:17:03AM +0400, Dmitry V. Levin wrote:

Еще про разделение на компоненты -- существенная часть пакетов не имеет
смысла для VE. Это и ядро с модулями, и различные системные приложения
вроде fdisk. 

А отдаелять просто kernel -- не вижу особого смысла.

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

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

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

Re: [devel] масштабируемость репозитория

[Michael Shigorin]

On Sat, Dec 24, 2011 at 03:17:03AM +0400, Dmitry V. Levin wrote:
> Примером такого кластера, наверное, является множество
> debuginfo-пакетов.  Интересно, существуют ли какие-то другие
> крупные кластеры этого типа?

RPMS.media -- можно попробовать даже изобразить эвристику:
- от бинарных пакетов ничего не зависит;
- бинарные пакеты могут зависеть от -data;
- размер -data типично от 10..50Mb и вверх.

Далее, замыкать тот же RPMS.contrib стоит по main+contrib,
и это может помочь понять, на каких пакетах вообще стоит
концентрировать усилия: если от моего "контрибного" liblasi
вдруг зависит сборка моего "основного" graphviz, то вынося
первое в contrib -- я задумаюсь*:
- то ли graphviz тоже в contrib;
- то ли liblasi держать и сопровождать в main сообразно;
- то ли отцеплять graphviz от liblasi, если поддерживать
  последний как следует не получается.

Что опять же может поспособствовать качеству пакетной базы.

Формировал бы я его методом "перетекания" по решению майнтейнеров
на начальной стадии; при ответвлении бранча -- по умолчанию
наоборот, отталкиваясь от соображений поддержки строить main,
а всё остальное -- в contrib.

* пример несколько надуман -- у меня нет претензий к апстриму
  liblasi и все высказанные замечания/предложения AFAIR учтены

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

Re: [devel] robots VS sisyphus

[Alexey Tourbin]

On Sat, Dec 24, 2011 at 01:15:15AM +0400, Денис Смирнов wrote:
> В итоге единственное чем _мешает_ массовый импорт из федоры
> пользователям/мантейнерам -- то что наш apt плохо масштабируется. И чем
> больше пакетов, тем он тормознее.

Apt масштабируется как O(n), где n - количество пакетов.
Кроме того, константа масштабирования очень хорошая: на сервере с 24G RAM
все операции апта выполняются менее чем за секунду.  То есть нет такого,
что сожрали CPU user time и никакого ответа не дали - дескать подождите ещё.

> И решать надо именно эту проблему.

Проблемы надо решать в отдельно взятой голове.

Re: [devel] robots VS sisyphus

[thecrux]

On Sun, Dec 25, 2011 at 08:47:36AM +0400, Alexey Tourbin wrote:
> On Sat, Dec 24, 2011 at 01:15:15AM +0400, Денис Смирнов wrote:
> > В итоге единственное чем _мешает_ массовый импорт из федоры
> > пользователям/мантейнерам -- то что наш apt плохо масштабируется. И чем
> > больше пакетов, тем он тормознее.
> 
> Apt масштабируется как O(n), где n - количество пакетов.
> Кроме того, константа масштабирования очень хорошая: на сервере с 24G RAM
> все операции апта выполняются менее чем за секунду.  То есть нет такого,
> что сожрали CPU user time и никакого ответа не дали - дескать подождите ещё.

Объём памяти большого значения не имеет, а вот потребление CPU user time
бывает очень серьёзным. Практически на все операции apt потребляет 99%CPU

$ /usr/bin/time apt-cache search abc > /dev/null 
4.54user 1.02system 0:05.57elapsed 99%CPU (0avgtext+0avgdata 291152maxresident)k
0inputs+0outputs (0major+7556minor)pagefaults 0swaps

Можно даже спалить процессор запустив:

$ apt-cache search $(perl -e 'print "a "x1025') > /dev/null

Можно собрать apt с флагом CXXFLAGS=-pg и увидеть, что любимая операция
apt это сортировка. Кстати, хороший алгоритм сортировки даёт O(n log n)
в худших случаях, поэтому мне кажется малореалистичной оценка
масштабируемости apt, как O(n).

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

Re: [devel] robots VS sisyphus

[Alexey Tourbin]

On Sun, Dec 25, 2011 at 03:55:28PM +0400, thecrux@gmail.com wrote:
> On Sun, Dec 25, 2011 at 08:47:36AM +0400, Alexey Tourbin wrote:
> > On Sat, Dec 24, 2011 at 01:15:15AM +0400, Денис Смирнов wrote:
> > > В итоге единственное чем _мешает_ массовый импорт из федоры
> > > пользователям/мантейнерам -- то что наш apt плохо масштабируется. И чем
> > > больше пакетов, тем он тормознее.
> > 
> > Apt масштабируется как O(n), где n - количество пакетов.
> > Кроме того, константа масштабирования очень хорошая: на сервере с 24G RAM
> > все операции апта выполняются менее чем за секунду.  То есть нет такого,
> > что сожрали CPU user time и никакого ответа не дали - дескать подождите ещё.
> 
> Объём памяти большого значения не имеет, а вот потребление CPU user time
> бывает очень серьёзным. Практически на все операции apt потребляет 99%CPU
> 
> $ /usr/bin/time apt-cache search abc > /dev/null 
> 4.54user 1.02system 0:05.57elapsed 99%CPU (0avgtext+0avgdata 291152maxresident)k
> 0inputs+0outputs (0major+7556minor)pagefaults 0swaps

apt-cache search рыскает pkglist файлы в каталоге /var/lib/apt/lists.
Сканирует их в цикле.  Этот поиск заведомо не относится к эффективным.

Алгоритмы разрешения зависимостей, которые выполняются на основной
структуре данных - /var/cache/apt/pkgcache.bin - работают гораздо быстрее.

> Можно даже спалить процессор запустив:
> 
> $ apt-cache search $(perl -e 'print "a "x1025') > /dev/null
> 
> Можно собрать apt с флагом CXXFLAGS=-pg и увидеть, что любимая операция
> apt это сортировка. Кстати, хороший алгоритм сортировки даёт O(n log n)
> в худших случаях, поэтому мне кажется малореалистичной оценка
> масштабируемости apt, как O(n).

Сортировка выполняется только раз (при пересборке кеша), а логарифм растёт
очень медленно.  Физики говоря, что логарифм в первом приближении можно
считать константой.  Вообще, логарифм асимптотически меньше любой степени;
например, O(n log n) < O(n^{1.1}).

Если отвлечься от теории, то нету примера, что апт непропорционально жрёт CPU
user time.  Он иногда жрёт system time, но это потому что у вас 1) большой
репозиторий и 2) ядро глючит.

Re: [devel] robots VS sisyphus

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

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

On Sun, Dec 25, 2011 at 08:47:36AM +0400, Алексей Турбин wrote:

AT> Apt масштабируется как O(n), где n - количество пакетов.

На какой операции?
И n -- количество пакетов, а не зависимостей?

AT> Кроме того, константа масштабирования очень хорошая: на сервере с 24G RAM
AT> все операции апта выполняются менее чем за секунду.  То есть нет такого,
AT> что сожрали CPU user time и никакого ответа не дали - дескать подождите ещё.

Увы, не у всех пока есть ноутбуки с характеристиками "сервера с 24G RAM",
например. А apt используется отнюдь не только при сборке пакетов.

А когда я при apt-cache вижу вот такое:
4.85s user 3.06s system 22% cpu 34.723 total

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

apt-cache search должен выполняться за менее чем 1s на среднем железе.
Среднее сейчас это что-то вроде 2G RAM, 2GHz core 2 duo.

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

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

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

Re: [devel] robots VS sisyphus

[Alexey Tourbin]

On Sun, Dec 25, 2011 at 06:53:04PM +0400, Денис Смирнов wrote:
> On Sun, Dec 25, 2011 at 08:47:36AM +0400, Алексей Турбин wrote:
> AT> Apt масштабируется как O(n), где n - количество пакетов.
> 
> На какой операции?
> И n -- количество пакетов, а не зависимостей?

Амортизированное время разрешения зависимостей при установке пакетов.
Например, это операция "apt-cache unmet" или более сложная операция
"apt-shell <<<unmet", которая включает в себя пересборку кеша зависимостей.

> AT> Кроме того, константа масштабирования очень хорошая: на сервере с 24G RAM
> AT> все операции апта выполняются менее чем за секунду.  То есть нет такого,
> AT> что сожрали CPU user time и никакого ответа не дали - дескать подождите ещё.
> 
> Увы, не у всех пока есть ноутбуки с характеристиками "сервера с 24G RAM",
> например. А apt используется отнюдь не только при сборке пакетов.
> 
> А когда я при apt-cache вижу вот такое:
> 4.85s user 3.06s system 22% cpu 34.723 total
> 
> мне становится сразу понятно что apt недостаточно быстрый с точки зрения
> пользователя.

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

> apt-cache search должен выполняться за менее чем 1s на среднем железе.
> Среднее сейчас это что-то вроде 2G RAM, 2GHz core 2 duo.

Ты не понимешь, как работает apt.  "Apt-cache search" практически
построчно сканирует те файлы, которые он скачал.  Это никогда не будет
слишком быстро работать, by design.  А обработка зависимостей
происходит на порядок быстрее за счет создания промежуточной структуры
данных - /var/cache/apt/pkgcache.bin.

[devel] [JT] Re: robots VS sisyphus

[Igor Vlasenko]

> > мне становится сразу понятно что apt недостаточно быстрый с точки зрения
> > пользователя.

Такому пользователю надо попробовать yum :)

Не совсем понятно, как связанно быстродействие apt с роботами 
и сизифом, но понятно, от ругани в рассылке apt быстрее не станет.

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

-- 

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

Re: [devel] robots VS sisyphus

[Sergei Epiphanov]

On 25 декабря 2011 08:47 Alexey Tourbin wrote:
> Apt масштабируется как O(n), где n - количество пакетов.
> Кроме того, константа масштабирования очень хорошая: на сервере с 24G RAM
> все операции апта выполняются менее чем за секунду.  То есть нет такого,
> что сожрали CPU user time и никакого ответа не дали - дескать подождите ещё.

Я пока еще не замечал, чтобы у рядового пользователя стоял бы сервер с 24ГБ 
памяти на борту. Hasher, например, для сборки пакета задействует apt не 
единожды и с базой Сизифа, объединённой со своей локальной для возможности 
сборки пакетов с учётом уже собранных ранее. И так для каждого пакета, 
проверяемого локально на сборку. А если пакетов несколько десятков?

-- 
С уважением, Епифанов Сергей

Re: [devel] robots VS sisyphus

[Alexey Tourbin]

On Mon, Dec 26, 2011 at 03:16:49PM +0400, Sergei Epiphanov wrote:
> On 25 декабря 2011 08:47 Alexey Tourbin wrote:
> > Apt масштабируется как O(n), где n - количество пакетов.
> > Кроме того, константа масштабирования очень хорошая: на сервере с 24G RAM
> > все операции апта выполняются менее чем за секунду.  То есть нет такого,
> > что сожрали CPU user time и никакого ответа не дали - дескать подождите ещё.
> 
> Я пока еще не замечал, чтобы у рядового пользователя стоял бы сервер с 24ГБ 
> памяти на борту. Hasher, например, для сборки пакета задействует apt не 
> единожды и с базой Сизифа, объединённой со своей локальной для возможности 
> сборки пакетов с учётом уже собранных ранее. И так для каждого пакета, 
> проверяемого локально на сборку. А если пакетов несколько десятков?

Я привёл пример c 24G RAM, чтобы исключить влияние виртуальной памяти и
page faults.  Понятно, что если у Вас 1G RAM и запущен Firefox, то hasher
не справится за секунду.  Но всё же справится относительно быстро, а торомоза
не следовало бы относить в первую очередь на счет apt.

Re: [devel] robots VS sisyphus

[Sergei Epiphanov]

On 28 декабря 2011 00:09 Alexey Tourbin wrote:
> > Я пока еще не замечал, чтобы у рядового пользователя стоял бы сервер с
> > 24ГБ  памяти на борту. Hasher, например, для сборки пакета задействует
> > apt не единожды и с базой Сизифа, объединённой со своей локальной для
> > возможности сборки пакетов с учётом уже собранных ранее. И так для
> > каждого пакета, проверяемого локально на сборку. А если пакетов
> > несколько десятков?
> Я привёл пример c 24G RAM, чтобы исключить влияние виртуальной памяти и
> page faults.  Понятно, что если у Вас 1G RAM и запущен Firefox, то hasher
> не справится за секунду.  Но всё же справится относительно быстро, а
> торомоза не следовало бы относить в первую очередь на счет apt.

А что значит "относительно быстро"? У меня дома i7 975 с 12ГБ на борту
(виртуальной памяти нет) и винтом Velociraptor 10000rpm. И то сбор данных
занимает порядка двух секунд. А hasher'у по каждому собираемому пакету
сначала нужно проверить адекватность chroot (первое обращение), потом
поставить пакеты (второе обращение), потом под конец ещё одна генерация списка.

Сервера (на Xeon и Opteron) показывают в 5-10 раз выше производительность
в обработке данных по сравнению с любыми десктопными процессорами той же
частоты даже при меньшей паспортной производительности памяти. Сужу
по сравнению старого Xeon 3.2ГГц с i7 760. Уже одно это отрывает Ваш пример
от действительности.

i7 960 + 24ГБ оперативки (6х4ГБ) с винтом WD Diamond Black 2ТБ
с локальной базой Сизифа
======================================
С реальным чтением с диска
# time apt-get update
[sudo] password for pif:
Reading Package Lists... Done
Building Dependency Tree... Done
2.07user 0.60system 0:11.88elapsed 22%CPU (0avgtext+0avgdata 279120maxresident)k
382136inputs+151480outputs (28major+27754minor)pagefaults 0swaps

С закешированными в памяти данными
# time apt-get update
Reading Package Lists... Done
Building Dependency Tree... Done
1.89user 0.36system 0:03.11elapsed 72%CPU (0avgtext+0avgdata 279504maxresident)k
8inputs+151480outputs (22major+28804minor)pagefaults 0swaps
# 

Xeon 3.2ГГц + 4ГБ оперативки (4х1ГБ) с softRAID1 на WD DIamond Black 1ТБ
с удалённой базой Сизифа через сеть 100МБит
=====================================
С реальным чтением базы с диска
# time apt-get update
Get:1 ftp://IP i586 release [861B]                                                                                                                                
Get:2 ftp://IP noarch release [859B]                                                                                                                              
Fetched 1720B in 0s (4066B/s)                                                                                                                                                  
Hit ftp://IP i586/classic pkglist                                                                                                                                 
Hit ftp://IP i586/classic release                                                                                                                                 
Hit ftp://IP noarch/classic pkglist                                                                                                                               
Hit ftp://IP noarch/classic release                                                                                                                               
Reading Package Lists...                                                                                                                                                       
Building Dependency Tree...                                                                                                                                                    
3.62user 1.40system 0:11.95elapsed 42%CPU (0avgtext+0avgdata 220048maxresident)k                                                                                               
312248inputs+148008outputs (29major+41574minor)pagefaults 0swaps

С закешированными в памяти данными
# time apt-get update
Get:1 ftp://IP i586 release [861B]                                                                                                                                
Get:2 ftp://IP noarch release [859B]                                                                                                                              
Fetched 1720B in 0s (6490B/s)                                                                                                                                                  
Hit ftp://IP i586/classic pkglist                                                                                                                                 
Hit ftp://IP i586/classic release                                                                                                                                 
Hit ftp://IP noarch/classic pkglist                                                                                                                               
Hit ftp://IP noarch/classic release                                                                                                                               
Reading Package Lists...                                                                                                                                                       
Building Dependency Tree...                                                                                                                                                    
1.21user 0.12system 0:01.86elapsed 71%CPU (0avgtext+0avgdata 193232maxresident)k                                                                                               
0inputs+912outputs (3major+19584minor)pagefaults 0swaps

Вопрос: что читает apt с диска  в течение 10 сек?

-- 
С уважением, Епифанов Сергей

[devel] apt performance (was: robots VS sisyphus)

[Michael Shigorin]

On Wed, Dec 28, 2011 at 11:27:15AM +0400, Sergei Epiphanov wrote:
> Сервера (на Xeon и Opteron) показывают в 5-10 раз выше
> производительность в обработке данных по сравнению с любыми
> десктопными процессорами той же частоты даже при меньшей
> паспортной производительности памяти.

Вероятно, для данных и кода, вдруг начинающих умещаться
в более объёмный кэш L1+L2.

> Вопрос: что читает apt с диска  в течение 10 сек?

Припоминая bonnie++, можно предположить,
что это не блочное чтение...

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

Re: [devel] apt performance (was: robots VS sisyphus)

[Sergei Epiphanov]

On 28 декабря 2011 09:50 Michael Shigorin wrote:
> On Wed, Dec 28, 2011 at 11:27:15AM +0400, Sergei Epiphanov wrote:
> > Сервера (на Xeon и Opteron) показывают в 5-10 раз выше
> > производительность в обработке данных по сравнению с любыми
> > десктопными процессорами той же частоты даже при меньшей
> > паспортной производительности памяти.
> 
> Вероятно, для данных и кода, вдруг начинающих умещаться
> в более объёмный кэш L1+L2.

Не знаю. Кэш данных у Xeon E5440 (family 6 model 23 stepping 10) 6МБ, а у i7 - 
8МБ. И в этот момент ещё работает KDE. И идёт интенсивный данными между 
областями памяти и сетью.

Может, играет роль, что стоят 2 двухъядерных процессора Xeon (пусть и меньшей 
производительности, чем i7: 5652 bogomips против 6478 bogomips)? Но программа 
однопоточная...

> > Вопрос: что читает apt с диска  в течение 10 сек?
> 
> Припоминая bonnie++, можно предположить,
> что это не блочное чтение...

Возможности сделать быстрое чтение мешает выбранный тип баз данных RPM и APT?

P.S. Прошу прощения, ошибся: сейчас под расчеты стоит процессор E5440 с 
частотой 2,83ГГц. Но и предыдущий компьютер тоже не ударял в грязь лицом.

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

-- 
С уважением, Епифанов Сергей

Re: [devel] robots VS sisyphus

[Dmitry V. Levin]

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

On Sun, Dec 25, 2011 at 08:47:36AM +0400, Alexey Tourbin wrote:
> On Sat, Dec 24, 2011 at 01:15:15AM +0400, Денис Смирнов wrote:
> > В итоге единственное чем _мешает_ массовый импорт из федоры
> > пользователям/мантейнерам -- то что наш apt плохо масштабируется. И чем
> > больше пакетов, тем он тормознее.
> 
> Apt масштабируется как O(n), где n - количество пакетов.

Алексей, это утверждение, к сожалению, неверно.

> Кроме того, константа масштабирования очень хорошая: на сервере с 24G RAM
> все операции апта выполняются менее чем за секунду.

К сожалению, и это утверждение тоже неверно.  Есть операции, которые даже
на полностью закэшированных индексах выполняются _на_порядки_ дольше.


-- 
ldv

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

Re: [devel] robots VS sisyphus

[Alexey Tourbin]

On Mon, Dec 26, 2011 at 08:42:18PM +0400, Dmitry V. Levin wrote:
> On Sun, Dec 25, 2011 at 08:47:36AM +0400, Alexey Tourbin wrote:
> > On Sat, Dec 24, 2011 at 01:15:15AM +0400, Денис Смирнов wrote:
> > > В итоге единственное чем _мешает_ массовый импорт из федоры
> > > пользователям/мантейнерам -- то что наш apt плохо масштабируется. И чем
> > > больше пакетов, тем он тормознее.
> > 
> > Apt масштабируется как O(n), где n - количество пакетов.
> 
> Алексей, это утверждение, к сожалению, неверно.
> 
> > Кроме того, константа масштабирования очень хорошая: на сервере с 24G RAM
> > все операции апта выполняются менее чем за секунду.
> 
> К сожалению, и это утверждение тоже неверно.  Есть операции, которые даже
> на полностью закэшированных индексах выполняются _на_порядки_ дольше.

Когда я профилировал user time на типичных операциях разрешения
зависимостей для установки пакетов, то в топе был rpmsetcmp() и co,
но его удалось обуздать, так что он занимал меньше секунды user time.

Если есть другая информация, то она в принципе представляет для меня
определенный интерес.  Но глючное альтовское ядро для меня интереса не
представляет.  Так что я специально написал user time.

Re: [devel] robots VS sisyphus

[Alexey Tourbin]

On Mon, Dec 26, 2011 at 08:42:18PM +0400, Dmitry V. Levin wrote:
> On Sun, Dec 25, 2011 at 08:47:36AM +0400, Alexey Tourbin wrote:
> > On Sat, Dec 24, 2011 at 01:15:15AM +0400, Денис Смирнов wrote:
> > > В итоге единственное чем _мешает_ массовый импорт из федоры
> > > пользователям/мантейнерам -- то что наш apt плохо масштабируется. И чем
> > > больше пакетов, тем он тормознее.
> > 
> > Apt масштабируется как O(n), где n - количество пакетов.
> 
> Алексей, это утверждение, к сожалению, неверно.

Дмитрий Левин,
А какая у тебя асимптотическая оценка масштабирования апта?
В чем утверждения Алексея Турбина, к сожалению, неверны?

Re: [devel] robots VS sisyphus

[Dmitry V. Levin]

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

On Wed, Dec 28, 2011 at 12:55:59AM +0400, Alexey Tourbin wrote:
> On Mon, Dec 26, 2011 at 08:42:18PM +0400, Dmitry V. Levin wrote:
> > On Sun, Dec 25, 2011 at 08:47:36AM +0400, Alexey Tourbin wrote:
> > > On Sat, Dec 24, 2011 at 01:15:15AM +0400, Денис Смирнов wrote:
> > > > В итоге единственное чем _мешает_ массовый импорт из федоры
> > > > пользователям/мантейнерам -- то что наш apt плохо масштабируется. И чем
> > > > больше пакетов, тем он тормознее.
> > > 
> > > Apt масштабируется как O(n), где n - количество пакетов.
> > 
> > Алексей, это утверждение, к сожалению, неверно.
> 
> Дмитрий Левин,
> А какая у тебя асимптотическая оценка масштабирования апта?

Для какой модели тебя интересует асимптотическая оценка?
Какая операция, в каких условиях?

Дело в том, что производительность apt зависит не только от количества
пакетов.  Конечно, можно предположить, что все остальные факторы
зафиксированы и не меняются, но такая модель будет слишком проста,
слишком далека от реальности, и мне не интересно ее обсуждать.


-- 
ldv

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