Random file I/O visszafejlődés a 2.6-ban

 ( trey | 2004. május 6., csütörtök - 9:28 )

Alexey Kopytov LKML-re postázott benchmark-jában megállapította, hogy a 2.6-os Linux kernelben jelentős visszafejlődés tapasztalható a random file I/O-ban. Mivel a random file hozzáférés elsősorban az apró file műveleteket jelenti (random I/O = kis fileok ``összecsipegetése'' a merevlemez terület elszórt részeiről, tipikusan adatbázis műveletek, szekvenciális I/O = egybefüggő, nagy fileok kezelése , tipikusan streaming video, audio, stb.), ezért elsősorban az adatbázisokat futtató felhasználók érzik meg ennek negatív hatását.
Alexey ezért olyan méréseket végzett, amely nagy terhelésű adatbázis-kezelést szimulálnak. A tesztek során megvizsgálta az összes szóba jöhető I/O ütemezőt, beleértve az anticipatory, deadline és a CFQ schedulert, és arra az eredményre jutott, hogy az összes esetben jobban teljesít a 2.4-es kernel, mint a 2.6-os (több, mint kétszer volt gyorsabb a 2.4).A hiba feltárásban Andrew Morton a 2.6-os kernel karbantartója és Nick Piggin az anticipatory I/O ütemező szerzője arra a következtetésre jutottak, hogy a regressziót valószínűleg a előreolvasási (readahead) cache nem megfelelő működése okozza (a random I/O-nál nagy szerepe van a megfelelő cache-elésnek, hiszen minél több adatot gyorsítótárazunk, annál kevesebb merevlemez műveletet kell végezni. Az apró fileok összeszedegetése rendkívűl sok merevlemez fej pozícionálással jár, amely nagyon időigényes feladat).

Andrew szerint a readahead logika egyre komplexebb, és állandóan csak foltozva van. Azt javasolta, hogy vessék el a jelenlegi megoldást, és gondolják újra azt. Végül a probléma okát Ram Pai találta meg. A probléma az volt, hogy több thread is ugyanazon fileleíróhoz (file descriptor) akart egy időben hozzáférni. Andrew egyetértett vele, és el is készített egy gyors patchet.

A teszt eredmények azt mutatják, hogy valóban ez volt a probléma. A patchelés után Andrew-nek ext2 filerendszeren AS ütemezővel jobb eredmények születtek a 2.6-os kernellel, mint a 2.4-gyel. Adatbázis embereknek mindenképpen érdemes majd kernelt frissíteni!

A thread itt kezdődik.

Hozzászólás megjelenítési lehetőségek

A választott hozzászólás megjelenítési mód a „Beállítás” gombbal rögzíthető.

Hát igen, az ilyen esetekről szól Linus törvénye. [en.wikipedia.org]

Még szerencse, hogy valaki felhívja az ilyen problémákra a figyelmet... :)

"Andrew szerint a readahead logika egyre komplexebb, és állandóan csak foltozva van. Azt javasolta, hogy vessék el a jelenlegi megoldást, és gondolják újra azt."

Végül megint csak foltozva lett... :P

Nem egeszen ertem, hogy miert a cache mukodesre gyanakodtak. A cache a adott teruletre koncentralt hivatkozasi mintak eseten jelent teljesitmenytobbletet (locality of reference). Szetszort random hivatkozasok eseten rontja a hatekonysagot, mert a cache muveletek extra overhead-et jelentenek.

Andrei

nem biztos, hogy a teljes atirasa 10 percet igenyel, mig egy patch kb. annyi ido alatt kesz van, ha ismert a regression oka.
nyilvan ujra kell tervezni, es implementalni kell a designt, ami nem ket perc. az a megnyugtato, hogy meg fogjak csinalni, es van olyan ember (Andrew) aki ki is mondja a hibakat. de nem csak kimondja, hanem meg is tudja csinalni

A cache logika epp azert olyan komplex, mert nem egyszeruen becacheli az adott teruletet ahonnan olvasas tortenik, hanem megprobalja kitalalni, hogy legkozelebb honnan fog tortenni olvasas es ugy probal elore cachelni... Ha rosszul tippel, akkor van "overhead"...

"[...] hanem meg is tudja csinalni"

Ki is tudja javítani :)