360-as load

[quote:c6c5b9ab58="broven"][quote:c6c5b9ab58="LiRul"]A munin user valoban tagja a procfs-t lato csoportnak, de a munin user elsodleges groupja a munin group, s nem a procfsview.

Ez miért baj? Ja, hogy akkor munin userként, és munin csoporttal akarja megnézni?

Rátapintottál a lényegre.

Miliyen pluginokat írtál már hozzá? És milyen licence alatt állnak ezek? ;)

Nah, hogy ontopic is legyek, feny derult a $topic beli terheles okara. Egy igen ganyul megirt oldal mysql select query-jei egyik tablabol (amiben >210e rekord volt) esetenkent 4-5 mp-ig is eltartottak. Namost jottek a userek es megrohantak az oldalt, a mysqld pedig felzabalta a memoriat. Most hogy ez kiderult (nagy segitseg volt a munin es a mysql slow queries statisztika), optimalizaltak picit a kodon, a 210e rekordbol maradt ~30e, egybol megemberelte magat a masina. A slow queries stat is sokkal szebb kepet mutat.

Na feltettem munin-t. http://www.linpro.no/projects/munin/ most generalja a szep csártokat, csak sajnos van 1-2 dolog amit nem tud kinyerni (procfs-bol), mert perm denied van (grsec procfs restrict miatt gondolom), holott ha en megnezem a munin user mindent le tud kerdezni (betettem abba a groupba aki latja a procfs dolgait).

[quote:7b4b538c3f="broven"]Az az... ha kell plugin, csak szolj, irok egyet :D

Egy lista esetleg, hogy mirol van mar kesz plugin? :D

[quote:7b4b538c3f="broven"]Alapbol asszem nobody-ként futnak a scriptek, de a conf.d-ben beállíthatod minden pluginra, hogy milyen userként futtassa.

Thx, ez egy tarball-bol felrakott /usr/local/munin alatt levo verzio. Ilyenekkel van tele a munin-node.log:
[code:1:7b4b538c3f]/usr/local/munin/etc/munin/plugins/open_files: /proc/sys/fs/file-nr: Permission denied
/usr/local/munin/etc/munin/plugins/open_inodes: /proc/sys/fs/inode-nr: Permission denied[/code:1:7b4b538c3f]
A munin/etc/plugin-conf.d/ dirben van egy conf file, abban (tobbek kozott ez all):
[code:1:7b4b538c3f][open_*]
user munin[/code:1:7b4b538c3f]
Vagy nem igy kellene megadni?

[quote:e89724748a="LiRul"]
[code:1:e89724748a]/usr/local/munin/etc/munin/plugins/open_files: /proc/sys/fs/file-nr: Permission denied
/usr/local/munin/etc/munin/plugins/open_inodes: /proc/sys/fs/inode-nr: Permission denied[/code:1:e89724748a]

Kedves supportor tarsaknak hala (cstamas,veszig) rajottem, hogy i r lame ;) A munin user valoban tagja a procfs-t lato csoportnak, de a munin user elsodleges groupja a munin group, s nem a procfsview. Emigyen a megoldas az lett, hogy:
[code:1:e89724748a][open_*]
user munin
group procfsview[/code:1:e89724748a]
A masik lehetoseg pedig az lett volna, hogy a munin user primary groupjat hozzaadni (tehat a csoportot!) a procfsview csoporthoz.

Nah lássátok feleim az alábbi linket, ez ma reggel történt, a gép kapott egy ctrl+alt+del-t, azóta csend van. De mi a bánat csinál ilyen terhelést?!

load_360.png

A masina egy P3 800, fél giga rammal, http/smtp/pop3 forgalommal. A normális nappali load 2 és 8 között mozog, éjjel 0.5. Jah egy sima woodyról van szó. Logban csak a következõk vannak:

[code:1:217dbd19c4]kernel: __alloc_pages: 0-order allocation failed (gfp=0xf0/0)[/code:1:217dbd19c4]

A memóriát valami csutkára megette, azt egy másik stat-on látom.

[quote:169947eb0e="cheeky"]Ez igen, LiRul, nem apróztad el... ;)

El sem tudom képzelni, ez az egyszerû P3 hogy bírta ilyen sokáig... :-o Normál esetben már 300-as loadnál kifekszik.

[quote:169947eb0e="cheeky"]Nekem csak olyan 500 körülig sikerült jutnom, igaz, az egy Sun 15k volt, szal azért az sem semmi. Mellesleg ott is memóriatúlfogyasztás állt fenn, plusz a tcp stack puffereinek teljes elhasználása, mire bejött pár perc alatt még úgy 10000 connection request... :)

Na ekkor váltott node-ot a cluster...

Azt mondod DoS?

[quote:adffab9de8="cheeky"]Amúgy milyen kernelt használsz pontosan?

2.4.27-lck1-grsec2

lck patch-ben Molnar Ingo O(1) utemezoje van portolva 2.4-es szeriahoz. Valjak meg tole?

[quote:6c94e8e37e="cheeky"]Nem okvetlenül, de megeshet az is... Persze lehet hibás kliens viselkedés is, esetemben ez inkább a jellemző, a J2EE container ha be tud csatlakozni az adatbázis listenerhez, de attól hibás státuszt kap vissza, akkor sajna percenként 4-5 ezerszer próbálkozik... :)

Ahh ilyen nalunk nem jatszik, nincs fent semmilyen java-s cucc szerencsere. :)

[quote:6c94e8e37e="cheeky"]Mondjuk nem tudom, esetedben szerintem inkább a memóriaelhasználódás lehetett az ok. Nem tudsz processz statisztikát arra az időszakra? Hátha vmi megszaladt, és sokat fork-olt, abból kiderülhet vmi...

Sajnos nincs ilyen melysegu statisztika, ez lesz a kovetkezo, hogy felallitok valamit. Esetleg otlet erre, hogy milyen progi lenne jo? broven munin parti azt tudom :D

[quote:6a25da82d0="cheeky"]Ez nem ütemező, hanem VM gond, a 2.4.10-re volt sok ilyen hiba, és mostanában a 2.4.27-el tért vissza, a VM módosításokkal, és az OOM killer nyúzásával...

Ahh igazad van, emlekszem az OOM killer koruli vitakra. 2.6-ra valo valtast ezen a gepen addig nem szeretnem megejteni, amig woody van rajta. Probaljam 2.4.29-cel? Csak ahhoz meg nincs lck, viszont grsec igen. :)

[quote:6a25da82d0="cheeky"]Amúgy a tapasztalatok szerint sokak egyszerűen annyival oldották meg, hogy több swap-ot adtak a rendszerhez.

Sajnos dugig vannak a particiok, nem igazan tudom atalakitani. Amugy 1G swap van most.

[quote:6a25da82d0="cheeky"]Persze ez csak elfedi a problémát, inkább ki kellene deríteni, mi szaladt meg.

Jaja absolute igaz.

[quote:b72dbcffc4="vmiklos"]te, nezd meg jobban. ez imho "csak" 360 :wink:

Nem tudom, de a "k" ezret szokott jelenteni...

[quote:a1ff9e4d25="vmiklos"][quote:a1ff9e4d25="LiRul"][quote:a1ff9e4d25="vmiklos"]te, nezd meg jobban. ez imho "csak" 360 :wink:

Nem tudom, de a "k" ezret szokott jelenteni...

es tole balra ott van, h mit mutat (load * 10) :wink:

Ohh fukk :-)) Tenyleg, najo akkor modositani kene a topic cimet :) de ettol a kerdes meg kerdes, hogy mit tudnek tenni. cheeky neked thx az eddigi helpet!

[quote:e3ebc61d1f="cheeky"]Hát, ha már grsec, akkor első tipp az exec logging, loggol, mint az állat, de tuti kiderül, mi van ilyenkor.... ;)
Mondjuk előbb megpróbálkoznék a hálózati logokból kibogarászni, hogy melyik service-t tömhették meg alaposabban...

Uhh execlog az durva :) egyszer probaltam ki egy sima lan-os http szerveren es egy nap eleg volt, hogy megtomje a /var particiot :) persze erre van a FLOODTIME es FLOODBURST grsec opcio, de ha lelimitalom, nem tudom kiderul-e mi nyomul nagyon. hmm