From: Igor Vlasenko <vlasenko@imath.kiev.ua> To: devel@lists.altlinux.org Subject: [devel] Опыты с ускорением и экономией памяти при параллельной пересборке. Date: Tue, 19 Mar 2019 22:31:21 +0200 Message-ID: <20190319203121.GA8755@dad.imath.kiev.ua> (raw) Ускорение и экономия памяти при параллельной пересборке с фиксированным репозиторием. Кому интересен данный текст: Нужна пересборка с большим количеством пакетов (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
next reply other threads:[~2019-03-19 20:31 UTC|newest] Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top 2019-03-19 20:31 Igor Vlasenko [this message] 2019-03-23 10:57 ` Igor Vlasenko 2019-03-25 1:14 ` [devel] overoptimizing hasher Dmitry V. Levin 2019-03-25 4:34 ` Anton Farygin 2019-03-27 23:52 ` Dmitry V. Levin 2019-04-02 21:27 ` Igor Vlasenko 2019-04-02 21:40 ` Igor Vlasenko 2019-04-03 4:50 ` Anton Farygin 2019-04-04 15:58 ` Igor Vlasenko 2019-04-04 16:09 ` Anton Farygin 2019-04-04 16:13 ` Anton Farygin 2019-04-04 16:27 ` Alexey V. Vissarionov 2019-04-06 16:35 ` Anton Farygin 2019-04-06 17:31 ` Yuri Sedunov 2019-04-06 17:39 ` Anton Farygin 2019-04-04 16:36 ` Igor Zubkov 2019-04-04 16:37 ` Anton Farygin 2019-04-04 16:47 ` Alexey V. Vissarionov
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=20190319203121.GA8755@dad.imath.kiev.ua \ --to=vlasenko@imath.kiev.ua \ --cc=devel@lists.altlinux.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: link
ALT Linux Team development discussions This inbox may be cloned and mirrored by anyone: git clone --mirror http://lore.altlinux.org/devel/0 devel/git/0.git # If you have public-inbox 1.1+ installed, you may # initialize and index your mirror using the following commands: public-inbox-init -V2 devel devel/ http://lore.altlinux.org/devel \ devel@altlinux.org devel@altlinux.ru devel@lists.altlinux.org devel@lists.altlinux.ru devel@linux.iplabs.ru mandrake-russian@linuxteam.iplabs.ru sisyphus@linuxteam.iplabs.ru public-inbox-index devel Example config snippet for mirrors. Newsgroup available over NNTP: nntp://lore.altlinux.org/org.altlinux.lists.devel AGPL code for this site: git clone https://public-inbox.org/public-inbox.git