Pomalý disk: univerzální problém

30.8.2006 21:20 | Přečteno: 1473× | Ze života |

V diskusi u zápisu KDE tipy a triky padla stížnost na pomalost diskových operací. Troufám si tvrdit, že právě "rychlost" disků je ta největší brzda dnešních počítačů.

Zatímco rychlost naprosté většiny součástí počítače setrvale roste (i když v poslední době už ne tak závratným tempem), pro pevné disky to tak docela neplatí. I když roste hustota záznamu a tedy i rychlost čtení a zápisu dat, doba na přesun hlav (seek time) zůstává prakticky stejná. Například u disku Hitachi 7K400, patřícího mezi to lepší, co je na trhu, se uvádí průměrný čas přesunu hlavy 8,5 ms. Zhruba na stejné úrovni se tento parametr drží už několik let.

Uvážíme-li, v jakých časových mírách se na dnešních počítačích pohybujeme (že máme např. jiffie 4 ms, průměrné systémové volání trvá řádově mikrosekundy atd.), je doba 8,5 ms nesnesitelně dlouhá. Pak stačí, aby bylo pro start nějakého programu potřeba provést pouhých 100 přesunů hlav a jen tyto přesuny zaberou skoro vteřinu. A to nepočítám další diskové prodlevy.

Proto vyvstává důležitá otázka: jak to vyřešit. Řešení se nabízí celá řada, ale žádné z nich neřeší problém beze zbytku:

• Zlepšení parametrů disků. To by bylo samozřejmě absolutně nejlepší, bohužel nikdo neví, jak na to. Dosud objevená řešení jsou buď drahá nebo ovlivňují další důležité parametry (nejčastěji obojí). Jsem skeptický - asi nezbývá než přejít na jiný způsob záznamu (nejspíš optický) a zcela eliminovat mechanické pohyby hlav.
• Přidání dalších disků. Docela schůdné je vytváření diskových polí (RAID), ale je to řešení hrubou silou a dostaneme se jen o kus dál. Výhodou je, že se zlepší i další parametry, problémem naopak náklady versus spolehlivost (optimální se jeví něco typu 5+1).
• Zvětšení cache disku. Současných 8 MB je spíše pro smích, vzhledem k ceně polovodičových pamětí. Paměť by mohla mít klidně třeba 128 MB, aniž by to znatelně zvedlo cenu. Nepříjemné je, že tato paměť je (z hlediska procesoru) až za vnější sběrnicí, a proto poměrně pomalá.
• Přidání operační paměti. Právě nízká cena pamětí umožňuje osadit si výrazně více paměti, než potřebují aplikace, a využívat ji jako diskovou cache. Zde máme dva problémy - jednak to v praxi znamená nutnost přechodu na 64 bitů (což ještě někdy nejde), a hlavně se tím nevyřeší prvotní načtení dat (totéž platí i pro předchozí řešení).
• Zlepšení filesystému. Protože problémem není ani tak samotné načítání, jako pohyb hlav, nebylo by od věci mít takový souborový systém, který pohyb omezí na nejnutnější úroveň. Problém ale je, že to vyžaduje znalost souvislostí mezi soubory a to už musí řešit nějaká "chytristika" mimo souborový systém. Něco takového existuje ve Windows, i když je sporné, nakolik to pomáhá.
• Omezení fragmentace. Tohle je jednak věc filesystému (pokud možno bránit fragmentaci předrezervací bloků), ale není od věci také explicitní defragmentace. I když se často říká, že linuxové filesystémy (ext2 a ext3) nic takového nepotřebují, často by to pomohlo - hlavně po častějších aktualizacích systému a při používání prelinku.
• Zlepšení plánování I/O. Nápad vychází z toho, že kdyby se bloky načítané z disku vhodně seřadily, nebylo by potřeba tolik pohybů hlav. Jenže je to složitější - už teď máme v jádře několik plánovačů a každý se hodí pro trochu jiné podmínky. Přidáme další, a ten bude opět někdy lepší a někdy horší. Nechci to zatracovat, ale příliš prostoru pro zlepšení tu nevidím.
• Přednačítání dat. Pokud máme volnou paměť, lze v době nečinnosti načítat z disku data, která by mohla být brzy potřeba. To se samozřejmě používá už nyní, ale šlo by jít ještě podstatně dál. Pokud máme třeba 4 GB paměti, aplikace spotřebují 300 MB a disková cache 500 MB, stále zbývá zcela nevyužitých 3,2 GB paměti. Na základě nějaké heuristiky lze pak odhadnout, jaká data (knihovny apod.) by se měla dopředu načíst. Právě kvalita této heuristiky (a její náročnost) je klíčem úspěšnosti takového řešení. Zatím se v GNU/Linuxu používá statické přednačítání, které nijak nereflektuje zvyky a typické chování konkrétního uživatele.
• Využití souborových serverů. Pokud to lze, je docela dobré přenechat přístup k datům serveru, se kterým se bude komunikovat přes rychlou síť. Server může mít hodně fyzické paměti, problém s přechodem na 64 bitů zde není (nemusí se řešit kompatibilita aplikací), lze vytvořit velké rychlé diskové pole atd. Bohužel pro většinu uživatelů je to řešení zcela nedostupné, uplatní se jen ve větších firmách a institucích.

Takže co z toho vyplývá? Moje doporučení zní: používat hodně fyzické paměti, defragmentovat disk, a pokud to lze, zprovoznit výkonný specializovaný souborový server (s RAID) a načítat data (včetně programů) z něj. Případně ještě vyzkoušet různé plánovače I/O a použít ten, který v dané situaci dává nejlepší výsledky (na většině distribucí je default CFQ, což někdy nemusí být ta správná volba). Také by se docela hodil dobrý démon pro přednačítání dat (s vyhodnocováním, co načíst), ale zatím bohužel o žádném takovém nevím.

       

Komentáře

[xxx]

Jak zminujes toho chytrho demona, tak to uz nejakeho chytraka napadlo. Uz nevim na jakem pochybnem ydroji jsem to cet (asi zive.cz). Disk skombinovanej s flashkou (nebo proste disk s mimoradne velkou cache, dovi jak tam na tu flasku prisli :) a super chytrej ovladac do woken, kterej by tam natlacil casto pouzivany data. A jako nevyhoda byla uvedena vysoka cena. Tot vse co si pamatuju

Osobne me tenhle smer vyvoje nebere. Jak pise autor blogpostu, hlavne hodne RAMky a je to. Vzdyt jakou dobu uz si v ni Linux nechava dulezity veci, aby je nemusel znovu nacitat. A nebo proste filesystem v RAMce.

[Luk]

Jenže ono jde také o to (a zmiňuji to tam), že dlouho trvá to první načítání. A funkce toho démona by spočívala v tom, že by zkoumal pravděpodobnost použití určitých dat a ta by přednačetl. Např. nějaké knihovny, konfigurační soubory, ale i spustitelné apod. Takže když někdo krátce po přihlášení do systému často spouští třeba Operu, KDevelop nebo GIMP, démon by je přednačítal. Činil by tak jen v rozsahu volné paměti (s nějakou rezervou) a jen v době, kdy by nezaznamenával v systému žádnou aktivitu (aby nebrzdil běžnou práci).

[Luboš Luňák]

Ta flashka je tam proto, ze neni mechanicka -> nema problemy s vykonem zpusobene presunem ctecich hlav.

[multi]

Když už člověk koupí tak velký ramky tak je snad potřebuje a nebude je mit natolik prázdné aby je ze 2/3 využival jako diskovou flah pamět.
Jinak RAMky se mě zdaj docela drahý, a mam dojem ze je to tim jak se kouká hl. na CPU a na RAMky se zapomíná. Pak se na nich šetří a tak jejich ceny dolu příliš nejdou.
Jinak to přednačítání by se šiklo, ale myslim si že pomalost disků u desktopů neni zas tak velký problém.

[Heron]

Když už člověk koupí tak velký ramky tak je snad potřebuje a nebude je mit natolik prázdné aby je ze 2/3 využival jako diskovou flah pamět.

Člověk, který uvažuje dopředu, si paměti nakoupí víc s tím, že zase tak drahá není a že dostatek RAM se hodí vždy (a to nejen pro diskovou cache). Pokud si budu konečně kupovat new PC, tak pod 2GB nejdu (hloupé je, že kdybych chtěl 4GB, tak si zaplácám všechny paměťový sloty a další zvyšování už nebude možné - jako teď ) Doufám, že si nikdo nenavrhuje PC tak, že si spočítá spotřebu programů a koupí si nejblíže vyšší kapacitu. Takto nastavená paměť mu vydrží tak na půl roku.

[disorder]

ja mam dlhodobo rovnake vyuzitie RAM. preco by som mal pocitat so zvysenim? pred 2 mesiacmi som pridal k 256MB modulu 1GB a neviem co s tym. (bohate by stacil aj 512MB modul, ale pocital som s tym, ze 1GB pojde neskor do novej masiny)

- aby nedoslo k nedorozumeniu, rezerva je dobra - ale 2GB? to je mi nanic, nevyuzijem ani 1GB ked sa snazim :)

[Luk]

aby nedoslo k nedorozumeniu, rezerva je dobra - ale 2GB? to je mi nanic, nevyuzijem ani 1GB ked sa snazim

Tak znovu. Načítání dat z paměti je o několik řádů rychlejší než z disku. Proto čím víc paměti, tím lépe. A osobně bych radši šetřil na procesoru než na paměti. Jen tak pro zajímavost: např. mezi procesory AMD A64 3800+ Venice a AMD A64 4000+ SanDiego je stejný cenový rozdíl, jako mezi 1 GB a 2 GB paměti. Co má větší smysl?

[Kníže Ignor]

Naštěstí procesorů jsou i jiné procesory než jen tyhle dva, takže otázka nemá smysl.

[disorder]

stacil by mi ten lacnejsi. a nemam vyuzitie pre 2GB, takze usetrim.

[Heron]

a nemam vyuzitie pre 2GB

V tom případě máte na disku méně než 2GB dat a v tom případě to skutečně nevyužijete.

[disorder]

ked ich nepotrebujem, tak ich nechavam na disku - zda sa mi to efektivnejsie :)

[Luk]

...efektivnější - přesně do chvíle, než je potřeba s nimi pracovat

[disorder]

ja si radsej pockam na tie data, ked ich budem potrebovat nez aby som cakal kym sa naloaduju ked ich nepotrebujem. (a co uz sa len do tych 2GB zmesti?)

[Luk]

Jenže ona se nemusí loadovat vůbec, pokud v té paměti zůstanou od předtím.

[disorder]

tusis vobec kolko dat mam a ako casto vypinam (t.j. RAM ich neuchova dobuducna)?

[Luk]

Netuším. Ale tušíš, kolik knihoven a jak velké všechny tvoje programy používají?

[disorder]

ano tusim. normalne je to do 300MB aj s operou s viac nez dvoma desiatkami tabov a flash pluginom. teraz momentalne po restarte je to 289MB aj s diskovou cache, ale este sa mi nestalo, ze by mi neostalo minimalne nejakych 200MB (z 1,25GB) aj po niekolkych dnoch behu. takze pises bludy.

[Luk]

Co na to říct? Každý svého štěstí strojvůdcem. Myji si nad tím ruce

[Petr (DotaZ) Jakubec]

hmm, jak to tak ctu, mam za to ze tu snad nikdo nepouziva linux...

pro tento (a i jine vyspele a rozumne navrzene OS je preci pre-loading bezna vec - zvysuje se tim vykon. Z mych zkusenosti rozhodne vyrazneji nez zvysovanim taktu procesoru.

dalsi vyuziti je nasmerovat /tmp do ram disku (bezne to dela napr Mandriva Linux pomoci tmpfs).

PS: ne/vyuziti RAM nad 1GB? to ma byt vtip? vzdyt 1GB je dnes rozumne minimum.

[disorder]

chces tu za niekoho druheho stanovovat minima? existuje tu akysi pomer cena/vykon, kde za tvoj "minimalny" vykon, ktory vyuzijem tak 1x za pol roka zaplatim minimalne o niekolko tisic viac. a prave pretoze pouzivam linux, nepotrebujem viac (momentalne par mesiacov ani nemam swap a nechyba mi).

na oplatku sa spytam, ci nahodou nepouzivas XP/vista, ked ti nestaci ani 1GB na beznu pracu?

[Heron]

aby nedoslo k nedorozumeniu, rezerva je dobra - ale 2GB? to je mi nanic, nevyuzijem ani 1GB ked sa snazim :)

Asi se snažíš málo . Pokud ti paměť stačí, není co řešit. Osobně bezproblému využiju i ty 4GB.

[disorder]

samozrejme sa nesnazim otvarat obrovske subory vo vime ani zle napisanom hexaeditore :)

[msk]

2G ram pri normalnej praci nepocitis. V praci som musel upgradnut z 512 na 2G kvoli otvaraniu velkych suborov etherealom a nepocitujem ziadny vacsi rozdiel vo vykone ( mimo ten ethereal ). Obcas, ked kopirujem velke subory hore-dole po disku, tak prvych par desiatok sekund to ide 50MBps ( len read do ram ), potom sa zaplni buffer, spadne to na 8M a ked sa operacia dokonci, par desiatok sekund trva, nez to prestane zapisovat ( takze pripadne dalsie paralelne citanie bude zase pomale ). Inak to pri beznej praci ( web, posta, programovanie, kompilacie ) takmer nepocitujem. Na vytazeny server prosim, na desk/work-station ( zatial ) zbytocnost.

[peter_h]

Disky narazaju pri otackach na ten problem, ze to produkuje vacsie teplo, treba asi aj kvalitnejsie materialy atd.
"Hlupy" defrag moze veci este zhorsit, ked napr. da casto pouzivane subory na opacne konce particie, aj preto sa to moc neodporuca.
Prednacitavanie zase ma ten problem, ze napr. je nevhodne na notebooky.
Jediny u mna osvedceny postup (btw. v linuxe stale nedorieseny) je transparentna kompresia, napr. prvy start oo.org to zasadne urychli a verim ze aj KDEcku by to pomohlo (a to ma privadza k myslienke, ze by to mohol niekto skusit, ja som si teraz zrusil linux, skusam bsd).

[Käyttäjä 11133]

Prosím, transparentní koprese není vyřešená? Co crypto-loop? Vím že ten už je vyřazen z jádra, ale byl nečím nahrazen a divil bych se kdyby to nepodporovalo i nějaký kompresná algoritmus.

[peter_h]

Ale to tam musis nakopirovat a na kazdy adresar si vytvorit image. Mne ide o to, ze nastavis atribut vo fs a nemas 100 mount-pointov potom.
A vyskusal ste to? Napr. binarky sa vobec nemenia. Alebo taky runtime paker existoval, teraz neviem ako sa volal, mozno ten by stacil.

[Devilkin]

Myslím, že budoucnost bude patřit flash diskům. Třeba něco takového. Za dva roky budou parametry vypadat určitě ještě líp.

Dovedu si představit, že do těch dvou let budu mít systém včetně aplikací na flashdisku a na klasickém disku třeba jen data. Když k tomu připočítám tak 4GB RAM (to už bude chabý průměr) a nějaký ten čtyřjádrový procesor...

Jen doufám, že na tohle nečekají vývojári (nejen ti u KDE)

[disorder]

tak to dufam, ze na to nikto necaka. o dva roky tu budu stale hlavne normalne disky a priemerna RAM maximalne 1GB (vista...).

[Käyttäjä 11133]

Hmm já spíš doufám, že mi ty 2 roky vydrží ještě to co mám, ale každý jsmě nějaký.

[Devilkin]

No já jsem ze svým 2roky starým Athlonem XP 2500 (1GB RAM) taky zatím spokojený a doufám, že mi ještě nějaký ten rok bude stačit. Navíc se nijak za výkonem neženu, ale za dva roky už nějaký ten upgrade bude (čistá statistika) a takový flash disk by navíc ušetřil "nějakou tu elektriku". Navíc bych rád nehlučné PC a i taky budou flashdisky nepřekonatelné (pravda HD je to poslední co bych teď slyšel).

No uvidíme, dva roky utečou jako nic

[msk]

Disk ma spotrebu par watt.

[trekker.dk]

Zvětšení cache disku

je IMO problematické, protože při výpadku napájení hrozí ztráta dost velkého množství dat (pokud bude cache zrovna plná)

[Miroslav Suchy]

Pokud si chcete zrychlit KDE, tak si z .kde/share udelejte ramdisk. Je to trochu drbacka tam kopirovat data pri startu a pri ulozeni pryc, ale pokud si kazdou chvili nemenite konfiguraci, tak neni problem ani pad pocitace. A v nekterych pripadech je zrychleni velmi citelne.

[Michal Vyskočil]

To není vůbec špatný nápad, musím to vyzkoušet. Ovšem mých 512MB je už zoufale zaplácaných, musím si přikoupit dalších 512.

[jan.xxx]

A nepište, že mám data přesunout jinam, když nemám jinde místo

[Michal Vyskočil]

No a to se na mě dívali jako na vola, když jsem u notebooku zaplatil skoro 5000 navíc jenom proto, že je tam rychlejší (a větší) disk s 5400 otáčkami a rychlejší paměti DDR2. Navíc měl paradoxně slabší procesor, "jenom" 1,6GHz.

[peter_h]

Niektori ludia nechapu, ze disk je najpomalsi v PC a ze parameter 1,6GHz ti bez benchmarku nic nepovie a ze aj ten najrychlejsi procesor (x86) by bez pamate nefungoval a ja im to uz ani nevysvetlujem, nie som papagaj. Nechapem naco sa ma pytaju potom ake pc si kupit, ked im poradim, ze radsej nech si priplatia za rychly disk, tak na mna kukaju ze ci mi nesibe nahodou, disk ako disk a kapacitu maju rovnaku a najhorsie je, ze tito ludia sa potom budu hadat, ze mali AMD a bola to pomala s.cka a ze teraz maju intel a neda sa to porovnavat. Samozrejme, ze sa neda, ked do AMD cpu lacne pamate a lacne disky a vsetko lacne aby to vychadzalo lacnejsie. Ja som si robil zostavu s AMD sam a neda sa to zrovnavat s intelmi v robote (zas sa setrilo) a moze za to intel? Ale co narobis?
A este poznamocka - v pocitaci s PII 233MHz mam 256M, novy disk a uplne v pohode sa da na tom robit, hry asi tazko, ale inak do kancelarie je to v pohode. Ale so starym diskom to bol horor.