túl nagy load

Merevlemezek, vezérlők

Lenne egy server és egy idő óta túl nagy rajta a load, ami nagyon lelassítja.

load average: 10.48, 7.95, 6.33
Cpu(s): 15.5%us, 3.8%sy, 0.0%ni, 26.0%id, 54.6%wa, 0.0%hi, 0.1%si, 0.0%st

A wa is elég nagy. 4 winyó van HW-es raid 5-be téve.
Hogy tudnék több infót kiszedni, hogy mi emészti fel az erőforrásokat?
Nem indokolna ekkora terhelés, adott file műveletek mellett.

  • 1882 megtekintés

( ScOut3R | 2009. 05. 12., k – 16:56 )

Minden merevlemez ep? Nem fogyott el a memoria (nincs szabad ram fajlrendszer cache-nek)?

minden lemez ép, se log nincs róla, se a hw nem jelzi

Cpu(s): 2.2%us, 1.1%sy, 0.0%ni, 31.7%id, 65.0%wa, 0.0%hi, 0.0%si, 0.0%st
Mem: 2075840k total, 1968408k used, 107432k free, 34436k buffers
Swap: 1954312k total, 35452k used, 1918860k free, 1708660k cached

Szerintem ez is teljesen rendben látszik. Nem tudom hova tenni.

Ha magas a wa, akkor a tobbszalusitas nem fog segiteni sajnos. A rendszer egyertelmuen a diszkekre var. Hanyas kernel fut a gepen? A 2.6.23-ban javitottak a feladatutemezesen a diszkalrendszer szempontjabol.

Nincs esetleg olyan fajlrendszer felcsatolva, ahol mar csak nagyon minimalis a szabad hely? Hany tomorites fut egyszerre?

2.6.20-16-server #2 SMP Sun Sep 23 19:57:25 UTC 2007 i686 GNU/Linux
kernel fut rajta, így lehet segítene valamelyest a frissítés
amire a tömörítés megy az 91-95%-on áll így elég tele van
csak azért gondoltam a többszálúsítást, hátha hamarabb lefut és a terhelés időben hamaradd megszűnik
egyszerre több tömörítés is fut, de egy az ami ekkora terhelést okoz, mert a többi simán lefut, míg ez az egy folyamatosan dolgozik

szia!

érdekes, én pont tegnap akartam ugyanerről egy kérdést feltenni :)
az én helyzetem kísértetiesen hasonlít a tiédre :)
2.6.20-17-generic #2 SMP Wed Aug 20 16:47:34 UTC 2008 i686 GNU/Linux
két diszk van. a szerver általában rendkívül alacsony terheléssel dolgozik (<0.1) folyamatosan, viszont délben beindul egy backup script, ami először törli a legrégebbi mentést, majd pár könyvtárat áttol (cp-vel) egy másik diszkre, olyan ~10gb, sok kis fájl. ilyenkor nálam is felugrik a load 9-10 körülire, már a törlési fázisban és a mésolás alatt is. van egy másik szkript, ami péntekenként fut (heti mentés) a napi után, az meg tar-ral csinál teljes mentést, szintén 8-10 gb fájlokat. ez is felnyomja a loadot. a cél lemez nálam is 85-90% körül van.
ugyanakkor nekem nem lassul be tőle a szerver, legalábbis nem vehető észre.

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

igen, olyankor van a legkevésbé használva.
nice-on gondolkoztam, de igazából nekem az lett volna a kérdésem, hogy ha ez a magas load nem okoz semmiféle problémát(?), tehát közben megy azért rendesen a samba, ftp, mail, imap, stb., akkor érdemes-e vele foglalkozni? okoz-e gondot? a userek nem vesznek észre semmit az egészből. a backup meg normális ideig fut, tehát nagyjából annyi ideig, ameddig az adott mennyiségű adatnak a vinyó adott sebességével illene átmásolódni. egyszóval, a magas load számtól eltekintve nem nagyon látok problémát. akkor hagyjam?
(de nem akarom elorozni ezt a thread-et :) )

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

Szia,

nem vagyok rendszergazda, így csak a saját desktop-omon összeszedett tapasztalatról tudok beszámolni. Nincs semmiféle RAID nálam, valamint ext2-t használok. Az alábbiba mindenhol beleértendő a "szerintem"; inkább nem fogom mondatonként kiírni.

Az ext2-nek van egy olyan kellemes tulajdonsága, hogy az egymáshoz közel eső inode számokkal rendelkező file-ok fizikailag is közel vannak egymáshoz a diszken. (Ez nagyon pongyola, de most jó lesz; sparse file-okkal meg nem szekvenciálisan megírt file-okkal most nem foglalkozom.) A nagy wait-et én azért szoktam kapni, mert az OS ráncigálja a fejet. Ez három részből adódik össze:

  1. szuperblokk olvasgatása,
  2. directory blokkok olvasgatása,
  3. file-ok olvasgatása.

Az alábbi megoldással az első két pontot elkülönítve be lehet nyalni, majd a memóriában lehet marasztalni, a harmadik pontot pedig fel lehet gyorsítani:

  1. a
    vfs_cache_pressure

    proc (sysctl) változó segítségével beállítjuk (

    =0

    ), hogy az első két ponthoz tartozó blokkok nagyon ne akarjanak kimenni a memóriából, ha már egyszer be lettek nyalva. Lásd pl. itt és itt.

  2. Ezután egy megfelelő GNU
    find

    parancs segítségével összeszedjük a file-okat, és inode szám szerint rendezzük. Ennek kettős haszna van: egyrészt összeállítja a megfelelő sorrendű file-listát, másrészt -- mivel a 

    sort

    csak akkor kezdi el a rendezett output-ot kiírni, amikor az input-ot már teljesen beolvasta, vagyis EOF-ot látott -- a 

    tar

    ill. a 

    cp

    a file-okat csak akkor fogja elkezdeni feldolgozni, amikor az összes szükséges directory blokk már a memóriában van. Ha a forrásállományok külön device-on (filesystem-en) találhatók, akkor figyelni kell, hogy ezek egymással ne keveredjenek össze (legalábbis ha fizikailag azonos diszken vannak), az inode-ok számozása ugye csak adott 

    dev_t

    értéken belül egyedi.

Az alábbi példában egy 

hda1

-en és egy 

hda2

-n található fs-sel játsszuk el ezt egyszerre. A 

tac

értelme csak annyi, hogy a teljes input-ot fel-buffer-eli (persze meg is fordítja a sorrendet) -- a 

sort

ugye fs-en belül megoldja ezt, viszont a két fs-t külön kell rendeznünk, ezért külön buffer-elésre van szükség, ami a teljes file-lista kiírásának megkezdése előtt megvárja az EOF-ot. Hogy az inode-ok mégiscsak növekedjenek végül, azért az elején a sort-tól csökkenő sorrendet kérünk. A file-nevekre csak annyi kikötés van, hogy újsor ne legyen bennük. 


export LC_ALL=POSIX

for I in /mnt/hda1fs /mnt/hda2fs; do
  find "$I" -printf '%i %p\n' \
  | sort -k 1,1rn
done \
| cut -f 2- -d ' ' \
| tac \
| tr '\n' '\0' \
| tar --create --no-recursion --null --files-from - \
| ...

( pepelopez | 2009. 05. 13., sze – 16:39 )

Nekem egyszer egy hp hw raid kártyán elment az aksi,erre kikapcsolta a write cache-t, és szépen vissza is esett az írási teljesítmény.