Výkon Ext4 klesá s novými verzemi jádra

Phoronix otestoval výkonnost souborového systému Ext4 v jádrech 2.6.28 až 2.6.33. V mnoha testech výkon s novými verzemi výrazně poklesl (kvůli doplňování funkcí zajišťujících stabilitu a spolehlivost).

20.1.2010 09:38 | Robert Krátký | Zajímavý článek

Komentáře

[Nicco]

Na desktop velmi dobre "tikajuci" kjournald2 je velky problem. Pri ziadnej uzivatelskej aktivite vyskakuje pravidelne v iotope na 3-4%

Ked si date googledesktop, to uz je aj 30% a co uplne nezvladne, to je vmplayer spustajuci windowsi z fyzickeho disku.

Tak kjournald2 zabera 99% a system je velmi zahlteny.

Ako typ jurnalu som pouzival default hodnotu.

[frr]

Hmm - pokud správně rozumím komentářům na Phoronixu, tak se víceméně změnily defaulty (opšny pro mount) - nově jsou bariéry standardně zapnuté (dřív nebyly). Takže ten test srovnává jabka a hrušky, resp. dokumentuje výkonnostní dopad bariér.

[m1c4a1]

Tak tak, mělo by tam být, že se zvýšila bezpečnost zápisu. Ale holt pesimistický titulky jsou čtenější.

[Robo]

nie je to len o barierach; celkovo to islo dole; ext4 s novymi kernelmi nenamountujes, tak aby isli rovnako rychlo ako predtym

[Ruža Becelin]

...protoze Phoronix. Bohuzel to tady porad spousta lidi nepochopila, a furt tady budou davat zpravicky o prevratnych vysledcich testu...

[J. M.]

Příště bych doporučil si ten článek na Phoronixu nejdřív přečíst, než o něm začnu plácat.

[xm]

Pokud byste si ten článek opravdu přečetl, tak byste věděl, že tam na konci dělali i srovnávací testy při vypnutých bariérách. A výsledek byl sice jak se dalo předpokládat podstatně rychlejší než s bariérami, ale pořád extrémně pomalejší než ve starších kernelech.

Takže rozhodně nejde jen o zapnuté bariéry. IMHO ten výkon zabili změny okolo fsyncu (kvůli stupidním aplikacím předpokládajícím, že to co zapíšou do souboru bude ihned okamžitě nezvratně na disku, místo aby si to ohlídaly samy - přičemž POSIX samozřejmě nic takového nevyžaduje, na XFS či JFS také v případě výpadku můžete přijít o čerstvě zapsaná data). Což je průser, protože tohle žádnou volbou při mountu neovlivníte

[frr]

matně si vzpomínám na nějakou hlášku v tom smyslu ohledně Emacsu?

[frr]

Jasně, úplně na konci porovnávali databázové Tps bez bariér a s bariérami. A zmíněný fsync taky bude mít vliv při zátěži, která visí na IOps.
Ale popravdě řečeno mi ani jedno z toho nevysvětluje 50% sešup v sekvenční průchodnosti při čtení. Ta lepší hodnota odpovídá špičkové hodnotě dnešních 2.5" disků, což je zřejmě tenhle případ (ST9320325AS). Osobně jsem viděl takovýhle výkonnostní propad ve dvou případech:
1) odpovídá to rozdílům v konfiguraci ICH9 na některých motherboardech (IDE / native SATA / AHCI) - netuším, jak je na tom SATA HBA v IONu
2) by mě zajímalo, jak měli při těch různých testech nakonfigurovaný "-o noatime" - ať už explicitně ve fstabu, nebo nějak implicitně (driver default, nebo zda vůbec access time byl implementovaný, a přesně jak, jestli tam nedošlo ke změně).

[xm]

Jednoduše to prostě nějaká hodně ošklivá výkonostní regrese v kernelu je. Ať už úmyslná (třeba ty tanečky kolem fsyncu) či neúmyslná. A pokud je úmyslná (jako nevyhnutelný vedlejší produkt nějakých změn), tak by rozhodně měli nabídnout alespoň volbu při mountu používat starou rychlejší (byť třeba méně "bezpečnou") metodu.

Co se týče toho noatime - předpokládám, že to nechali na výchozí hodnotě. Což do 2.6.29 bylo striktní atime a od 2.6.30 výše relatime (samozřejmě distribuce si to mohly upravit, ale předpokládám, že testovali vanilla kernely). Takže rychlost čtení by se měla naopak od 2.6.30 z tohoto hlediska zlepšit, né zhoršit.

[Robo]

no a to som si dal na novy comp vsade ext4

[Zdenek]

Co pa ty, ale Google taky a to je tragedie!

[Nikola Ciprich]

myslim ze google to jeste nikam nedal, najali si Theodora T'So aby jim s migraci pomohl, a verim tomu ze v ramci teto akce se urcite bude dale pracovat na vykonu, ktery google urcite bude zajimat...

[Jindřich Makovička]

Akorat, ze Google AFAIK zajima hlavne provoz ext4 bez zurnalu.

[dark]

Mám pocit, že rychlost jádra se obecně snižuje s každou novou verzí, někde to tu i bylo, o 2% každý rok?

[Bedňa]

Ja mám veterán komp a môžem povedať že zmeny za posledný rok v jadre dosť zrýchlili jeho chod, prvé až neuveritelné zrýchlenie spôsobila úprava správy pamäte optimalizovaná pre staršie kompiše, to že Ext stojí za prd nieje žiadna novinka.

[dark]

Já mluvím o nějakém výzkumu, který dělal intel, ale nechce se mi to tu hledat:) Mi osobně spíš vadí rychlost GUI, tam se podle mě za 7 let co používám linux nezlepšilo vůbec nic.

[J. M.]

Nejen nezlepšilo, ale hlavně několikanásobně zhoršilo. Já používám Linux 11 let a mám možnost dlouhodobého srovnání i na počítači, kde mi běží od roku 2001 (samozřejmě stále průběžně aktualizovaný). A režie a pomalost GUI je každým rokem čím dál větší.

[dark]

No já jsem si toho všiml teď hlavně na jednom starším kompu (Duron 800MHz, ~380MB ram, je to plečka), a tam je to všechno fakt vidět (je tam KDE3 a Gtk). Ten komp jsem chtěl někomu dát jen na net, ale abych pravdu řekl, tak se za tu rychlost fakt stydím. Vidím se překreslovat každou viditelnout komponentu, jak v Qt tak Gtk, resize oken je tak na 2 sekundy, zobrazení menu tak na sekundu (u firefoxu je delší prodleva). Je to něco strašného:( Jen abych doplnil, nastavil jsem schválně jednoduché téma (Redmond).

[J. M.]

Tak u toho KDE 3 mě to docela překvapuje. Na to mám hezké vzpomínky, to mi i na podobné plečce (no, o něco rychlejší) jelo mnoho let dobře (což znamená pouze tak 2x-3x pomaleji než Windows XP, což je na linuxové poměry excelentní výsledek, dnes už z říše sci-fi). GTK+ nicméně bylo velice pomalé vždycky, od verze 2.0, ale velkou ránu tomu zasadil přechod na Cairo ve verzi 2.8. Aspoň že už teď v nové verzi používají ty alieny, windowless widgets, to u mě odstranilo hodně překreslovacích artefaktů při změně velikosti (sice se to překresluje pořád pomalu, ale aspoň to nevypadá tak blbě), a hodně zrychlilo překreslování spin buttonů. Když k tomu připočtu ještě synchronizaci se správcem oken při změně velikosti okna, kterou přiedali asi před 4-5 lety, tak to jsou asi jediná dvě významná zlepšení výkonu, která jsem u GTK+ 2.x za celou jeho existenci zaznamenal (a obojí jsou jenom "triky", ne skutečné zrychlení).

Jinak linuxové GUI je podstatně pomalejší celou dobu co Linux používám. Začínal jsem na Pentiu 120 MHz s KDE 1 a jelo to pěkně. Dnes už nepředstavitelná věc. Jenomže pak přišlo KDE 2 a od té doby už je rozdíl linuxových GUI oproti Windows jednou provždy takový, že se člověk opravdu stydí to ukázat někomu zvyklému na Windows. Dřív bylo potřeba hodně koukat na vytížení procesoru, aby člověk viděl, že každá hovadina, která ve Windows žere 0-2 procenta výkonu procesoru (třeba přejetí myši nad nějakým elementem, procházení menu atd.), žere v Linuxu 10-30 procent. Dnes už to je třeba 60-80 procent a už je to vidět pouhým okem, že to prostě nestíhá.

Bohužel dřív to bylo hlavně to GUI a aspoň systém pod tím byl jinak v pohodě, ale už nejmíň rok nebo dva se k tomu přidalo i linuxové jádro, které má podle mě teď nejhorší období za celou svoji existenci. Pro mě je to už momentálně na 2.4 GHz stroji pod hranicí použitelnosti, ten systém se každou chvíli dusí sám sebou, práce s diskem už ho v každé nové verzi víc a víc zahlcuje, až tak, že třeba 2-3 minuty nonstop absolutně nereaguje, ani jednou nepřekreslí obrazovku, nepohne kurzorem myši ani o pixel. V unixových systémch s X Window Systemem vždycky ta interakce s GUI byla odjakživa dost špatná, vždycky se to při vytížení systému sekalo, vždycky se zadrhávala myš daleko víc než ve Windows, které mají to GUI víc spjaté s jádrem, ale to, co mi předvádí Linux v posledním roce, jsem v životě neviděl. A je to čím dál horší. K tomu se přidává i čím dál horší stabilita všeho.

[okbob]

Na rychlost vykreslování má zásadní vliv akcelerace grafiky.

Používám Gtk na 5 let starém Notebooku s inteláckou grafikou a všechno jede naprosto v pohodě. Být Vámi, tak si ověřím nastavení Xek. Tam máte něco vyhnilého.

[J. M.]

Hahahahahaha.

Nastavení Xek si ověřuji již přes 10 let. Vyzkoušel jsem všechny kombinace všeho, co lze, a mnohdy snad i nelze, zkombinovat. Včetně výměny grafické karty za konkurenční. Nemá to na věc žádný vliv.

Nicméně stejně tak těch 10 let slyším "zkontroluj si nastavení", což mě po těch 10 letech každodenního kontrolování může už jen rozesmát. Tož tak ještě asi dalších 10 let si to nastavení budu každodenně kontrolovat, a pak už snad konečně bude použitelný nějaký jiný operační systém, který nebude mít tak neodstranitelně neefektivní a superpomalou grafiku.

[J. M.]

Mimochodem, 10 z 10 benchmarků se mnou souhlasí. Vždycky, když se testuje výkon něčeho, co vykresluje grafiku (např. hoši z Nokie když testují Qt), vždycky je to pod Xkama několikanásobně pomalejší než na Microsoft Windows. A nikdo se tomu nepodivuje, protože to je notoricky známá věc, kterou každý, kdo to léta sleduje, považuje za samozřejmost, se kterou se nedá dělat nic jiného než se s ní smířit.

[okbob]

Problém nemusí být pouze v kartě - může být někde ve sběrnici, na desce.

Z principu budou Xka o něco pomalejší než windows grafika. Je to dáno stackem a strukturou, architekturou klient-server. Na stranu druhou problémy, které popisujete rozhodně nejsou typické. Na všech počítačích které mám nepozoruji rozdíl v rychlosti vykreslování Win a X. S pomalým překreslováním jsem se naposledy setkal, když jsem spouštěl Netscape na mašině s 80MB paměti. Od té doby jsem na nic podobného nenarazil - a to už jsem vystřidal všechny Fedory a to jak s grafikami Intel, tak s NVidii.

Jakou používáte grafiku?

[dark]

To jsou všechno jen mýty, univerzální odpověď, kterou slyším velice často.

Problém je v implementaci a kvalitě GUI knihoven, které se používají. Stačí udělat resize okna pod windows a v linuxu, a musí každému dojít, jak moc velký rozdíl v kvalitě implementace je (ne že by se jednalo o něco měřitelného, ale oči snad mají všichni). Podle mě by stačilo jen trochu zapracovat, dostat renderování na client-side (jak to udělalo Qt), používat windowless widgety, atd. Sice to znamená mín používat X Window, a víc toolkit, ale jak jde vidět, je to nejspíš dobrý směr. Druhá věc je optimalizovat grafické knihovny (hlavně cairo), je to bída.

[okbob]

Já jsem neodpovídal - naopak, zeptal jsem se jakou že předřečník používá kartu.

P.B. ví v čem to je - mám 5 let starý (na tehdejší dobu lowend) notebook a jedu bez problémů - prestigio nobile, 2G RAM, grafika je lowend intel. Jediné s čím byly problémy, byla podpora více monitorů - ale teď už je to v pohodě.

[alblaho]

Já mám asi něco podobného a rychlost GUI mi nevadí (gnome). Ale je to pomalejší než Wokna, wtz.

Jak ale psal kolega výše, že se přidalo to jádro, tak to není tak docela pravda. I když je jádro pomalejší (o nějaké procento) s každým releasem, tak hlavní vinu nesou rozežrané aplikace. Všelijaké indexery, pulsovací audia, démoni a tak. Polovina desktopu je napsaná v Pythonu, něco v Monu.

[J. M.]

To jsou ale volitelné věci, které si člověk může, nebo nemusí nainstalovat. Například já jsem v životě žádný indexer nebo cokoli v Monu nepoužil, PulseAudio jsem zkusil jednou a už mi nikdy víc na počítač nesmí, můj desktop je napsaný v čistém céčku. Spolu se všemi démony i jádrem obsadí jenom nějakých 50 MB a vytíží procesor na nula procent.

Přesto mám s jádrem stejný problém jako tisíce jiných. Tohle byl v posledních měsících a letech velký hit, to zahlcování jádra při práci s velkými soubory, na Rootu o tom byla nekonečná mnohaměsíční diskuse, do které se připojili snad všichni místní (prakticky všichni s tím měli problém a řešení žádné), i tady na ábíčku o tom byla velice výživná diskuse. Spousta lidí má úplně stejnou zkušenost. Poslední, co jsem četl, bylo, že prý snad nejnovější jádro už to konečně opravilo, ale na mém počítači bohužel stále žádná velká změna k lepšímu.

[dark]

No nevim, když se podívám na cairo, gtk, xlib, atd, tak mám pocit, že grafické ovladače jsou až to poslední, co má nějaký vliv na rychlost GUI aplikací. Šokující ale je, že Qt s použitím raster engine (což je vykreslování na client-side) je mnohem rychlejší, než s použitím xlib/opengl (u gtk neznám podobnou volbu, tak nemůžu porovnat).

..ale dost bylo flejmů, kecáním nic nevyřešíme:)