I/O ütemező: Te melyiket használod?

Van egy számomra idegesítő probléma, amely az Ubuntu Linux alapú rendszereimet (9.04, 9.10) érinti, grafikus környezetben. Ha nagyobb fájlokat másolok a rendszeren (elsősorban a rendszert is tartalmazó merevlemezen), akkor a grafikus rendszer (X, fglrx, GNOME asztali környezet) iszonyatosan lelassul, válaszékonysága (Responsiveness) elviselhetetlenül alacsony szintre esik. Ti találkoztatok ezzel a problémával? Úgy tűnik nem csak Ubuntura korlátozódik a probléma, ezért is érdekelne a HUP-társak véleménye, tapasztalata.

Egy Ubuntu Launchpad hibajegy alapján kezdtem el játszani a lehetséges további beállításokkal. Egy másik, kapcsolódó hibajegy, ahol egy pár teszt is elérhető. Úgy tűnik a hiba másoknál is előfordul - barátaimnál is, és látok jópár ezzel kapcsolatos a levelezőlistákon is - ezért, úgy vélem, érdemes ezzel a kérdéssel foglalkozni, tapasztalatainkat megosztani. Mint ahogy azt mások is tették.

Első lépésként ellenőrizzük milyen I/O schedulert használ rendszerünk. Ezt a lekérdezést meghajtónként tudjuk elvégezni az alábbi módon: 

cat /sys/block/sda/queue/scheduler

Az sda a vizsgálandó lemezes eszközünk.

Alapértelmezésben ezt a választ kapjuk: 

noop anticipatory deadline [cfq]

Amennyiben ezen változtatni szeretnénk adjuk ki az alábbi parancsot: 

echo deadline > /sys/block/sda/queue/scheduler

Példában az sda eszköz mostantól deadline I/O ütemezőt használ. Ezzel úgy tűnik a fentiekben vázolt probléma megszűnik. Ugyanez igaz a noop, anticipatory vagy deadline közül bármelyikre, így lehet, hogy az alapértelmezéshez (CFQ) képest mindennel jobban járunk - legalábbis asztali rendszer esetén.

Ellenőrizzük a beállításokat: 

cat /sys/block/sda/queue/scheduler 
noop anticipatory [deadline] cfq

Ettől kezdve nincs más dolgunk mint ellenőrizni, hogy ez a módosítás valóban segített a fenti problémán. Mivel maga a válaszékonyság önmagában nehezen mérhető, kíváncsi lennék, hogy ki mire jutott a tippel kapcsolatban. Érdemes a deadline mellett a noop lehetőséget is kipróbálni. Várom tehát a visszajelzéseket, kinek, milyen gépen, melyik volt a legjobb megoldás.

Ha megtetszik valamelyik beállítás, így véglegesíthetjük:
Szerkesszük a /boot/grub/menu.lst fájlt: 

gksudo gedit /boot/grub/menu.lst

Keressük meg a kernel boot paramétereit tartalmazó sorát, amely például nálam így néz ki: 

kernel		/boot/vmlinuz-2.6.31-13-generic root=UUID=92f912ad-b348-4b68-b6c6-1963a5a2e1fb ro quiet splash

és adjuk hozzá a választott ütemezőt, példánkban elevator=deadline, ilyen módon: 

kernel		/boot/vmlinuz-2.6.31-13-generic root=UUID=92f912ad-b348-4b68-b6c6-1963a5a2e1fb ro quiet splash elevator=deadline

Tegyük meg azt azoknál a kernel-bejegyzéseknél, amelyeket használni kívánunk.

Mentsük el a fájlt majd futtassuk a 

sudo update-grub

parancsot.

Ezzel véglegesítettük a beállításokat.

A különféle ütemezőkről pár szóban:

  • CFQ scheduler (Completely Fair Queuing) (cfq): Napjainkban ez az alapértelmezett I/O ütemező a legtöbb Linux disztribució esetén. Nagy telejsítményű lemezes rendszerekhez lehet jó választás.
  • Noop scheduler (noop): Egyszerű I/O ütemező, amely lényegében a FIFO elv mentén végzi a kiszolgálást.
  • Anticipatory scheduler (anticipatory): A Linux rendszerek CFQ előtti I/O ütemezője, rosszabbul teljesít nagy teljesítmény lemez-alrendszer esetén, mint a CFQ.
  • Deadline scheduler (deadline): Garantált időt próbál biztosítani az egyes feladatok kiszolgálásához, mind írás, mind olvasás tekintetében...

Szilárdtest-meghatók (SSD) esetén a noop I/O ütemező lehet a legjobb választás.

( muczy v | 2009. 10. 11., v – 16:04 )

1. "Napjeinkban" <- elírás
2. a végén, ahol leírod hogy melyik milyen, meg kéne említeni, hogy a CFQ az alapértelmezett
3. grub menu.lst változtatása után ne felejtsük el, hogy következő kernel frissítésnél az apt-nak nem tetszhet a megváltoztatott sor: http://ubuntu.hu/node/9907
4. én nem rég tértem át a deadline-ra, hasonló okokból, mint leírtad
5. köszi a leírást! esetleg publikálhatnád más doksi tároló helyeken is.

1) Javítva
2) Szerintem a Napjainkban bejegyzés erre utal.
3) Jó ötlet az a változtatás, szerintem felvezetem
4) :o)
5) Szerintem fogom. Ubuntu.hu-n vagy a hogyan.org-on, ha van rá igény. De előtte vitassuk meg, hogy jó-e ez így, hogyan fejleszthetnénk tovább.

KAMI | 神
--
Támogatás | OxygenOffice | Fordításaim és SeaMonkey

OpenOffice.org fordítás mellett (lemez és CPU intenzív esetekben) néha beszaggat a háttérben futó Rhythmbox 0.12.5. De a helyzet még mindig jobb, mint eddig. Most deadline I/O scheduler használata mellett.

KAMI | 神
--
Támogatás | OxygenOffice | Fordításaim és SeaMonkey

3.-ra megoldas: 


## additional options to use with the default boot option, but not with the
## alternatives
## e.g. defoptions=vga=791 resume=/dev/hda5
# defoptions=panic=15

es a grub-update majd hozzabiggyeszti a panic=15-ot a kernel parameternek.

--
A vegtelen ciklus is vegeter egyszer, csak kelloen eros hardver kell hozza!

( Yorirou | 2009. 10. 11., v – 16:14 )

Én régen Gentoo alatt a deadline-t kedveltem, Ubuntu alatt ritkán dolgozok nagy fájlokkal, így nem annyira érint.

Most hogy írtad, váltottam deadline-ra, aztán nézem, hátha gyorsabb.

Valaki nem tudja véletlen, hogy GRUB2-vel hogyan kell kernelparamétert megadni? (nézegetem a fájlokat a /etc/grub.d alatt, de nem nagyon látom hogyan kellene) :)

( Gyuszk v | 2009. 10. 11., v – 16:15 )

Az izgi, hogy pont a CFQ-val szaggat be az X, mert elvileg az a desktopra ajánlott ütemező.

********************
"Aki nem backupol az tehetsegtelen :-)"
"...ha nem tévedek!" (Sam Hawkens)
http://holo-media.hu

( Sianis | 2009. 10. 11., v – 17:49 )

Köszi! Valóban nem hal le a rendszer ha nagy fájlokkal kell dolgozni!

( _ventura_ v | 2009. 10. 11., v – 17:58 )

nem csak ettől függ, nekem preemptes kernel van + CFQ de nagy I/O nál se szaggat be, pont a preempt miatt.

Core2Duo T7100, 4G, Ubuntu 9.04, 2.6.31

ugyehogyugye :>
Esetleg konfig HZ=1000 sem árt. Viszont frissítettem karmicra, ott nagyon rossz volt a válaszidő ismételtem gyári kernellel, ráadásul HZ=100 ra visszavették. Szal maradtam a saját preemptes kernelnél. Nem is értem a desktop kerneleket miért nem PREEMPT-el forgatják.

Core2Duo T7100, 4G, Ubuntu 9.10, 2.6.31

( PcZolee v | 2009. 10. 11., v – 21:43 )

Laptopon szerintetek melyiket érdemes használni?

<= Powered By Ubuntu & Gentoo Linux =>

'Software is like sex: It's better when it's free!'
By Linus Torvalds

( hrgy84 | 2009. 10. 12., h – 01:30 )

- "válaszékonysága" - yuyy... ez iszonyatosan fajdalmasan erint igy lefekves elott. "Válaszideje erősen megnő".
- "Ezt a lekérdezést meghajtóként tudjuk elvégezni" - kikérem magamnak, én nem vagyok meghajtó, és nem is óhajtok senki kedvéért az lenni.

Egyebkent en cfq schedulert hasznalok, viszont a rendszert tartalmazo meghajtomon csak a rendszer talalhato meg, nagy fajlokat nem a rendszert tartalmazo meghajton tarolok/masolok/kezelek. Es eddig nem erzekeltem komolyabb lassulast.
-- 


()=() Ki oda vagyik,
('Y') hol szall a galamb
C . C elszalasztja a
()_() kincset itt alant.

( apostroph3 | 2009. 10. 13., k – 00:57 )

Mi lehet a helyzet a dvd írókkal? milyen hatása lehet a deadline scheduler-nek az írási folyamatra?