[devel] Опыты с ускорением и экономией памяти при параллельной пересборке.

[devel] Опыты с ускорением и экономией памяти при параллельной пересборке.

[Igor Vlasenko]

Ускорение и экономия памяти при параллельной пересборке
с фиксированным репозиторием.

Кому интересен данный текст:

Нужна пересборка с большим количеством пакетов
(beehive ?), либо протестировать пересборку
с новой библиотекой, к примеру, новый питон.
Или параллельно собирать образы в hasher.
Или еще что-то делать одновременно на нескольких
hasher но с одним репозиторием.

Исходная проблема:

На altair можно было параллельно запустить 16-20
параллельных сборок в tmpfs, Я же хотел 32. Ядра там есть,
но на большее уже не хватало памяти.

Нужно уменьшить расход памяти.

Куда уходит в tmpfs память?
Часть, естественно, на chroot-ы,
Но, как оказалось, больше трети,
почти половину в случае легких пакетов (perl-* и т. д.)
забирает hasher на свои служебные нужды.

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

du -sh hasher (без chroot)
500M для sisyphus
640M для sisyphus+autoimports
Умножив, получим 640M*31=20G возможной экономии.

Убрав дублирование, сможем наслаждаться сборкой в 32 потока.

Как это сделать?

Я создаю кеш hasher workdir с помощью
hsh --with-stuff --initroot-only --apt-conf=...

затем хардлинкую на нужное число hasherX
mkdir hasherX
cp -rl кеш/{aptbox,cache} hasherX
rm && touch
  pid
  aptbox/var/cache/apt/archives/lock \
  aptbox/var/lib/apt/lists/lock \
  aptbox/var/lib/rpm/.rpm.lock \
  aptbox/var/lib/rpm/.dbenv.lock
Затем в идеале я бы сказал
hsh-mkchroot
hsh-initroot
hsh-rebuild
и у меня не только экономилась бы память, но и ускорялась бы сборка:
на mkaptbox c нуля hsh тратит около минуты, а поверх имеющегося -
порядка 20с.
Я же пропускал бы эти (1м|20с.) при сборке и по 20с. на
тестировании установки собранных бинарных пакетов
(а у нас в среднем 3 бинарных на 1 src)
т.е. заодно сборка-тестирование ускорились бы на полторы минуты на
каждый пакет.

Пока так хорошо не получается. Надо будет пропатчить
hsh-initroot, добавить в него полноценную поддержку
такого режима работы. Сейчас же hsh-initroot
с aptbox/'ом от hsh --initroot-only работать не хочет.
Кеш cache/chroot/chroot.cpio там есть.
Но при этом chroot нет, aptbox rpmdb говорит что build_list установлен,
hsh-initroot в недоумении:
fatal 'Failed to generate non-empty build package file list; check your sources.list'
Без патчения hsh-initchroot я пока извращаюсь
следующим образом:

При создании кеша hasher workdir после
hsh --with-stuff --initroot-only --apt-conf=...
я еще вызываю mkaptbox --with-stuff --initroot-only --apt-conf=...
Такой aptbox hsh-initroot уже кушает.
При этом я, как и до оптимизации, теряю 20с на раздумья hsh-initroot
и 200 Mb на то, что во время этих раздумий hsh-initroot
пересоздает
aptbox/var/cache/apt/pkgcache.bin
aptbox/var/cache/apt/srcpkgcache.bin

Но зато cache/chroot/chroot.cpio
и aptbox/var/lib/apt/lists остаются хардлинкованными,
что дает мне экономию в 440 Mb per hasher
или же 16Gb при запуске в altair.

Хотелось бы дожать такую оптимизацию до экономии всех 640 Mb
и полного отсутствия лагов.
В будущем она пригодится и для beehive,
и в сборочнице (например, в тесте на устанавливаемость)
и во многих других местах.


-- 

I V

Re: [devel] Опыты с ускорением и экономией памяти при параллельной пересборке.

[Igor Vlasenko]

On Tue, Mar 19, 2019 at 10:31:21PM +0200, Igor Vlasenko wrote:
> Пока так хорошо не получается. Надо будет пропатчить
> hsh-initroot, добавить в него полноценную поддержку
> такого режима работы. Сейчас же hsh-initroot
> с aptbox/'ом от hsh --initroot-only работать не хочет.
> Кеш cache/chroot/chroot.cpio там есть.
> Но при этом chroot нет, aptbox rpmdb говорит что build_list установлен,
> hsh-initroot в недоумении:
> fatal 'Failed to generate non-empty build package file list; check your sources.list'
> Без патчения hsh-initchroot я пока извращаюсь
> следующим образом: ...

Пропатчил hsh-initchroot. Теперь погоняю с ним 
недельку-две свою сборочницу для autoimorts 
на альтаире и буду готовить pull request.

-- 

I V

Re: [devel] overoptimizing hasher

[Dmitry V. Levin]

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

On Tue, Mar 19, 2019 at 10:31:21PM +0200, Igor Vlasenko wrote:
[...]
> У нас репозиторий статический,
> синхронизируется ночью и во время пересборки меняться не будет.
> Поэтому теоретически достаточно создать для
> каждой архитектуры единственный hasher workdir
> и затем его повторно использовать.

Тестовая пересборка проводится на снапшоте репозитория,
что создаёт предпосылки для оптимизации.

Первый hsh --initroot (без кэша) занимает там около 21 сек,
повторные (с кэшом) -- около 10.5 сек.

Если кэшировать aptbox после initroot, то
повторные hsh --initroot занимают там около 2.3 сек.

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

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


-- 
ldv

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 801 bytes --]

Re: [devel] overoptimizing hasher

[Anton Farygin]

25.03.2019 4:14, Dmitry V. Levin пишет:
> Первый hsh --initroot (без кэша) занимает там около 21 сек,
> повторные (с кэшом) -- около 10.5 сек.
>
> Если кэшировать aptbox после initroot, то
> повторные hsh --initroot занимают там около 2.3 сек.

Может быть есть смысл вернуться к идее apt'а как сервиса (apt-pipe) ?

apt-get во время обычной сборки пакета 6 раз. Время запуска apt'а 
порядка 2 секунд. Можно на одном пакете сэкономить 10 секунд на каждой 
сборке, что в сумме даст около 4000 минут машинного времени на всех пакетах.

Re: [devel] overoptimizing hasher

[Dmitry V. Levin]

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

On Mon, Mar 25, 2019 at 04:14:09AM +0300, Dmitry V. Levin wrote:
> On Tue, Mar 19, 2019 at 10:31:21PM +0200, Igor Vlasenko wrote:
> [...]
> > У нас репозиторий статический,
> > синхронизируется ночью и во время пересборки меняться не будет.
> > Поэтому теоретически достаточно создать для
> > каждой архитектуры единственный hasher workdir
> > и затем его повторно использовать.
> 
> Тестовая пересборка проводится на снапшоте репозитория,
> что создаёт предпосылки для оптимизации.
> 
> Первый hsh --initroot (без кэша) занимает там около 21 сек,
> повторные (с кэшом) -- около 10.5 сек.
> 
> Если кэшировать aptbox после initroot, то
> повторные hsh --initroot занимают там около 2.3 сек.
> 
> Суммарное время пересборки Сизифа при таком кэшировании получается
> примерно на 40 часов меньше, что в теории на нынешнем оборудовании
> могло бы сократить время тестовой пересборки примерно на 15 минут.
> 
> К сожалению, такая оптимизация, будучи реализованной в hasher,
> выглядит как жульничество, поскольку проверки валидности кэша
> нет и не может быть.

Я запушил 1.3.35-alt1-4-gafd5ba4 в hasher.git, можно пробовать.


-- 
ldv

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 801 bytes --]

Re: [devel] overoptimizing hasher

[Igor Vlasenko]

On Thu, Mar 28, 2019 at 02:52:56AM +0300, Dmitry V. Levin wrote:
> Я запушил 1.3.35-alt1-4-gafd5ba4 в hasher.git, можно пробовать.

Спасибо большое, пробую.

-- 

I V

Re: [devel] overoptimizing hasher

[Igor Vlasenko]

On Mon, Mar 25, 2019 at 04:14:09AM +0300, Dmitry V. Levin wrote:
> Тестовая пересборка проводится на снапшоте репозитория,
> что создаёт предпосылки для оптимизации.
> 
> Первый hsh --initroot (без кэша) занимает там около 21 сек,
> повторные (с кэшом) -- около 10.5 сек.
> 
> Если кэшировать aptbox после initroot, то
> повторные hsh --initroot занимают там около 2.3 сек.
> 
> Суммарное время пересборки Сизифа при таком кэшировании получается
> примерно на 40 часов меньше, что в теории на нынешнем оборудовании
> могло бы сократить время тестовой пересборки примерно на 15 минут.

Для меня основное ускорение пересборки получается не из-за
этой экономии в 20 сек. с каждой пересборки,
а из-за того, что схардлинковав эти кеши,
я снижаю потребление hasherом памяти в tmpfs
что позволяет запускать больше пересборок параллельно.

Было: altair с 32 cores, но мог запустить параллельно только
16-24 параллельно работающих hasherов.
Теперь запускаю все 32 hasherа, и еще памяти хватает.
ускорился в 32/24=1.5 - 32/16=2 раза,
в полтора-два раза!
Для beehive такое тоже не помешало бы.

-- 

I V

Re: [devel] overoptimizing hasher

[Anton Farygin]

03.04.2019 0:40, Igor Vlasenko пишет:
> On Mon, Mar 25, 2019 at 04:14:09AM +0300, Dmitry V. Levin wrote:
>> Тестовая пересборка проводится на снапшоте репозитория,
>> что создаёт предпосылки для оптимизации.
>>
>> Первый hsh --initroot (без кэша) занимает там около 21 сек,
>> повторные (с кэшом) -- около 10.5 сек.
>>
>> Если кэшировать aptbox после initroot, то
>> повторные hsh --initroot занимают там около 2.3 сек.
>>
>> Суммарное время пересборки Сизифа при таком кэшировании получается
>> примерно на 40 часов меньше, что в теории на нынешнем оборудовании
>> могло бы сократить время тестовой пересборки примерно на 15 минут.
> Для меня основное ускорение пересборки получается не из-за
> этой экономии в 20 сек. с каждой пересборки,
> а из-за того, что схардлинковав эти кеши,
> я снижаю потребление hasherом памяти в tmpfs
> что позволяет запускать больше пересборок параллельно.
>
> Было: altair с 32 cores, но мог запустить параллельно только
> 16-24 параллельно работающих hasherов.
> Теперь запускаю все 32 hasherа, и еще памяти хватает.
> ускорился в 32/24=1.5 - 32/16=2 раза,
> в полтора-два раза!
> Для beehive такое тоже не помешало бы.
>
А можно просто перейти в hasher root на Optane SSD с петабайтным
ресурсом. Разницы с tmpfs вы не заметите.

https://www.hardwareluxx.ru/index.php/artikel/hardware/storage/44163-intel-optane-ssd-900p-280-gb-3d-xpoint.html?start=2

Re: [devel] overoptimizing hasher

[Igor Vlasenko]

On Wed, Apr 03, 2019 at 07:50:59AM +0300, Anton Farygin wrote:
> А можно просто перейти в hasher root на Optane SSD с петабайтным
> ресурсом. Разницы с tmpfs вы не заметите.
> 
> https://www.hardwareluxx.ru/index.php/artikel/hardware/storage/44163-intel-optane-ssd-900p-280-gb-3d-xpoint.html?start=2

Хорошо бы такое в altair установить.
А то народ пристрастился постоянно держать данные
на altair в оперативке,
что и слишком дорого - хранить в оперативке
обходится в 400 руб/гб,
а не на диске 2 руб/гб,
и не надежно - сервер перезагрузится и все пропадет.

Плюс оперативки на всех не хватит.

Кто такие заявки принимает?

-- 

I V

Re: [devel] overoptimizing hasher

[Anton Farygin]

04.04.2019 18:58, Igor Vlasenko пишет:
> On Wed, Apr 03, 2019 at 07:50:59AM +0300, Anton Farygin wrote:
>> А можно просто перейти в hasher root на Optane SSD с петабайтным
>> ресурсом. Разницы с tmpfs вы не заметите.
>>
>> https://www.hardwareluxx.ru/index.php/artikel/hardware/storage/44163-intel-optane-ssd-900p-280-gb-3d-xpoint.html?start=2
> Хорошо бы такое в altair установить.
> А то народ пристрастился постоянно держать данные
> на altair в оперативке,
> что и слишком дорого - хранить в оперативке
> обходится в 400 руб/гб,
> а не на диске 2 руб/гб,
> и не надежно - сервер перезагрузится и все пропадет.
>
> Плюс оперативки на всех не хватит.
>
> Кто такие заявки принимает?
>
Нужно обратиться к администратору этого сервера. Я не уверен, что во все 
наши сервера можно установить эти платы.

Re: [devel] overoptimizing hasher

[Anton Farygin]

04.04.2019 18:58, Igor Vlasenko пишет:
> On Wed, Apr 03, 2019 at 07:50:59AM +0300, Anton Farygin wrote:
>> А можно просто перейти в hasher root на Optane SSD с петабайтным
>> ресурсом. Разницы с tmpfs вы не заметите.
>>
>> https://www.hardwareluxx.ru/index.php/artikel/hardware/storage/44163-intel-optane-ssd-900p-280-gb-3d-xpoint.html?start=2
> Хорошо бы такое в altair установить.
> А то народ пристрастился постоянно держать данные
> на altair в оперативке,
> что и слишком дорого - хранить в оперативке
> обходится в 400 руб/гб,
> а не на диске 2 руб/гб,
> и не надежно - сервер перезагрузится и все пропадет.
И да, быстрые ssd так же как и оперативка - не предназначены для 
хранения данных.
А где раздают такую серверную дешевую оперативку, по 400 рублей за 
гигабайт ?

Re: [devel] overoptimizing hasher

[Alexey V. Vissarionov]

On 2019-04-04 18:58:48 +0300, Igor Vlasenko wrote:

 >> А можно просто перейти в hasher root на Optane SSD с петабайтным
 >> ресурсом. Разницы с tmpfs вы не заметите.
 > Хорошо бы такое в altair установить. А то народ пристрастился
 > постоянно держать данные на altair в оперативке, что и слишком
 > дорого - хранить в оперативке обходится в 400 руб/гб, а не на
 > диске 2 руб/гб,

Я бы, пожалуй, на такую штуку swap отправил...

 > и не надежно - сервер перезагрузится и все пропадет.

Это не техническая проблема: кладем что-то в tmpfs - принимаем
риск потери этих данных. Такова цена производительности.

 > Плюс оперативки на всех не хватит.

У меня в свое время была мысль сделать накопитель для swap из
старой оперативки (чтобы при каждой загрузке делать там mkswap
и swapon). Посмотрел в сторону ПЛМ. Увидел ценники на готовые
модули поддержки SATA/SAS и DDR2/DDR3. Пришел к выводу, что мне
дешевле выйдет раз в 3...5 лет покупать топовый компутер, под
завязку набитый актуальной на тот момент памятью (сейчас это
была бы плата на X299 с разъемом ЦП LGA2066, куда можно сунуть
i9 7960X и 128 Гб памяти).

Проприетарщики, [тут был мегабайт мата] ...


-- 
Alexey V. Vissarionov
gremlin ПРИ altlinux ТЧК org; +vii-cmiii-ccxxix-lxxix-xlii
GPG: 0D92F19E1C0DC36E27F61A29CD17E2B43D879005 @ hkp://keys.gnupg.net

Re: [devel] overoptimizing hasher

[Igor Zubkov]

On Wed, Apr 3, 2019 at 7:51 AM Anton Farygin wrote:
> А можно просто перейти в hasher root на Optane SSD с петабайтным
> ресурсом. Разницы с tmpfs вы не заметите.
>
> https://www.hardwareluxx.ru/index.php/artikel/hardware/storage/44163-intel-optane-ssd-900p-280-gb-3d-xpoint.html?start=2

https://hard.rozetka.com.ua/ua/intel_ssdpekkw010t8x1/p58440117/#tab=characteristics
Intel 760p m2 по скорости тоже самое (ну почти), а по цене в 4 раза
дешевле. Только m2 нужно на материке.

Или 3D XPoint лучше TLC?

Re: [devel] overoptimizing hasher

[Anton Farygin]

04.04.2019 19:36, Igor Zubkov пишет:
> On Wed, Apr 3, 2019 at 7:51 AM Anton Farygin wrote:
>> А можно просто перейти в hasher root на Optane SSD с петабайтным
>> ресурсом. Разницы с tmpfs вы не заметите.
>>
>> https://www.hardwareluxx.ru/index.php/artikel/hardware/storage/44163-intel-optane-ssd-900p-280-gb-3d-xpoint.html?start=2
> https://hard.rozetka.com.ua/ua/intel_ssdpekkw010t8x1/p58440117/#tab=characteristics
> Intel 760p m2 по скорости тоже самое (ну почти), а по цене в 4 раза
> дешевле. Только m2 нужно на материке.
>
> Или 3D XPoint лучше TLC?
TBW посмотри.
Он на порядки дольше живёт под высокой нагрузкой.

Re: [devel] overoptimizing hasher

[Alexey V. Vissarionov]

On 2019-04-04 19:36:30 +0300, Igor Zubkov wrote:

 >> А можно просто перейти в hasher root на Optane SSD с петабайтным
 >> ресурсом. Разницы с tmpfs вы не заметите.
 > https://hard.rozetka.com.ua/ua/intel_ssdpekkw010t8x1/p58440117/
 > Intel 760p m2 по скорости тоже самое (ну почти), а по цене в
 > 4 раза дешевле. Только m2 нужно на материке.

https://www.aliexpress.com/item/PCI-E-X4-to-M-2/32919838986.html


-- 
Alexey V. Vissarionov
gremlin ПРИ altlinux ТЧК org; +vii-cmiii-ccxxix-lxxix-xlii
GPG: 0D92F19E1C0DC36E27F61A29CD17E2B43D879005 @ hkp://keys.gnupg.net

Re: [devel] overoptimizing hasher

[Anton Farygin]

04.04.2019 19:27, Alexey V. Vissarionov пишет:
> On 2019-04-04 18:58:48 +0300, Igor Vlasenko wrote:
>
>   > Плюс оперативки на всех не хватит.
>
> У меня в свое время была мысль сделать накопитель для swap из
> старой оперативки (чтобы при каждой загрузке делать там mkswap
> и swapon). Посмотрел в сторону ПЛМ. Увидел ценники на готовые
> модули поддержки SATA/SAS и DDR2/DDR3. Пришел к выводу, что мне
> дешевле выйдет раз в 3...5 лет покупать топовый компутер, под
> завязку набитый актуальной на тот момент памятью (сейчас это
> была бы плата на X299 с разъемом ЦП LGA2066, куда можно сунуть
> i9 7960X и 128 Гб памяти).

https://www.ixbt.com/news/2019/04/06/intel-optane-dc-850-2800.html

Вот вам и аппаратный своп. Цена высокая, но дешевле DDR4 прямо заметно. 
Особенно если учесть то, сколько такой памяти можно пихнуть в один сервер.

Re: [devel] overoptimizing hasher

[Yuri Sedunov]

В Сб, 06/04/2019 в 19:35 +0300, Anton Farygin пишет:
> 04.04.2019 19:27, Alexey V. Vissarionov пишет:
> > On 2019-04-04 18:58:48 +0300, Igor Vlasenko wrote:
> > 
> >   > Плюс оперативки на всех не хватит.
> > 
> > У меня в свое время была мысль сделать накопитель для swap из
> > старой оперативки (чтобы при каждой загрузке делать там mkswap
> > и swapon). Посмотрел в сторону ПЛМ. Увидел ценники на готовые
> > модули поддержки SATA/SAS и DDR2/DDR3. Пришел к выводу, что мне
> > дешевле выйдет раз в 3...5 лет покупать топовый компутер, под
> > завязку набитый актуальной на тот момент памятью (сейчас это
> > была бы плата на X299 с разъемом ЦП LGA2066, куда можно сунуть
> > i9 7960X и 128 Гб памяти).
> 
> https://www.ixbt.com/news/2019/04/06/intel-optane-dc-850-2800.html
> 
> Вот вам и аппаратный своп. Цена высокая, но дешевле DDR4 прямо
> заметно. 
> Особенно если учесть то, сколько такой памяти можно пихнуть в один
> сервер.


https://en.wikipedia.org/wiki/NVDIMM


-- 
Yuri N. Sedunov

Re: [devel] overoptimizing hasher

[Anton Farygin]

06.04.2019 20:31, Yuri Sedunov пишет:
> В Сб, 06/04/2019 в 19:35 +0300, Anton Farygin пишет:
>> 04.04.2019 19:27, Alexey V. Vissarionov пишет:
>>> On 2019-04-04 18:58:48 +0300, Igor Vlasenko wrote:
>>>
>>>    > Плюс оперативки на всех не хватит.
>>>
>>> У меня в свое время была мысль сделать накопитель для swap из
>>> старой оперативки (чтобы при каждой загрузке делать там mkswap
>>> и swapon). Посмотрел в сторону ПЛМ. Увидел ценники на готовые
>>> модули поддержки SATA/SAS и DDR2/DDR3. Пришел к выводу, что мне
>>> дешевле выйдет раз в 3...5 лет покупать топовый компутер, под
>>> завязку набитый актуальной на тот момент памятью (сейчас это
>>> была бы плата на X299 с разъемом ЦП LGA2066, куда можно сунуть
>>> i9 7960X и 128 Гб памяти).
>> https://www.ixbt.com/news/2019/04/06/intel-optane-dc-850-2800.html
>>
>> Вот вам и аппаратный своп. Цена высокая, но дешевле DDR4 прямо
>> заметно.
>> Особенно если учесть то, сколько такой памяти можно пихнуть в один
>> сервер.
>
> https://en.wikipedia.org/wiki/NVDIMM
>
>
Там цена намного выше, а не ниже DDR4.