Fórum Root.cz
Hlavní témata => Distribuce => Téma založeno: já 08. 03. 2014, 21:53:04
-
Vyzkoušel jsem si nainstalovat gentoo na ITX desku která má jenom 1GB RAM. Nainstalovalo se to v pohodě, všechno zdá se funguje ale narazil jsem na problém, se kterým si nevím rady.
Když jsem instaloval eclipse podle tohodle návodu https://wiki.gentoo.org/wiki/EclipseSDK, tak jsem se setkal se situací, kdy pro kompilaci jednoho balíčku nestačila RAM, chtělo to něco kolem jeden a půl giga. Tohle ale byla věc kterou jsem tušil a měl jsem připravený dvougigový swap oddíl. Zdá se ale že ho to emerge při kompilaci balíčků defaultně nevyužívá a já nevím jak to aktivovat, jestli to vůbec jde.
-
Co vypíše následující příkaz?
/sbin/swapon -s
-
Ja se s tim setkal u open-office - ale ne kvuli pameti samotne, ale kvuli tomu, ze jsem mel work directory pro portage v RAM. Ostatne zadna kompilace by nemela vyzadovat 1G pro kompilaci nebo linkovani jednotliveho souboru. Nepomohlo by vam snizeni paralelismum, napr. -j1 ?
-
to jste jeste asi neprekladal libreoffice, llvm a nebo Boost ..
-
Swap na disku je absolutne nepouzitelny pre zataze kde working set procesu je zhruba rovnaky ako fyzicka pamat (co je pripad takychto kompilacii) lebo disk je jednoducho prilis pomaly, SSD je trochu lepsi ale zas sa pri tom nici. Odporucam miesto toho pouzit zram - komprimovany swap v pamati: http://wiki.gentoo.org/wiki/Zram Vedel som s nim v pohode s -O2 skompilovat boost a podobne aj na 512M RAM (na x86, na 64bit treba viac) a ide to pomalsie, ale ide.
Okrem toho existuje aj cleancache+frontswap co toho vie viac ale vyzera ze ma vykonnostne regresie, aspon mimo x86 architektur.
-
pripadne instalovat dev-util/eclipse-sdk-bin z java-overlay
-
Swap sa používa až keď nie je voľná RAM."
mimochodom, výber technológie swap-u závisí aj od plánovaného vyťaženia stroja. Práca s skomprimovanými údajmi (strih filmov) v kombinácii s zram nedáva zmysel. A zram nie vždy pomôže pri kompilácii. Napríklad linkovanie firefoxu mi na 1G RAM išlo pomalšie s pomocou zram ako s nekomprimovaným wapom v súbore.
-
praveze teraz som si pozrel navod podla ktoreho to JA robil a tam sa spomina binarny balik takze asi nepojde o kompilaciu. len netusim co moze zozrat RAM pri rozbaleni binarneho balika.
-
Odporucam miesto toho pouzit zram - komprimovany swap v pamati: http://wiki.gentoo.org/wiki/Zram
No to dá rozum - když mám málo paměti, tak jí ještě část nesmyslně promrdám na swap. Tuhle kravinu zkoušelo spousta lidí na Androidu se závěrem, že to je celé na velké hnědé mazlavé.
-
Asi bych zacal nastavenim compile flagu "-j 1" :)
-
Odporucam miesto toho pouzit zram - komprimovany swap v pamati: http://wiki.gentoo.org/wiki/Zram
No to dá rozum - když mám málo paměti, tak jí ještě část nesmyslně promrdám na swap. Tuhle kravinu zkoušelo spousta lidí na Androidu se závěrem, že to je celé na velké hnědé mazlavé.
Pekny FUD :D Nic sa nepremrda, na swap sa pouziva iba tolko RAM kolko je treba na komprimovane data, bezne sa da ocakavat 50% kompresia alebo lepsia. Na Androide je to samozrejme nanic lebo to zerie CPU a spomaluje odozvu na vstup uzivatela, kdezto pri kompilacii na latencii nezalezi.
-
U Libreoffice fungovalo toto:
I_KNOW_WHAT_I_AM_DOING=yes emerge -v libreoffice
Tím se vyřadila kontrola velikosti RAM a Libreoffice se krásně zkompilovaly i na 1GB RAM (v době, kdy požadovaly 1GiB -> v jednotkách mám dodnes hokej, prostě mi free ukazovalo 998MB RAM a LO chtěly víc, selskym rozumem jsem ale ten požadavek splňoval).
Třeba je něco podobnýho i u jiných balíků...