Óránként magas load

Red Hat, Fedora, CentOS

Üdv!

Egy felettébb érdekes problémával küzdök bizonyos időközönként 5x-re ugrik a load
mindjárt a cron-ra gyanakodtam de ilyen időközönként nincs ütemezett feladat.
Majd a top-ban nézegettem hogy mi terheli a gépet de semmi változás nem történik amikor
felugrik a load.
Egy ideig nem zavart de néha már annyira magas a load hogy pár másodpercig használhatatlan a gép.
Grafikon LINK: http://kepfeltoltes.hu/view/100419/gep-load_www.kepfeltoltes.hu_.png

Bármi tippetek van azt nagyon köszönöm!

  • 2208 megtekintés

( Vladi | 2010. 04. 19., h – 22:09 )

Milyen disztró?

De csak a htop kéne. Mert van pár cronjob ami csinál ilyet. Megnézem mindjárt.

mod:
Nekem centos-en és fedorán is makewhatis, meg egy másik csinált ilyet. Azok?

>>: sys-admin.hu :<<

( egeresz | 2010. 04. 19., h – 22:13 )

a load a varakozo es futo processzek szama.
Ket fele eroforrasra szoktak varakozni: CPU-ra es diszkre.
Ha top -pal nem latszik semmi, de a load meg-meg ugrik, akkor varhatoan a load tetemes resze a diszk. 

sar -d 3 0 > megnezzukmajd

ez csak diszk terheltseg mero, es ebben az avgqu-sz szamit bele a load-ba.

( fanti | 2010. 04. 19., h – 23:03 )

Egy vicc az egész úgy jelentkezik a probléma hogy iostat,htop megáll mint a szög az egyik pillanatrol a másikra, esélyem sincs megnézni hogy mi csinálja.

( fanti | 2010. 04. 19., h – 23:12 )

Megvan........
Sikerült elkapnom az iotop-al:
23222 be/4 root 0.00 B/s 0.00 B/s 0.00 % 96.44 % [pdflush]

szuper.

kerem a kovetkezo ertekeket (cat $fname)
/proc/sys/vm/dirty_writeback_centisecs
/proc/sys/vm/dirty_expire_centiseconds
/proc/sys/vm/dirty_background_ratio
/proc/sys/vm/dirty_ratio

Milyen diszked van? (milyen diszken van a user adata, a swap)
Van-e a rendszerben fsync() hivogato? (adatbaziskezelo)

mondjuk HW beruhazas nelkul olyat lehet elerni, hogy a rendszer altalanos teljesitmenye kicsit lecsokken, de a tuskek kibirhatoak lesznek.

/proc/sys/vm/dirty_background_ratio = 5
/proc/sys/vm/dirty_expire_centisecs = 2999 (ezt kiszámolva kijön az 50percenkénti agybaj)
/proc/sys/vm/dirty_ratio = 10
/proc/sys/vm/dirty_writeback_centisecs = 499

két darab WD1500HLFS 150GB
raid1:
md0(adat) /dev/sda1 /dev/sdb1 145GB
md1(swap) /dev/sda2 /dev/sdb2 4.29GB

Mysql adatbázis van.
A saját scripjeimben nem használok fsync()-ket.

szia, vedd le a kovetkezo ket erteket:
echo "3" > /proc/sys/vm/dirty_background_ratio
echo "1500" > /proc/sys/vm/dirty_expire_centisecs

mondjuk.. de a lenyeget nem hiszem, hogy ez fogna meg

valami olyasmi van, hogy neha a mysql fsync() muvelete osszeakad valami massal is (pl ext3 filesystem commit interval) mikozben valami processz eppen memoriat szeretne, sokat egyszerre. Mondjuk epp a mysql.

nem, ez nem ujrainditasos dolog, sot, ezek az ertekek elvesznek rebootra. (bootkor a defaulttal jon fel).

Szoval nem valtozott?

Van mar eredmenye a 'sar -d' -nek? Ha van, akkor az gondolom mar rendes meretu file. Egy csucs kornyeki (elotte 5 perc utana 5 perc) lista kellene belole, hogy biztosan lassuk, a diszk (es melyik diszk) a hunyo.

sda kezd meghalni, csereld le.

nezd meg, ez ket egyforma sata diszk. Amikor a raid1 irni akar, akkor egyszerre ir mind a ket diszkre. Diszkenkent ugyan annyinak kellene lennie mindenfele ertekeknek, legfeljebb kicsi (20%) elteressel. Amikor viszont extrem service time (3 sec egy diszknel eleg extrem!) van, ott mindig csak a sda -n van, az sdb nem csinal semmit.

Kivettem a vinyót betettem egy másik masinába végig futattam rajta a hd sentinel-t
nem talált semmi problémát teljesítmény és kondicó 100% irás-olvasási sebesség, készenléti idő meg miegymás
szintén rendben.
Arra gondoltam hogy a szerverben egy másik sata portba dugom a vinyót egy másik sata kábelel hátha az volt a baj.