magas IOwait

Ubuntu Linux

az OS Ubuntu 9.04, következő a problémám:
ha torrentezek, néha azt csinálja hogy felszökik az iowait az egekbe, emiatt kb megáll az egész rendszer, van hogy az egeret is alig lehet megmozdítani, a programok nem válaszolnak, a zene akadozni kezd stb.
ugyanezt csinálja hasheléskor, és kicsomagoláskor is, mindig. A kicsomagolás max 10MB/s körül mozog ami elég nevetséges, nem értem miért csinálja.
Win alatt működik minden, legalábbis ilyen szintű belassulást nem tapasztaltam egyszer sem.

van valakinek valami ötlete mitől lehet és mit lehet vele csinálni?

hdparm -tT /dev/sda
/dev/sda:
Timing cached reads: 2028 MB in 2.00 seconds = 1014.13 MB/sec
Timing buffered disk reads: 226 MB in 3.02 seconds = 74.90 MB/sec

  • 2173 megtekintés

( kavics | 2010. 01. 12., k – 19:45 )

nekem is :)
4éves vinyó
DL: 3 Mbyte/s

sajnos a Hdd-k miatt szokott belassulni egy rendszer.
Mikor megveszed, tök jó gyors, tökéletes, de 1 év után már sokkal lassabb, ugyan azokkal a szoftverekkel.
Használj SSD -t ha nagyon zavar :) hosszútávon szerintem jobb.

( maniac | 2010. 01. 12., k – 20:06 )

Ha be van kapcsolva a write, es read cache, akkor lehet a filerendszer, utemezoknel kellene keresni a problemat. Filerendszerek nemelyike szeret toredezni, es emiatt idonkent iszonyatosan blassul (foleg torrent miatt szeret toredezni). Masik az utemezo lehet meg, cfq valt be szamomra a legjobban, a legtobb kernel is szerintem mar ezzel van alapbol szerelve. Szoval szerintem a filerendszerrel lehet valami. Milyet hasznalsz? Szvsz xfs a legjobb torrentezesre amugy.

-------------------------------
“The 0 in Raid 0 stands for how many files you’re going to get back if something goes wrong” :)

/dev/sda3: clean, 29154/14172160 files, 25551672/28320586 blocks

29154 inodes used (0.21%)
3072 non-contiguous files (10.5%)
25 non-contiguous directories (0.1%)
# of inodes with ind/dind/tind blocks: 19475/4272/1
25551672 blocks used (90.22%)
0 bad blocks
2 large files

nem értek hozzá, de ez nem tűnik nekem olyan vészesnek, vagy az?

ezek a (modern) filerendszerek igen jol birjak a hasznalatot. Szamottevo fragmentacio akkor szokott elofordulni, ha neha-neha betelik, vagy ha allandoan magas telitettsegi szinten megy (90% felett) vagy ha lenyegeben nem tudja hasznalni a cachet (pl allando fsync(), fdsync() hivasok vagy nagyon teli a memoria)

Ha a memoriaban mindig van egy kis hely, es a filesystem soha nem megy 70% fole, es az atlag filemeret a filesystem meretenek elenyeszo resze (1% alatti) akor nem nagyon fragmentalodik, akar hosszu evek alatt sem.

Igazad van, hogy elmeletileg nem kell toredezettsegmentesiteni. Az NTFS-t sem kell elmeletileg. Gyakorlatilag viszont torrentezes, es egyeb hasonlo igenybevetelnel sajnos igenis toredezik a filerendszer.

-------------------------------
“The 0 in Raid 0 stands for how many files you’re going to get back if something goes wrong” :)

( ricsip v | 2010. 01. 12., k – 20:37 )

bad sector a vionyón? smart logban bármi érdekes?

( egeresz | 2010. 01. 12., k – 21:53 )

a (CPU) iowait kevesse szamottevo ertek/grafikon, bar varhatoan nalad (desktopon) jol illezkedik a 'disk %usage' grafikonnal.

Inkabb rakd fel a sysstat parancsot, es a

sar -d -p 3 0

parancsot futtasd egy ablakban. Ott latod a 'avgqu-sz' erteket: ez a diszkre egyszerre varakozo IO muveletek szama. Valamint az utolso oszlop lehet erdekes, a '%util' ez pedig az, hogy a diszk iranyaba meno csatorna mennyire van kihajtva.

vegul is mindegy, hogy van egy fizikai badsect, aminek relokalasa lelassitja a diszket, vagy iszonyatosan fragmentalt, vagy veletlenszeruen megszalad a proceszekbol eredo terheles (bar ez utobbin lehet szoftveresen hangolni). tehat vegul is, nem feltetlen mond hasznosat a 'sar -d -p' :-)

nekem is volt ilyen, nem tudtam megoldani, a net tele van ilyen postokkal, szerintem ez "normális", sajnos így működik. nem tudom, az ext fájlrendszer miatt van-e, mást nem próbáltam.
én úgy "oldottam meg" a problémát, hogy beraktam még több vinyót, és szétdobtam rajta a dolgokat. a rendszer külön, külön az adatokat, és külön másik adatokat. pl. a te esetedben külön lehetne venni a rendszert egy vinyóra, külön a torrenteket, és külön a kicsomagolandó dolgoknak (gondolom a kész torrenteket csomagolod ki?). iowait így is lesz, de nem fog belassulni tőle a rendszer jelentősen.

----------------------------------
feel the beat - it's everywhere!

( turul16 v | 2010. 01. 13., sze – 12:30 )

Probald meg masik io scheudlerrel.
cat /sys/block/sda/queue/scheduler itt tudod megnezni mi van most es bele echoz-va a nevet, valaszthatsz mast.

Amit nem lehet megirni assemblyben, azt nem lehet megirni.

( bocs | 2010. 01. 13., sze – 12:35 )

mint amatőr, egy ötlet: nem az ext4 okozza?
A phoronix tesztek szerint sokat fsync-el, így esetleg az oprendszer cache írása lerontja a teljesítményt.
Meg kellene próbálni másra tenni az oprendszert, vagy kikapcsolni az ext4 állandó fsync-jét.