[Megoldva] Nagy I/O terhelésnél brutális latency

Linux-haladó

A tárgybeli probléma kifejtve:

Tegyük fel hogy adatokat mentek HDD1 -> HDD2 irányba. Ez a folyamat akkora lassulást okoz a rendszerben, hogy felfoghatatlan. Bármilyen alkalmazás reakcióideje jobbik esetben ~2s körüli, rosszabb esetben van hogy közel percig kell várni arra, hogy mondjuk egy ablak felugorjon a tálcáról, vagy kattintok egy menüpontra Firefox-ban (openbox alatt).

SMART tiszta, kábelek tesztelve többször is, több gépben, táp rendben.

A CPU terhelés mindeközben <20% (2x), a 2GB memória 1/4-e van kihasználva nem cache-nek, egyedül az I/O pörög.

A 2.6.36-os (amd64, gentoo-sources) kernel sima Desktop kernelként van konfigurálva, semmi hókusz-pókusz, CFQ-val.
-ck kernelt próbáltam, annyira nem jó hogy random időnként egy-egy kernel pánikot elviseljek.

Nem hiszem hogy helyi probléma, mert több gépen is reprodukálni tudom a dolgot, most Gentoo alatt tűnt fel de tesztelve Ubuntu 10.04-en is.

Bármi ötlet, hogy lehetne javítani a reakcióidőn?

Köszönöm.

--
Megoldás lehet:

I/O ütemező: Deadline (sirenter)
Preemption model: Voluntary Kernel Preemption
Timer frequency: 1000Hz (Pingo_villany)

sysctl -w vm.vfs_cache_pressure=10 (sirenter, LGee)

  • 4169 megtekintés

- A legutóbbi BFQ patch 2.6.30-as kernelhez van, nem biztos hogy jó ötlet lenne.
- Konstans javulást szeretnék elérni. Ideiglenesen perce nice-olhatom azt amit akarok, de ez nem mindig megoldás.
- A memória teljesen üres, hozzá se szagol a swap-hoz, pedig rendelkezésére áll 1GB.

( pinyo_villany | 2010. 12. 12., v – 05:34 )

kernel config CFQ->AS, bar azt lehet vissza kellene patchelni, es probalj meg egy NONPREEMPT kernelt, mondjuk 100Hz-n 1kHz helyett.
___
info

( sirenter | 2010. 12. 12., v – 07:16 )

root-ként:
..# sysctl -w vm.vfs_cache_pressure=0
..# echo deadline > /sys/block/sda/queue/scheduler

sda értelemszerűen helyettesítendő; egyébként AS már rég nincs a kernelben

ha müxik:

/etc/sysctl.conf:
vm.vfs_cache_pressure = 0

/etc/conf.d/local.start:
echo deadline > /sys/block/sda/queue/scheduler

Konkrét összehasonlításom nincs, de érdekes módon volt már deadline-nal 30%+ fragmentáltságú lemezhez is szerencsém.

Bár elképzelhető hogy csak valami szerencsétlen folyamatok okán sikerült ezt elérni, mert közben van egy másik gép, ami szintén deadline-nal fut, és 0.1%-nyi fregmentációt számol az fsck.

( kisbetu v | 2010. 12. 12., v – 08:52 )

Konkrétan milyen eszközt jelölsz "HDD1" és "HDD2" néven?

( zolpet | 2010. 12. 12., v – 10:03 )

Szerintem ez a cfq működéséből adódik.
Ott miután kielégít egy io kérést, nem kezdi el kiszolgálni rögtön a soron következő folyamat igényeit, hanem egy rövid ideig vár arra, hogy lesz-e még újabb kérése az épp kiszolgált folyamatnak. Ha sok cuccot másolsz, akkor természetesen lesz. Én amikor ezzel kísérleteztem, azt tapasztaltam, hogy könnyebb beállítani egy deadline ütemezőt, mint a cfq-t felaparaméterezni. Ez hozott egy kis javulást, de nyilván a rendszernek vannak korlátai.

Végezz el egy tesztet úgy, hogy átállítod deadline-ra. Link : http://www.cyberciti.biz/faq/linux-change-io-scheduler-for-harddisk/

Lemezenként külön be kell állítani. Illetve lehet paraméterezni, ha van kedved kísérletezni vele :

http://www.serverwatch.com/tutorials/article.php/3819446/Selecting-and-…
http://www.gossamer-threads.com/lists/drbd/users/13515

Szerk : gyakorlatban ahogy Sirenter írta.

( apal v | 2010. 12. 12., v – 11:06 )

Tegyük fel hogy adatokat mentek HDD1 -> HDD2 irányba. Ez a folyamat akkora lassulást okoz a rendszerben, hogy felfoghatatlan.
hat legutoljara ilyet akkor lattam mikor valami dma opcio hianyzott (hdparm, ilyesmi, vagy nem megfelelo" kernelmodul). manapsag mar csak ninsc ebbol problema.

illetve: ha sok kicsi file-t masolgatsz, akkor igen, az szopo lehet. de ha nagy (seektime * seqreadwrite me'retet definite meghalado) fileokat masolgatsz, akkor me'g egy egyszerubb schd mellett sem kene ilyesmit tapasztalni.

( Byron | 2010. 12. 12., v – 12:52 )

Volt ilyen gondom nekem is Ubuntu 9.04 környékén, de már magától elmúlt (10.04-en legalábbis).

( Lacyc3 v | 2010. 12. 12., v – 16:10 )

Köszönöm mindenkinek a segítséget.

Az eddigi legjobb kombinációnak ez tűnik:

I/O ütemező: Deadline
Preemption model: Voluntary Kernel Preemption (Desktop)
Timer frequency: 1000Hz

sysctl -w vm.vfs_cache_pressure=0

Közel sem tökéletes megoldás, de az eddigieknél jobb. Folyamatosan tudok másolni, zenét hallgatni és böngészni is.

"Közel sem tökéletes megoldás, ..."

amit még mindenképp érdemes megnézni:

..# hdparm -M /dev/[hs]da

gyárilag a legtöbb disk-en 0 vagy 128, érdemes a 254-t kipróbálni; ha nem javul a transfer, vagy túl hangos a fejkattogás, simán visszaállítod 128-ra (a beállítást boot-olás után is megtartja)

sok éves, sok gépes üzemeltetési tapasztalat:
a terhelés intenzitásától függően 1nap..1hét alatt beáll a SLAB a RAM 10%-ára, aztán a következő boot-olásig ott is marad;

természetesen nem vitatom, hogy van ahol ez probléma; az én tapasztalatom viszont az, hogy hiába smartarray+bbwc, hiába tonnaszám a RAM, a legtutibb vasat is megöli a default vm.vfs_cache_pressure=100; természetesen még1x elnézést az =0 miatt, a vm.drop_caches=3 sem szabadítja fel a SReclaimable-t és természetesen maximálisan egyetértek, tesztelni kell

a topiknyitóban is jó lenne javítani az =0-t mondjuk =10-re

( arrabonus v | 2010. 12. 13., h – 11:48 )

...
Timer frequency: 1000Hz (Pingo_villany)
...

Ugye ez csak kernel újrafordítással változtatható?