[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