I/O disku mi zabíjí desktop

[Tomáš Psika]

Pokračování diskuze z http://www.root.cz/diskuse/3880/.

Objevila se zajímavá oprava v jádře, která by problémy s latencí měla konečně řešit.

Více na abíčku: http://www.abclinuxu.cz/zpravicky/opraven-problem-s-odezvou-linuxu-pri-velke-i-o-zatezi

[Reklama]

[trubicoid2]

ha, dobry, mrknu na to
me to ted zacalo delat pri upgradu na 2.6.32.16, predtim s 2.6.32.10 ne

[Tomáš Psika]

Ten zveřejněný patch v odkazovaném článku je proti -mm větvi, na vanilkách vyžaduje ruční úpravy. Kdo opravdu neví (jako já), co to dělá, ať to raději neaplikuje.

Někdo od Fujitsu tam dělal v mm/vmscan.c před čtyřmi dny pořádek:
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=e247dbce5cc747a714e8dcbd6b3f442cc2a284cf

Teprve poté byl aplikován zveřejněný bugfix:
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=e31f3698cd3499e676f6b0ea12e3528f569c4fa3

Zároveň se poté v -mm větvi trochu více změnila situace, takže bůhví, jak to nakonec ještě bude:
http://git.zen-kernel.org/?p=kernel/mmotm.git;a=commitdiff;h=00516132d6f15938beeef480669cd6f5ec8ef1ba

A protože jsem jen běžná lama, tak si raději počkám na konečný stav. S velkou pravděpodobností bude v 2.6.35.3. V nynější stabilní verzi (2.6.35.2) ještě žádná úprava v tomto ohledu není, protože poslední komit k tomuto souboru tam byl k 20. červenci.

[Filip Pytloun]

Tyto problémy jsem měl také - dokonce i na SSD. Opravdu nechápu jak může Linux s takovým bugem takhle dlouho vůbec existovat, protože ho to dělá při I/O loadu nepoužitelným bez ohledu na to, kde je nasazený.
Už jsem uvažoval i nad tím, že se od Linuxu přesunu zase směrem k jiným Unix nebo unix-like systémům, ale pak jsem našel řešení - zen-kernel (http://www.zen-hernel.org) s BFQ schedulerem, který obsahuje.

Pokud někdo má amd64 Debian, tak jsem dal k dispozici generic (default Debian kernel + moje nastavení pro desktop) zen kernel a headers tady - http://deb.ifrit.eu/dists/debian/main/binary-amd64/
případně celý repozitář:
deb http://deb.ifrit.eu/ debian main

Neslibuju že bude aktualizovaný, apod., ale když se ho někdo bude chtít ujmout nebo do něj jen přispět, tak není problém 

[Tomáš Psika]

Jen pro informaci, v kernelu 2.6.35.3 daná úprava není, je už ale v 2.6.36-rc1.

[Reklama]

[Tomáš Psika]

Před pár dny jsem upgradoval na 2.6.36. Problém s I/O latencí se zdá být vyřešen. Ale že to tedy trvalo .

[brk]

A jak to zpětně hodnotíte po letech? Během týdne jsem dělal kopii cca 30GB souboru na stejném disku a ve chvíli kdy došla RAMka pro cachování se to celé značně přibrzdilo, hudba občas vynechala, odezva zřetelně slabší.  Už to asi není takový masakr, jako v době vzniku tohoto, či spíše ještě původního vlákna, ale na to, že se ta i7 s 8GB RAM typicky těžce fláká a tady to bylo jen o kopírováni, tak stále nic moc.

[Neviditelný]

A jak máte nastavené dirty_ratio a dirty_background_ratio? Viz http://www.abclinuxu.cz/clanky/jaderne-noviny-7.-11.-2013-proc-pomala-flashka-zpomali-64bitovy-stroj#zakerny-problem-se-zamrzajicimi-flashkami

[trubicoid2]

myslis tedy spis dirty_bytes a dirty_background_bytes

[brk]

brk@bobek /proc/sys/vm $ cat dirty_ratio dirty_background_ratio dirty_bytes dirty_background_bytes
10
5
0
0

[trubicoid2]

tak dej misto toho:

Kód: [Vybrat]

echo 33554432 > /proc/sys/vm/dirty_background_bytes
echo 66554432 > /proc/sys/vm/dirty_bytes coz je 32MB a 64MB, muzes zkusit jeste treba 100MB a 200MB

[Neviditelný]

myslis tedy spis dirty_bytes a dirty_background_bytes

Ne, myslel jsem skutečně *_ratio, protože to se používá defaultně a působí to problémy. 10 % velikosti RAM znamená na mašině s 8 GB RAM 800 MB stránek, které může proces ušpinit, než se začnou zapisovat na disk. Právě použití *_bytes místo *_ratio může situaci značně zlepšit.

[trubicoid2]

tim, ze zapises do _bytes se ty _ratio vynuluji a opacne, vzdy plati posledni zapis

takze se dohodneme, ze se ma tech 800MB snizit trebas na 64MB a to bud pres _bytes (jak jsem navrhnul) nebo pres _ratio, tam ale je treba zapocist velikost RAM