Metody na przyspieszenie czasu kompilacji w projekcie za pomocą bitbake?

Pracuję w projekcie, który ma wiele przepisów na bitbake i zajmuje dużo czasu - w niektórych przypadkach do 13 godzin. Jestem nowy w bitbake i proszę o jakiś sposób:

  • sprawdź, jakie pakiety potrzebują więcej do zbudowania
  • sprawdzanie bardzo długich zależności (użyłem już bitbake-g)
  • sprawdź, czy istnieją jakieś kołowe zależności i jak je rozwiązać
  • sprawdź, czy istnieją przepisy, które nie są używane i jak je bezpiecznie usunąć

Lub wszelkie sugestie za korzystanie z wszelkich narzędzi do lepszego zarządzania i zrozumienia receptur.

Lub jakiekolwiek metody / sposoby na przyspieszenie procesu budowania w ogóle.

Zarówno sugestie, jak i dokładne techniki są mile widziane.

Data edycji 07/08/2013:

Znaleziono przydatne narzędzie do śledzenia zależności

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

Opis: 

./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.
Author: Neaţu Ovidiu Gabriel, 2013-08-06
Source

2 answers

To bardzo szerokie pytanie!

Po pierwsze, oto podsumowanie, jak sprawdzić wydajność kompilacji i zależności podczas korzystania z projektu openembedded / yocto. To odpowiada na pierwszą część pytania.

Jakie pakiety zajmują więcej czasu?

Użyj buildstats z narzędziem pybootchartgui Utwórz wykres budowy.

Szczegóły:

Ustaw USER_CLASSES += "buildstats" w swoim $BUILDIR/conf/local.conf plik. Spowoduje to zrzucenie szczegółowych danych o wydajności w $BUILDDIR/tmp/buildstats/<DATE>. Następnie Użyj skryptu pybootchartgui.py (w poky/scripts/pybootchartgui) do wygenerowania wykresu. To ci pomoże zlokalizuj ewentualne wąskie gardła w kompilacji. Oczywiście, jeśli masz wiele przepisów do pieczenia, Twój wykres będzie ogromny. Aby usunąć trochę hałasu użyj opcji linii poleceń -m MINTIME.

Na przykład: 

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

Wyświetli tylko zadania (do_compile, do_fetch, itd.), które trwają dłużej ponad 10 minut (600 sekund) do uruchomienia.

Jak sprawdzić zależności pakietów?

Aby zbadać zależności danego pakietu korzystają z depexp użyteczność. Na przykład, aby zbadać zależności eglibc użyj: 

bitbake -g -u depexp eglibc
To da lepsze zrozumienie, od czego zależy każdy przepis zarówno podczas uruchamiania, jak i kompilacji.

Jak sprawdzić, czy istnieją jakieś kołowe zależności i jak je rozwiązać?

Bitbake automatycznie wykrywa kołowe zależności i wyświetla komunikat o błędzie, gdy coś takiego się stanie. Komunikat o błędzie zawiera nazwę pakietów wywołując tę kołową zależność.

Jak sprawdzić, czy istnieją przepisy, które nie są używane i jak bezpiecznie je usunąć?

Bitbake oblicza zależności automatycznie i nie będzie budować pakiety, które nie są potrzebne celowi. Jeśli znajdziesz niechciane pakiety w obrazie i chcesz je usunąć:

  1. użyj bitbake -g -u depexp <TARGET>, aby sprawdzić, jak pakiet zostanie wciągnięty
  2. zmodyfikuj potrzebne przepisy w warstwie (na przykład tworząc bbappend), aby wyeliminuj zależność ręcznie

Poprawa ogólnej wydajności kompilacji

Na koniec kilka wskazówek, jak poprawić ogólną wydajność kompilacji. To odpowiada na drugą część pytania.

  • oczyść swoje zależności (bitbake -g -u depexp <TARGET> jest twoim przyjacielem). Budowanie mniej rzeczy zajmuje mniej czasu.
  • bitbake może automatycznie buforować wyjścia kompilacji i używać ich do przyszłych kompilacji, ta pamięć podręczna nazywa się" shared-state cache " i jest kontrolowane za pomocą SSTATE_DIR zmienna w twoim local.conf.
  • Ustaw zmienne BB_NUMBER_THREADS i PARALLEL_MAKE w twoim local.conf, aby pasowały do twojego zasoby maszyny. Te zmienne kontrolują, ile zadań jest uruchamianych równolegle i ile procesów 'make' powinno działać równolegle (-j opcja).
  • umieść katalog 'build' na własnym dysku.
  • Użyj systemu plików ext4 bez i z tymi montowaniem opcje: noatime,barrier=0,commit=6000. WARNING : This makes your dysk twardy zawodny w przypadku zasilania straty. Nie przechowywać niczego z wartość na tym dysku twardym.
  • budowanie obrazów za pomocą -dev i/lub -dbg pakietów zwiększa do_rootfs czas zadania znacznie. Upewnij się, że je włączyłeś (zobacz EXTRA_IMAGE_FEATURES w Twoim local.conf) tylko w razie potrzeby.
    • Openembedded i yocto wspierają icecream (distributed compile). Zobacz klasę icecc i ten post .
  • kup szybszą maszynę;)

Bibliografia:

Yocto Build Performance Wiki

Bitbake GUI tools

 15
Author: bookmarc,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2017-05-23 12:34:47

Próbowałem distributed compile way lata temu ,ale konfiguracja środowiska serwerowego nie jest tak elastyczna dla pracy agenta CI ,a kompilacja nie jest odpowiednia dla muti-ludzi .

Próbowałem analizować czas budowy z buildstats , i znalazłem czas kompilacji jest prawie cały koszt kompilacji 3-rd party opensource komponenty, których w ogóle nie zmodyfikowałem.

Więc najprostszym i najskuteczniejszym sposobem jest użycie "sstate-cache", aby uniknąć niezmodyfikowanego komponenty do ponownego zbudowania.

Sposób, w jaki używam w mojej pracy, to wymiana przestrzeni na czas

  1. Skompilować cały projekt bitbake, można znaleźć wiele .pliki tgz pod "build/sstate-cache"

  2. Dodaj i zatwierdź wszystkie te pliki do git w celu śledzenia modyfikacji pliku

  3. Skompiluj cały projekt ponownie bez czyszczenia

  4. Cd do twojego "build / sstate-cache", stanu git i znalazł pliki, które są modified, delete them and commit to git

  5. Następnie czysty projekt bez .tgzs pod "sstate-cache", Wymiana przestrzeni na czas odbywa się

Lista "niezmodyfikowanych" plików może zostać zmodyfikowana zgodnie z twoim własnym projektem .

Czas budowy jest dla mnie zredukowany z 1 godziny do 10 minut

Hope this would be helpful

 1
Author: butter,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2017-05-23 12:18:21