bsnmp a RAM

[Dan Lukes]

On 29.12.2013 18:32, Miroslav Prýmek:
> Jde mi o jakoukoli "rozumnou" metriku --
> tj. vytahnout ze snmp nejaky cislo, ktery by melo smysl sledovat - tj.
> napr. za normalnich okolnosti by to cislo melo treba oscilovat kolem
> nejake hodnoty, ale nemelo by neustale rust - to by znamenalo memory
> leak nebo nejaky jiny problem.

Otazka "co sakra vlastne sledovat" je zajimavy problem sam o sobe, 
nezavisle na otazce jak/cim to pak sledovat.

Alokaci realne pameti smysl sledovat nema, ta by se mela neustale tocit 
okolo 100%, protoze co nepouziji aplikace, to by mely pouzivat cache 
diskoveho subsystemu.

Sledovat celkove mnozstvi alokovane pameti (linearni) je problematicke 
pokud neni zatizeni toho stroej velice konstantni. Vetsina verejnych 
serveru bude v zavislosti na zatizeni alokovat dost rozdilna mnozstvi 
pameti a tyhle vykyvy budou typicky vetsi pomale vykyvy zpusobene memory 
leakem. Obzvlast, kdyz to sledujeme poscitane pres cely server.

To uz je mozna lepsi mit natypovanou pametovou narocnost konkretnich 
daemonu a nastavit jim podle toho ulimit. Pak uz jen staci sledovat, kdo 
byl systemem zastrelen pro prekroceni limitu. Ale to je dost narocny a i 
tak je to jen heuristika.

To o cem mluvis by se tak podle me dalo sledovat snad jedine v podobe 
trendu dlouhodovych prumeru. Neco jako - zaznamenavat prumerne alokovane 
mnozstvi pameti za 24 hodin (to eliminuje intradenni vykyvy zpusobene 
ruznym pouzivanim) a sledovat v delsim horizontu nekolika tydnu trend 
techto hodnot (do eliminuje vykyvy v ramci pracovniho tydne). A pokud 
tahle krivka vykazuje trvaly rust (po zignorovani lokalnich kratkodobych 
poklesu) tak vis, ze je neco spatne.

Na tom poznas, ze je neco v neporadku.

Ale je to pomerne slozitej zpusob. Sleduju ukazatel, kterej ma trochu 
podobny vlastnosti jako to co jsem popsal, je pro sledovani jednodussi, 
za cenu toho, ze nezachyti to problem dokud se nedobere do dost velkejch 
rozmeru.

Sleduju vyuziti swapu.

Postupne rostouci vyuziti swapu ukazuje na memory-leak, ale v podstate 
jakekoliv netrivialni vyuziti swapu ukazuje na problemy systemu ...


> Proste neco na zpusob metriky "pocet procesu" nebo "pocet navazanych
> spojeni" -- nejaky vesmes libovolny cislo, na kterym by se poznalo ze
> "neco neni v poradku"

Pocet procesu a pocet navazanejch spojeni je dalsi mozna vec ke 
sledovani, ale i tady musis sledovat dlouhodoby trend, nikoliv hodnotu v 
konkretnim okamziku nebo kratkem obdobi.

Sledovani kazdy z tech veci te upozorni na jinej typ problemu. Nade 
vsechnu miru rostouci pocet procesu nemusi zpusobit podstatny rust 
alokovany pameti, pocet navazanych spojeni (ja bych to ale spis videl na 
pocet otevrenejch handlu, jakejkoliv) nemusi bejt spojenej s velkym 
mnozstvim procesu.

No, a taky lze zvolit uplen jinej pristup - takovej Apachovskej (ale 
pouzivaji to i jine servery). Oni proste vedi, ze bez ohledu na 
testovani k necemu takovymu obcas stejen dojde. Apachovske synovske 
procesy proto obslouzi jen urcity pocet pozadavku a pak se ukonci. 
System tak uvolni vsechny zdroje toho procesu, vcetne "zapomenutych" a 
serverovy manager nastartuje novy, "cisty" proces.

Tim chci rict, ze nekdy muze bejt nejlepsi ten celej server proste 
preventivne jednou za cas otocit ...

Dan