Triky na zvýšenie rýchlosti portage portage

13.3.2009 17:00 | Přečteno: 1625× | Linux | | poslední úprava: 13.3.2009 16:42

Portage na rozidel od väčšiny balíčkovacích systémov nepoužíva žiadnu databázu balíkov. Informácie sú tu roztrúsene v drobných nekomprimovaných textových súboroch. Týchto súborov je štandardne > 100 000 (nie, nepomýlil som si počet núl). Na jednej strane je pridávanie vlastných balíkov do portage veľmi jednoduché a bezbolestné. Načítavanie takého množstva súborov už také ideálne nie je (ak teda nemáme SSD disk). Našťastie existuje riešenie ako tieto obmedzenia (za cenu drobného kompromisu) obísť.

Rýchle vyhľadávanie balíkov pomocou eix

• Obtiažnosť - veľmi jednoduché
• Bezpečnosť - bezpečné (nemá sa čo pokaziť)

Nástroj eix umožňuje veľmi rýchle vyhľadávanie v balíkoch. Informácie o balíkoch sú podrobnejšie než tie, ktoré poskytuje emerge.

Inštalácia je veľmi jednoduchá, stačí nainštalovať nástroj eix a spustiť update-eix. Databáza eix sa neaktualizuje automaticky pri synchronizácii (emerge --sync) preto je nutné po každej synchronizácii spustiť update-eix. Aby sme nemuseli zadávať zasebou emerge --sync a update-eix existuje príkaz eix-sync, ktorý spustí emerge --sync a update-eix a po synchronizácii zobrazí prehľadný zoznam zmien balíkov.

Paralelné sťahovanie balíkov

• Obtiažnosť - veľmi jednoduché
• Bezpečnosť - bezpečné

Portage umožňuje paralelné sťahovanie počas kompilácie. Pre zapnutie paralelného sťahovania stačí editovať súbor /etc/make.conf a do premennej FEATURES pridať voľbu parallel-fetch. Odteraz sa budú súbory sťahovať počas kompilácie.

Pokračovanie v inštalácii pri výskyte chyby

• Obtiažnosť - jednoduché
• Bezpečnosť - vyžaduje nestabilné portage (môžu nastať problémy)

Toto na prvý pohľad nemá s rýchlosťou moc spoločného. Ak ale nechávate emerge bežať v noci a kompilácia padne pri druhom balíku môže táto technika ušetriť aj niekoľko dní.

Prvé čo musíme urobiť je inštalácia portage 2.2. Pred inštaláciou je nutné nové portage odmaskovať (pridať sys-apps/portage-2.2* do /etc/portage/package.unmask a sys-apps/portage ~architektúra do /etc/portage/package.keywords). Po inštalácii stačí pri pri použití emerge pridať voľbu --keep-going. Ak ste rovnako leniví ako ja pravdepodobne sa vám to nebude chcieť písať pri každom použití emerge. Práve pre takéto prípady existuje premenná EMERGE_DEFAULT_OPTS v /etc/make.conf. Moja EMERGE_DEFAULT_OPTS vyzerá takto:

EMERGE_DEFAULT_OPTS="--keep-going"

Využitie rýchleho filesystému na portage

• Obtiažnosť - pomerne zložité
• Bezpečnosť - pri nepozornosti môže dôjsť k poškodeniu systému (nič čo by pokročilý užívateľ nevedel opraviť)

Liekom na pomalé portage môže byť presun /usr/portage na rýchlejší filesystém. Nebudem tu rozoberať veľké množstvo filesystémov vhodných na tieto účely (napr. rôzne komprimované filesystémy) alebo písať o tom, ako optimalizovať „bežné” filesystémy na rýchlu prácu s veľkým množstvom malých súborov. Namiesto toho popíšem jedno konkrétne riešenie využívajúce read only filesystém (squashfs).

Squashfs je komprimovaný filesystém používaný prevažne u live linuxov. Kompresný pomer nie je síce najlepší, ale zato kompresia je rýchla. U mňa sa portage zredukovalo z 555 MB na 46 MB (čo je pri danej rýchlosti kompresie slušná hodnota). Rýchlosť prístupu k súborom je u squashfs výrazne vyššia než u väčšiny bežných filesystémov. Istým problémom môže byť to, že je iba read only (i keď pri istých kompromisoch nie je tento problém neprekonateľný).

V linuxe existuje niekoľko filesystémov ktoré ktoré dokážu pracovať s pripojeným read only filesystémom ako keby bol zapisovateľný. Tieto filesystémy sú napr. unionfs, fsunionfs, alebo aufs. Unionfs je je trochu zastaralý, jeho náhradou je fsunionfs (unionfs pre FUSE). V podstate môžeme vybrať ktorýkoľvek z týchto filesystémov, ja som sa rozhodol pre aufs z overlaya sunrise.

Pre tých ktorí ešte nepoužívali overlaye odporúčam pozrieť si nástroj layman.

Prvá vec ktorú by sme mali urobiť je presun adresára /usr/portage/distfiles na iné miesto (výber ponechám na vás). Po presune na iné miesto upravíme /etc/make.conf a špecifikujeme nové umiestnenie adresára distfiles.

DISTDIR="nové umiestnenie distfiles"

Ďalej si z tejto stránky stiahneme súbor initscripts.tar.gz a rozbalíme súbor init.d/squash_dir do /etc/init.d. Tento súbor premenujeme na squash a z neho urobíme odkaz na /etc/init.d/squash_portage (ak ste si istí, že nechcete používať iný adresár okrem portage pre squashfs môžete priamo tento súbor pomenovať /etc/init.d/squash_portage). Názov súboru squash_adresár nie je povinný, dané pomenovanie som zvolil len pre zvýšenie prehľadnosti.

Teraz vytvoríme súbor /etc/conf.d/squash_portage s takýmto obsahom:

DIRECTORY="/usr/portage"
DIR_CHANGE="/tmp/portage"
DIR_SQUASH="/tmp/portage_ro"
VERBOSE_MODE=1

V premennej DIRECTORY je adresár ktorý chceme chceme dať do squashfs. V DIR_CHANGE je adresár kde sa ukladajú zmeny (keďže samotný squashfs je read only). Adresár môže sa môže nachádzať v ramdisku (ak chceme maximálny výkon). Do adresára DIR_SQUASH sa pripája read only časť portage. Ak chceme pri odpájaní vidieť progress bar môžeme zapnúť voľbu VERBOSE_MODE [na to je potrebný patch, ktorý je v adresári squash_dir_utils (z rovnakého archívu v ktorom sa nachádzal init skript)]. Modifikácia ebuildu nie je nič zložité.

Teraz už je všetko nakonfigurované a môžeme smelo spustiť /etc/init.d/squash_portage start. Pri pokuse o prvý štart nám init skript vypíše chybu (keďže zatiaľ nemáme vytvorený súbor so squashfs). Okrem chybovej hlášky rovno ponúka aj riešenie.

squash_portage    |* You must create /usr/portage.sqfs first. Use e.g.
squash_portage    |* mksquashfs '/usr/portage' '/usr/portage.sqfs'
squash_portage    |*    && chmod 644 '/usr/portage.sqfs'
squash_portage    |*    && rm -rf -- '/usr/portage'                   [ !! ]
squash_portage    |* ERROR: squash_portage failed to start

Takže už stačí len systémom copy & paste vytvoriť /usr/portage.sqfs a naštartovať službu /etc/init.d/squash_portage start.

Pre zápis zmien portage stačí reštartovať službu squash_portage (/etc/init.d/squash_portage restart). Ak nedošlo k modifikácii reštart bude takme okamžitý. V opačnom prípade to bude pár sekúnd trvať (v žiadnom prípade nie tak dlho ako prvé vytvorenie portage.sqfs z celého adresára /usr/portage).

Podrobnosti môžete nájsť v pôvodnom vlákne na gentoo fóre.

Na záver ešte spomeniem, že okrem samotného portage je možné urýchliť aj kompiláciu balíkov (pomocou ccache, alebo distcc). Medzi optimalizačné techniky patrí aj confcache (to je ale oproti predchádzajúcim nástrojom veľmi nespoľahlivé).

Ak máte ďalšie nápady ako zrýchliť portage napíšte prosím postup do diskusie.

       

Komentáře

[David Watzke]

--keep-going pro Paludis

export PALUDIS_OPTIONS="--continue-on-failure if-satisfied"

Jinak osobně doporučuju zvážit použití rsync_excludes. Prostě si vytvoříte soubor s názvy kategorií balíků, které nepoužíváte a ty se při synchronizaci vynechají. Stačí rsyncu předat --exclude-from. Já jsem tohle zatáhl trochu do extrému a vytvořil jsem si seznam balíků co používám a zbytek ignoruju - do konfiguráku gentoo.conf jsem přidal:

sync_options = --rsync-option=--prune-empty-dirs --rsync-option=--include-from=/etc/paludis/rsync_includes --exclude=*

a soubor /etc/paludis/rsync_includes patřičně naplnil (nezapomenout na metadata!)... ukázka:

app-cdr/                                                                             
app-cdr/cdrdao/                                                                      
app-cdr/cdrdao/**
metadata/
metadata/*
metadata/cache/
metadata/cache/*
metadata/cache/app-cdr/
metadata/cache/app-cdr/cdrdao-*

Problém je, že když pak člověk chce nainstalovat něco novýho tak to holt musí přidat a synchronizovat znova. Výhoda je tak 10x menší strom. Takže se to hodí spíš na nějaký mini systémy.

[Scarabeus IV]

Jenom aby se nezapomelo tak portage umi taky sincovat jen cast stromu. Je to v manu tak si to najdete ;]

[CET]

--keep-going pro stable  portage:

if ! emerge -uvDN world;then while ! emerge --resume --skipfirst;do true;done;fi

[Marián Kyral]

Nestabilní portage už používám opravdu hodně dlouho a na problémy jsem nenarazil. Ale to neznamená, že žádné nejsou

Squashfs vypadá zajímavě. Asi se do toho brzo pustím. Se 4GB RAM by ramdisk neměl být problém

[mirec]

No vzhľadom na to, že sa tam ukladajú len zmeny by nemal byť problém ani 512MB.

[Marián Kyral]

A vyplatí se ten ramdisk, když těch změn nebude moc?

[mirec]

No práve som synchronizoval s ramdiskom, vidím, že mi to zožralo 11MB a pri synchronizácii som nevidel žiadnu činnosť disku. Určite to spôsobí mierne zrýchlenie ale pravdu povediac aj tak ma teraz brzdí hlavne server s ktorým synchronizujem.

[Marián Kyral]

Tak jsem zkompiloval aufs ale modprobe aufs skončil s chybou. Asi bude třeba ještě nějaká volba v kernelu (gentoo-sources), ale v dokumentaci o tom nic není, google zatím nepomohl.

Nechal jsem default USE flagy - jen kernel_linux

aufs: Unknown symbol security_inode_permission

[Marián Kyral]

Aha, aufs opatchoval aktuální kernel, takže ho musím znova přeložit, pak by to mělo fungovat.

[Marián Kyral]

Příloha:

• squashfs-tools-3.4-progress-stderr.patch (684 bytů)

Takže hotovo (zatím bez ramdisku).

Trochu problém byl s instalací aufs, takže přidám postup, třeba se to někomu bude hodit:

• layman -a sunrise
• emerge -av aufs squashfs-utils
• aufs opatchuje jádro, takže je třeba jej znovu přeložit. Při té příležitosti doporučuji kouknout do sekce "File systems" a povolit squashfs, ať to nemusíte dělat dvakrát jako já
• Znova přeložíme moduly: emerge -1 @module-rebuild
• Pak dle návodu, nicméně místo rm -rf -- '/usr/portage'" doporučuji spíše přejmenování a smazat až je vše hotovo

/usr/portage se smrsklo ze 607 MB na 46MB a /usr/local/portage/layman se smrskl ze 130MB na 19MB. Po prvním update měly rw adresáře 23 a 43 MB.

Patch na verbose mode jsem musel aplikovat ručně, protože verze 3.3 nepasuje na squashfs-tools-3.4. Aktualizovaný patch je v příloze, ale už jsem jej zaslal autorovi, takže se snad brzy objeví aktualizovaná verze initscripts.

[Marián Kyral]

...squashfs-tools tam má být

 

[mirec]

To s tým premenovaním je asi lepšie riešenie (tiež som tak pre istotu postupoval). Mimochodom /usr/local/portage je nejaké veľké, ja tam mám pár vlastných ebuildov ale do takého štádia som ešte nedospel ;)

[mirec]

Jaj ja som blbec, to je layman .. ja mam laymana priamo v /usr/portage/local/layman .. to bude asi tým, automaticky som predpokladal, že v /usr/local/portage sú vlastné ebuildy ;)

[Marián Kyral]

Novější verze laymana se už instalují do /usr/local/portage.

[CET]

K rychlosti FS. Mel jsem /usr/portage spolecne na root oddilu (asi 16GB na jednom kompu, na druhym to bylo na disku 150GB). Bylo to pomaly. Tak jsem udelal specialni LV oddil jenom pro /usr/portage, pak dalsi pro /var/db a dalsi pro /var/cache/edb (velikosti jen o trosku vic, nez bylo obsazene misto). update-eix je ted o dost rychlejsi, tak bych rekl, ze i emerge bude.

IMHO to nemusi byt primo nejaky super-rychly FS, ale staci, aby na tom FS byly pouze tyhle data, aby system prochazel jenom ty data, ktery prochazet ma a nemusel se starat o dalsi struktury s celym systemem.

[Semo]

emerge bude rychlejsi, ale kompilacia nie. Takze iba hladanie zavislosti. Na kompilaciu vraj pomaha tmpfs na /var/tmp/portage.

Mam uz asi 2 roky portage a /var/cache/edb na loopdevice, aby som ich udrzal blizko seba a disk nemusel seekovat po celej sirke. Obcas pomaha to skopirovat mimo a naspat. Len touto operaciou som znizil zaplnenie loopu z 85% na 40%. Zjavne struktury reiserfs casom bobtnaju.

[Marián Kyral]

 

emerge bude rychlejsi, ale kompilacia nie. Takze iba hladanie zavislosti.

To mi stačí. U kompilace záleží na rychlosti procesoru, disku a velikosti paměti. A kompilace může klidně bežet i přes noc.

Na kompilaciu vraj pomaha tmpfs na /var/tmp/portage.

 

Jen si pak musí člověk dát pozor aby nekompiloval openoffice. Ale dneska se dá do počítače narvat i 8GB ram, to by možná šlo. A chtěl bych to pak vidět

[Marián Kyral]

Tak jsem to zkusil s dvougigovým tmpfs a nestačilo to ani na kdelibs-4.2.1

Nějaké zrychlení jsem pozoroval, ale nebylo to nic závratného. Taky jsem si vytipoval dalšího kandidáta na squashfs. Adresář /usr/include má 325MB a skoro 46 tisíc souborů. Squash soubor má 26MB. Jen je to mnohem nebezpečnější, pokud člověk přijde o změny v tmpfs, tak může v lepším případě kompilovat jen pár balíků, v tom horším celý systém

[zippy]

my sme sa tomu na fakulte troska venovali, a toto z toho vypadlo:

http://www.fit.vutbr.cz/study/DP/BP.php?id=6209&y=2007