Zrychlení spouštění aplikací a optimalizace pro SSD

[Rover623]

V Linuxu už delší dobu existuje nástroj "preload", který v kostce vlastně nedělá nic jiného než, že analyzuje chování uživatele a předpovídá, které programy by mohl chtít spustit. Části těchto programů potom přednostně nahraje do paměti, aby nebylo nutné je tahat z disku.

Ještě v předposlední LTS (10.04) to fungovalo dost na houby. Ve 12.04 už to funguje o poznání lépe (verze 0.6.4), řekl bych až o dost lépe. Tahle věcička se hodí každému kdo má pomalý disk, má SSD (omezí čtení) nebo provádí častěji rozsáhlé diskové operace na systémovém disku. Instalace je jednoduchá (je to pouze jeden balík)

Kód: [Vybrat]

sudo apt-get install preload
Zároveň je ovšem nutné upozornit, že instalaci nelze doporučit těm kteří mají málo paměti (úplné minimum pro využití jsou 2GB) nebo používají paměťově náročné aplikace. Logicky jednoduše proto, že vám to nahrává do paměti části aplikací o kterých si to myslí, že je budete chtít použít a ta paměť potom samozřejmě chybí.

[TIBOR]

Nepredlzuje to start systemu? Ten uz nieje taky dobry ako v dobe 10.10. Bolo by ho skoda este predlzovat.

[Rover623]

Neprodlužuje a pokud ano, tak neznatelně. Mám pomalý disk a nějak jsem si nevšiml rozdílu v době startu. Sám autor ovšem upozorňuje, že to rozhodně start systému nezrychluje, jen to zrychluje spuštění vybraných programů.

Pro zrychlení startu systému je k dispozici balík "readahead-fedora", ale u toho pozor, protože to vyřadí některé funkce systému během startu a taky to vypne původní optimalizátor startu z Ubuntu.

[beer]

Preload jsem zkoušel, start byl subjektivně o něco málo s SSD diskem pomalejší, u startu aplikací jsem zrychlení nepoznal, spouštějí se mi zpravidla dost rychle i tak.

Ten readahead-fedora neznám, to vyřazení funkcí systému je možné navrátit odinstalací toho balíku? Oproti původnímu optimalizátoru dojde ke zrychlení? Bude fungovat /etc/rc.local?

[Rover623]

Preload ani ten readahead se nikam nezapisují. Teď jsem to vyzkoušel na klasickém SSD a jestli je tam rozdíl ve startu v délce tak 2 vteřin tak je to hodně. Každopádně, značně to omezilo čtení z disku. U SSD to není o zrychlení spuštění programů, ale spíš o tom, že to omezí čtení a to se hodí.

Readahead sice zvedne rychlost startu, na klasickém disku klidně i 10 vteřin, ale za cenu toho, že systém nezapisuje přístupy k souborům bootu. To občas nelibě nesou některé aktualizace. Nedetekuje se HW během startu, vypne se nouzový režim a pár dalších drobností. Pro zapnutí/vypnutí stačí předmětný balík nainstalovat/odebrat, ale v momentě kdy něco selže je konec. Pak je člověk odkázán jen na terminál a hlavně, pokud systém ztratí povědomí o nějakém HW, sám si ho nenajde.

[beer]

Hmm, díky za info. Toho čtení u SSD se nebojím, je dobré eliminovat zbytečné zápisy, ale čtení, to disk (SSD, u HDD to neplatí, tam se přesouvají hlavičky) nijak nepoškozuje, a na mém SSD je již dostatečně rychlé, a to mám jen Sata 2.0, takže nevyužiju plně potenciál SSD s Sata 3.0. Preload má dle mého laického názoru tedy největší efekt na klasickém HDD.

Možná ho ale přece jen opět nainstaluju a zkusím zkombinovat, nyní bootuji na mé staré šunce odhadem kolem 10 vteřin, jestli se to dá nějak stáhnout níž.

[Martin Šácha]

Nejen preloadem ziv je clovek, prelink "prekompiluje" binarky takze se zbytecne nevolaji knihovny ktere nejsou potreba a to zrychluje aplikace... akorat analyza systemu chvilku trva (jednorazova akce)

[Rover623]

Tak o prelinku jsem nevěděl, člověk se pořád učí.

[ETNyx]

ze zkušenosti vím, že prelink není tak úplně nejbezpečnější věc už mi několikrát rozbil systém takže tady opatrně.

[Rover623]

Tak ono asi záleží na celkovém stavu systému. Já mám třeba systém prakticky vždy zaplevelený hromadou PPA třetích stran + vlastních úprav, takže třeba provést úspěšný přechod je u mě z kategorie Sci-fi. Naproti tomu u systému kde byl k dispozici je oficiální repozitář + GetDeb + Medibuntu, prošel přechod z LTS (10.04) na LTS (12.04) naprosto bez potíží.

Při použití takových věcí jako je prelink to bude obdobné.

[Martin Šácha]

Souhlas, prelink uz neni pro BFU, nesmi se v systemu michat 32 a 64bit aplikace ... ale ja s tim problem nikdy nemel

[Rover623]

Tak já mám ve svém systému (12.04 64bit) smíchané kdeco. 32bit ovladače i aplikace třetích stran které jinak než stažením z netu nejsou.

Prelink jsem nainstaloval, spustil s parametry podle helpu a zatím se nic nestalo, vše funguje. Na druhou stranu je fakt, že kdyby něco nevyšlo, tak to bez problémů vrátím, ale pochybuji, že běžný uživatel by něco takového zvládl.

[beer]

Souhlas, prelink uz neni pro BFU, nesmi se v systemu michat 32 a 64bit aplikace ... ale ja s tim problem nikdy nemel

Hmm, takže když používám 64 bit ubuntu a 32 bitový skype a 32 bitový citrix, atd, tak prelink je naprosto nevhodný. Dobré vědět.

[Rover623]

Skypu to nevadí, ale upozorňuji, že pokud se prelink spustí a Skype běží, tak obvykle spadne

[Martin Šácha]

Skypu to nevadí, ale upozorňuji, že pokud se prelink spustí a Skype běží, tak obvykle spadne

Ono vubec to poustet na bezicim systemu je trochu risk... ja to vzdy spoustel pod chrootem z liveusb

[beer]

Skypu to nevadí, ale upozorňuji, že pokud se prelink spustí a Skype běží, tak obvykle spadne

Ono vubec to poustet na bezicim systemu je trochu risk... ja to vzdy spoustel pod chrootem z liveusb

Na druhou stranu, pokud by to bylo tak riskantní, tak by to nemělo defaultní periodicitu 14 dní v souboru /etc/default/prelink.

Viz:
http://wiki.ubuntu.cz/zrychlení_startu_aplikací

Prelink z chrootu by měl význam v případě zakázání periodického prelinkování.

[František Zatloukal]

Systém se dá docela pěkně zrychlit a optimalizovat pro SSD úpravou hodnoty swappiness("agresivita" swapování, čím menší, tím později začne systém zapisovat do swapu, default je 60) v /etc/sysctl.conf . Já používám "10" pro 2GB RAM (na strojích s více RAM swap nepoužívám vůbec).

Pak bych také doporučil pro systémy s větší RAM adresovat /tmp do RAM místo pevného disku.
Toho lze docílit editací /etc/fstab , přidáním na konec souboru:

Kód: [Vybrat]

# Move /tmp to RAM
tmpfs /tmp tmpfs defaults,noexec,nosuid 0 0
Dalšího zrychlení lze docílit další úpravou /etc/fstab. Ta zruší zapisování přístupu k souborům. Je potřeba do sloupce options (za default u každého oddílu) přidat

Kód: [Vybrat]

noatime, nodiratime
Můj /etc/fstab vypadá pak takto:

Kód: [Vybrat]

#
# /etc/fstab
# Created by anaconda on Sun Apr 14 15:33:54 2013
#
# Accessible filesystems, by reference, are maintained under '/dev/disk'
# See man pages fstab(5), findfs(8), mount(8) and/or blkid(8) for more info
#
UUID=32dade96-769d-49fc-84f3-ac1d6ebf304e /                       ext4    defaults,noatime,nodiratime        1 1
UUID=5868c192-9b71-48bd-9aa2-3a9d2bb7e9c9 /boot                   ext4    defaults,noatime,nodiratime        1 2
UUID=87cc0af8-4954-4b2b-8e45-fbe439cc6f8c /home                   ext4    defaults,noatime,nodiratime        1 2
UUID=b9eadf01-19f1-4686-9488-809707490db5 swap                    swap    defaults        0 0
# Move /tmp to RAM
tmpfs /tmp tmpfs defaults,noexec,nosuid 0 0


[Rover623]

Při přemístění TMP do paměti je vhodné ještě použít parametr "size", který specifikuje velikost zabrané paměti. TMP totiž u mě občas nabývá obludných rozměrů a i 16GB RAM by mu občas bylo málo. Jinak pro mount TMP do paměti používám tyhle parametry, jinak se mi občas stávalo, že některé programy to nelibě nesli

Kód: [Vybrat]

defaults,nodev,nosuid,noatime,exec,mode=1777 a pak samozřejmě "size", kde podle počítače (kolik je v něm paměti) specifikuji kolik smí TMP v paměti zabrat.

[ETNyx]

Jsem netušil, že Ubuntu ještě nemá tmp v RAM od instalace. Pokud nevíte jak velké size si nastavit tak nezoufejta a parametr klidně nezadávajte ve většině případů jej není nutné nastavovat (pro pořádek pokud size nenastavíte je použita defaultní hondonta = 1/2 RAM).

Taky přidám pár tipů:
Bohužel ne všechny často používané soubory se uloží do tmp respektivě do RAM. Existují dva pseudo daemoni: Anything sync daemon (ASD) a Profile sync daemon (PSD). PSD je navržen tak aby synchronizoval profily známých webových prohlížečl do RAM (a zpět) a ASD dělá víceméně to samé ale s libvolnou složkou (bez specifik PSD pro prohlížeče). Pokud používáte SSD můžete takto omezit tolikrát propírané opotřebování disku. Případně se hodí tam kde je vysoký load na disky nebo prostě pro zrychlení odezvy systémů.

Když už všechno stěhujeme do RAM tak můžeme mít problém s její velikostí. Chtělo se mi napsat, že není nafukovací ale to není pravda. Hrozně se mi líbí jaderný modul zram s jehož pomocí si můžete vytvořit klasické blokové zařízení naformátovat fs a moutnount do systému a ještě prohnané nějakým kompresním algortmeme. zram spolu s ASD používám na dvouch strojích který mají celkem vysoký load na disky a dělá to divy a ještě jsem si tam navíc rozšíčil RAM díky kompresi o 2GB :-D.

Ještě zpátky k SSD všiml jsem si že tam nikdo nemáte discard pro trim příkaz to už se dneska dělá automaticky bez podpory jadra a fs? Případně máte někdo zkušenost s šifrováním + SSD + trim?

Ještě mně napadl jeden trik jak připadně zvýšit výkon SSD. A to změnou I/O plánovače. Zjednoduším to,.. máme 3 plánovače (cfq, deadline, noop) cfq pracuje na základě priorit, tím si vytváři fronty které případně přerovnáva a tak, deadline vytváři frontu tak že všem dává stejný časový úsek po který může pracovat s diskem a noop pracuje tak že vytváří frontu tak jak jednotlivý požadavky přijdou zasebou. U SSD mají deadline a noop větší výkonnost než cfq, které je dost často defaultní plánovač. U SSD to bude v řádech jednotek % ale lepší něco než nic. (Pozn. tenhle tip se dá použít i u jiných věcech na svém diskovém poli který používám pro zálohu jsem si zvedl výkon v řádech desítek procent,..)

[beer]

@ETNyx
discard používám, bez něj trim v ubuntu nefunguje, používám i ty plánovače, zram nepoužívám - komprese by žrala výkon slabému procesoru, ASD a PSD jsem zatím neřešil, tip jak na ně by se hodil, ram v tmp opravdu není defaultní.

@Rover623
to bobtnání tmp máš i v RAM? Pokud by to bylo někde na disku, tak bych se nedivil, stačilo by, kdyby si OS po sobě v /tmp přestal uklízet.

@František Zatloukal
Noatime je nadmnožinou nodiratime. Pokud používáš noatime, nemusíš explicitně zmiňovat nodiratime, protože je v noatime již zahrnuto. Výchozí v ubuntu je relatime, kdy se zapisuje jen čas modifikace. Noatime a nodiratime bych tedy osobně vůbec neřešil.

[ETNyx]

@beer

PSD funguje tak, že se do RAM nahraje daná složka, té se vytvoří backup pro případ havárie a symbolickým linkem ze z RAM vrátí na původní místo. Pak se jednou za čas dělá synchronizace (1h), interval se dá změnit v cronu nebo systemd timeru

pro ubuntu tu https://launchpad.net/~graysky/+archive/utils. Je potřeba rsync a awk. Je trošku potřeba zkonfiigurovat v /etc/psd.conf

Kód: [Vybrat]

USERS="etnyx"
BROWSERS="firefox"
VOLATILE="/run/shm"
DAEMON_FILE="/var/run/psd"

případnou kontrolu jak je PSD nastaven

Kód: [Vybrat]

[etnyx@etnyx-laptop ~]$ profile-sync-daemon parse

Daemon file /var/run/psd is present.
Service is currently active.

Psd will manage the following per /etc/psd.conf settings:

 browser/psname:  firefox/firefox
 owner/group:     etnyx/users
 sync target:     /home/etnyx/.mozilla/firefox/pxve7rkr.default
 tmpfs dir:       /tmp/etnyx-firefox-pxve7rkr.default
 profile size:    33M

Pokud programu z neoficiálního repozitáře nevěřite můžete si jej sami projít v podstatě je to bash skript a cron (připadně systemd timer).

Jinak ASD a PSD jsou na githubu https://github.com/graysky2/profile-sync-daemon https://github.com/graysky2/anything-sync-daemon

[beer]

@ETNyx, díky za tipy.

[Rover623]

Bobtnání TMP je u mě normální věc, dělám obvykle víc věcí najednou a když se potom sejde vypalování kdy si tam K3B vytváří ISO, editace videa kdy si tam Avidemux odkládá rozbalené části videa a k tomu ještě nějaká kompilace, občas má u mě TMP i přes 20GB. Jasně, když to potom všechno zavřu, mám TMP velikosti třeba 4MB, ale při té největší zátěži by mu v případě umístění v paměti nemuselo stačit ani těch 16GB RAM