Методы ускорения времени сборки в проекте с помощью bitbake?

Я работаю над проектом, в котором есть много рецептов битбейков, и это занимает много времени - в некоторых случаях до 13 часов. Я новичок в bitbake, и я прошу какой-нибудь способ:

  • проверить, какие пакеты занимают больше времени для сборки
  • проверить очень длинные зависимости (я уже использовал bitbake -g)
  • проверьте, есть ли круговые зависимости и как их решить
  • проверить, есть ли рецепты, которые не используются, и как их безопасно удалить

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

Или любые методы/способы ускорения процесса сборки в целом.

Приветствуются как предложения, так и точные методы.

ДАТА ИЗМЕНЕНИЯ 08.07.2013:

Нашел этот полезный инструмент для отслеживания зависимостей

https://github.com/scottellis/oe-deptools

Описание:

./oey.py -h

Usage: ./oey.py [options] [package]

Displays OE build dependencies for a given package or recipe.
Uses the pn-depends.dot file for its raw data.
Generate a pn-depends.dot file by running bitbake -g <recipe>.

Options:
-h      Show this help message and exit
-v      Show error messages such as recursive dependencies
-r      Show reverse dependencies, i.e. packages dependent on package
-f      Flat output instead of default tree output
-d <depth>      Maximum depth to follow dependencies, default and max is 10
-s      Show child package dependencies that are already listed
        as direct parent dependencies.

Provide a package name from the generated pn-depends.dot file.
Run the program without a package name to get a list of
available package names.

python openembedded build bitbake embedded
person Neaţu Ovidiu Gabriel    schedule 06.08.2013    source источник

Ответы (2)


arrow_upward
25
arrow_downward

Это очень широкий вопрос!

Во-первых, вот краткое изложение того, как проверить производительность сборки и зависимости при использовании проекта openembedded/yocto. Это отвечает на первую часть вопроса.

Сборка каких пакетов занимает больше времени?

Используйте buildstats с инструментом pybootchartgui для создания диаграммы сборки.

Подробности:

Установите USER_CLASSES += "buildstats" в файле $BUILDIR/conf/local.conf. Это приведет к сбросу подробных данных о производительности в $BUILDDIR/tmp/buildstats/<DATE>. Затем используйте скрипт pybootchartgui.py (в poky/scripts/pybootchartgui) для создания диаграммы. Это поможет вам локализовать возможные узкие места в сборке. Конечно, если у вас много рецептов выпечки, ваша таблица будет огромной. Чтобы убрать шум, используйте параметр командной строки -m MINTIME.

Например:

poky/scripts/pybootchartgui/pybootchartgui.py -m 600 $BUILDDIR/tmp/buildstats/201312310904

будут отображаться только те задачи (do_compile, do_fetch и т. д.), выполнение которых занимает более 10 минут (600 секунд).

Как проверить зависимости пакетов?

Для изучения зависимостей конкретного пакета используйте утилиту depexp. Например, для изучения зависимостей eglibc используйте:

bitbake -g -u depexp eglibc

Это даст лучшее понимание того, от чего зависит каждый рецепт как во время выполнения, так и во время компиляции.

Как проверить, есть ли круговые зависимости и как их решить?

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

Как проверить, есть ли рецепты, которые не используются, и как их безопасно удалить?

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

  1. используйте bitbake -g -u depexp <TARGET>, чтобы проверить, как пакет втягивается
  2. измените необходимые рецепты в вашем слое (например, создав bbappend), чтобы устранить зависимость вручную

Улучшение общей производительности сборки

Наконец, несколько советов о том, как улучшить общую производительность сборки. Это отвечает на вторую часть вопроса.

  • Очистите свои зависимости (bitbake -g -u depexp <TARGET> — ваш друг). Создание меньшего количества вещей занимает меньше времени.
  • Bitbake может автоматически кэшировать выходные данные сборки и использовать их для будущих сборок, этот кеш называется «кэш общего состояния» и управляется переменной SSTATE_DIR в файле local.conf.
  • Установите переменные BB_NUMBER_THREADS и PARALLEL_MAKE в local.conf в соответствии с ресурсами вашей машины. Эти переменные управляют тем, сколько задач выполняется параллельно и сколько процессов make должны выполняться параллельно (опция -j) соответственно.
  • Поместите каталог build на отдельный диск.
  • Используйте файловую систему ext4 без журналирования и со следующими параметрами монтирования: noatime,barrier=0,commit=6000. ВНИМАНИЕ: это делает ваш жесткий диск ненадежным в случае потери питания. Не храните на этом жестком диске ничего ценного.
  • создание образов с пакетами -dev и/или -dbg значительно увеличивает время выполнения задачи do_rootfs. Убедитесь, что вы включили их (см. EXTRA_IMAGE_FEATURES в local.conf) только при необходимости.
  • openembedded и yocto поддерживают icecream (распределенный компилятор). См. класс icecc и этот сообщение.
  • Купите более быструю машину ;)

Рекомендации:

Вики Yocto Build Performance

Инструменты Bitbake с графическим интерфейсом

person bookmarc    schedule 31.12.2013
comment
pybootchartgui в порядке, но я обнаружил, что ElectricInsight создает визуализацию bitbake, которую намного проще понять и использовать (отказ от ответственности: я разрабатываю ElectricInsight) - person Eric Melski; 05.02.2014
comment
depexp был переименован в taskexp в новых версиях: bitbake -g -u taskexp <TARGET> - person Leistungsabfall; 10.01.2018

arrow_upward
4
arrow_downward

Я пробовал способ распределенной компиляции несколько лет назад, но конфигурация серверной среды не такая гибкая для работы агента CI, и сборка не подходит для мути-людей.

Я попытался проанализировать время сборки с помощью buildstats и обнаружил, что время сборки составляет почти все стоило компиляции сторонних компонентов с открытым исходным кодом, которые я вообще не модифицировал.

Итак, самый простой и эффективный способ — использовать sstate-cache, чтобы избежать повторной сборки немодифицированных компонентов.

Я использую в своей работе способ обмена места на время

  1. Скомпилируйте весь проект bitbake, вы можете найти много файлов .tgz в build/sstate-cache.

  2. Добавьте и зафиксируйте все эти файлы в git для отслеживания модификации файла.

  3. Скомпилируйте весь проект еще раз, не очищая его.

  4. cd к вашему build/sstate-cache, статусу git и найденным файлам, которые были изменены, удалите их и зафиксируйте в git

  5. Затем очистите проект без .tgzs под sstate-cache , обмен места на время выполнен

Список немодифицированных файлов может быть изменен в соответствии с вашим собственным проектом.

Время сборки для меня сократилось с 1 часа до 10 минут

Надеюсь, это будет полезно

person butter    schedule 07.08.2015
comment
Не могли бы вы объяснить на высоком уровне, как это предотвращает компиляцию стороннего программного обеспечения? - person eis; 03.02.2016
comment
Проект oe-bitbake часто содержит инструменты среды сборки, которые компилируются при первой сборке всего проекта. что разумно рассматривать с различными средами разработчиков, но для самих разработчиков нам не нужно каждый раз компилировать инструменты. Таким образом, мы могли бы использовать sstate-кэш, который кэширует инструменты и немодифицированное стороннее программное обеспечение, найдите время для компиляции реального кода. Идея пришла со второго раза время компиляции уменьшить, протекторное пространство для экономии времени - person butter; 07.05.2016
comment
Не слишком увлекаюсь идеей хранения всех этих двоичных файлов в git... лучше надеюсь, что вы используете LFS - person austinmarton; 30.04.2018
comment
Вы можете использовать SSTATE_MIRRORS для хранения готового sstate за пределами вашего репозитория, возможно, в месте, доступном для нескольких людей. Задачи setscene будут скопированы из SSTATE_MIRRORS в ваш локальный SSTATE_DIR. - person jpkotta; 24.05.2019