Fórum Root.cz
Hlavní témata => Software => Téma založeno: Tomáš Psika 05. 08. 2010, 01:25:26
-
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
-
ha, dobry, mrknu na to
me to ted zacalo delat pri upgradu na 2.6.32.16, predtim s 2.6.32.10 ne
-
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.
-
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 :)
-
Jen pro informaci, v kernelu 2.6.35.3 daná úprava není, je už ale v 2.6.36-rc1.
-
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 :-\.
-
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.
-
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
-
myslis tedy spis dirty_bytes a dirty_background_bytes
-
brk@bobek /proc/sys/vm $ cat dirty_ratio dirty_background_ratio dirty_bytes dirty_background_bytes
10
5
0
0
-
tak dej misto toho:
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
-
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.
-
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