linux debian - magas load average - indok?

Linux-haladó

Tisztelt Fórumtársaim!

A szerveren naponta 1x felmegy 7-8 fölé a load average,az utóbbi időben 3x is,de néha több napig.
Átlagban elég alacsony a LA, amikor felmegy nem a processzor miatt,hanem az IO műveletek miatt.
A gépen szoftvered raid1 van.
Ilyenkor nem megy fel a memória használat,sem a CPU használat,csak IO művelet van.

iotop se adott értelmes választ, maga a TOTAL READ/WRITE nagyon magas,de egyik processz sem az.

Újrainditás követően is felmegy az LA,amikor ez az 5-10-15-20 perce van.

Kiírattam a blokkokat,és aszerint szűrtem syslogból,de csak kjournald-t láttam,ami elvileg nem kell számításba venni. Attól nem lehet nagy az LA a cikkek szerint, írtak valami noatime-ot,hogy tegyem be fstab-ba,vagy mountoljam úgy fel, most bevan kapcsolva,de ugyanaz.

Szeretnék elindulási irányt kérni tőletek,hogy merre keresgéljem az okát ennek?

Muninról képeket itt tudjátok megnézni:
http://imgur.com/a/VlvRt#4

Köszönöm a válaszokat

  • 6075 megtekintés

( Dacr (nem ellenőrzött) | 2013. 08. 10., szo – 20:13 )

Egy _tipp_:
munin disk pluginek csokra. Több esetben is tapasztaltunk már hasonlót miatta. A munin rajzolások igencsak tudnak szépeket művelni, ha fűfavirág be van téve neki (főleg, ha nem erőmű van alatta). A képeid közül kitűnik, hogy a munin processing time-ban nem csak időnként van kimaradás, hanem szinte folyamatosan hiányos a mérés. Én futnék egy kört a munin körül.

Én megnézném, hogy valami locate/updatedb-féleség nincs-e aktivizálva. Újabban lehet úgy ütemezni a kis drágát, hogy csak akkor fusson, ha alacsony a gép terhelése viszont ha az atime nincs letiltva, akkor rövid ideig képes ilyen csúfságok elkövetésére is.
Persze csak mint ötlet, nem állíthatom, hogy ez a megoldás.
Mindenesetre a crontabok környékén körülnéznék alaposabban, illetve ha van process accounting a gépen, akkor abban megnézném, hogy az adott időszakokban mi minden volt aktív.
Ha tényleg a kjournal+atime okozza a magas loadot, akkor előtte valaminek végig kellett szaladnia a két diszkeden és belenézni a fájlokba.

Alig van crontab beállítva, szóval ez sajnos nem probléma, bárcsak ilyen egyszerű lenne :(

Az utánanéztem az updatedb bejegyzéseket, nem találtam semmit, minden default,és nincs semmi bekapcsolva aminek nem kellene, annyi hogy nem egy időbe fut,hanem így randomba, valamikor éjfélkor valami délelött délután.

"Ha tényleg a kjournal+atime okozza a magas loadot, akkor előtte valaminek végig kellett szaladnia a két diszkeden és belenézni a fájlokba."

Ezt nem teljesen értem, mit értesz az alatt,hogy végig szalad?
Még a kjournak nem nagyon néztem utána, de az az ext3 naplózó fájlrendszer kernel része,de hogy mit naplóz,meg ilyeneket azt nem tudom.
Erről tudsz valami konkrétabbat mondani?

Végigszalad=
Pl. azt, amit az updatedb művel: végigolvassa az összes(? ez nem igaz, de a példa szempontjából nincs jelentősége) fájlokat és indexet készít róluk. Viszont... ha nincs noatime a mount opciók között, akkor minden fájlhozzáférés (úgy emlékszem, minden open, de ez nem 100%) generál egy írást is, amivel a rendszer rögzíti az utolsó hozzáférés időpontját.
A kjournald meg az ext3 journal írását/szinkronizálását/etc végzi - ha mégsem, akkor valaki úgyis kijavít. ;)

Gondolom nem friss telepítésről beszélünk. Mióta csinálja? Volt valami frissítés, vagy nagyobb változtatás?
Distro, kernel, stb?
Azért a 12:00 előtti load idején az apache is kúszik felfelé és a tűzfal is teker.
Mi fut rajta?
Load idején egy tcpdump lehet, hogy elárulna pár dolgot.

2 hónapos telepítésről van szó,és kb 1 hónapja csinálja.
Debian, 2.6.32-5-amd64

apache2,mysql,postgresql,postfix,courier és társai,ftp,openvpn de amikor a loadaverage high,akkor kilőttem minden ilyen service-t.

A legfurcsább az volt,amikor a történet egyikén újrainditottam a gépet,és rá amikor bekapcsolt rá 2 másodpercre ugyanaz a LA volt(~7.5).
A TCPDumport kifogom próbálni, köszönöm a tippet.

Semmi változás nem volt,debian 6, konkrétan semmi egyik nap jó volt,másiknap nem.

A szolgáltatónak írtam,és azt mondták,hogy nem lehet kompatibilitási probléma, más nem jelezte. (Bérelt gép,blade)

( Fisher v | 2013. 08. 10., szo – 20:39 )

Az atop ment historikus adatkat. A /etc/default/atop vagy /etc/init.d/atop scriptekben lehet állítani a mintavételezést, az állítsd be jó fürgére (30 sec mondjuk kezdésnek, de ilyenkor tolja ám a logot, hely legyen neki), és hátha.

az atop győzött, mysqld volt a bűnös mindenesetben.
atop -a logfájl és ott t-vel lapozgatva pirossal megjelent a raid merevlemezek és alatta csökkenő sorrendbe mysqld és kjournald

Nagyon köszönöm szépen!

illetve még egy kérdés,ti mit szoktatok arra használni,hogy a mysql ne őlje le a gépet?

Én régen csináltam egy perl scriptet ami mindig lekérdezte hogy melyik fut x percnél tovább,és megkérte szépen,hogy állítsa le, ennél van humánusabb módszer?

Limitálni a lekérdezések által használható erőforrásokat - sajna csak az Oracle RDBMS-t ismertem ilyen téren, MySQL esetében csak találgatok, hogy talán a mysqld.conf környékén lehet keresgélni.
De attól tartok, hogy ha nincs összefüggés az adatbázisban folyó műveletek és a kliensek forgalma közt, akkor valami karbantartó dolog futhat a háttérben, amit nem célszerű agyonvágni.

Ez nem humánusabb egyébként, csak "kulturáltabb" ;)

SlowQuery logban érdemes lehet nézelődni. Első körben a lekérdezéseket kéne optimalizálni, ahol nem muszáj, ott ne fusson select *, indexet meglesni, tenni, ha nincs és szükséges, stb.
AZtán persze vannak mysql konfigban elvégezhető tuningok is, Google rengeteg találatot adhat rá (amikkel azért óvatosan érdemes bánni).

( lajos22 | 2013. 08. 11., v – 21:47 )

Bind nem fut?

Esetleg valaki rátenyerelt az F5-re és a MySQL tekeri a hdd-t, esetleg az apache teszi ugyanezt...

Vagy... ISPConfig ? abban van egy script ami végig tekeri az összes logot és át teszi adatbázisba.

Szerk:
"Újrainditás követően is felmegy az LA,amikor ez az 5-10-15-20 perce van."
Erre még az jutott eszembe: töröld az apache és a mysql bin logjait. Nekem volt már, hogy ezek okoztak nagy gubancot.

--
openSUSE 12.2 x86_64