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
--
FreeBSD mailing list ([email protected])
http://www.freebsd.cz/listserv/listinfo/users-l
