bsnmp a RAM

[Miroslav Prýmek]

Dne 29. prosince 2013 22:40 Dan Lukes <dan na obluda.cz> napsal(a):
> Sledovat celkove mnozstvi alokovane pameti (linearni) je problematicke pokud
> neni zatizeni toho stroej velice konstantni.

Pro me je ted momentalne asi nejproblematictejsi se vubec vyznat v
tom, co ktery nastroj vlastne ukazuje pod jakym nazvem :)

Napr. to ucd mi dava:
UCD-SNMP-MIB::memErrorName.0 = STRING: swap
UCD-SNMP-MIB::memTotalSwap.0 = INTEGER: 4194176 kB
UCD-SNMP-MIB::memAvailSwap.0 = INTEGER: 4194176 kB
UCD-SNMP-MIB::memTotalReal.0 = INTEGER: 8333220 kB
UCD-SNMP-MIB::memAvailReal.0 = INTEGER: 687100 kB
UCD-SNMP-MIB::memTotalFree.0 = INTEGER: 687100 kB
UCD-SNMP-MIB::memMinimumSwap.0 = INTEGER: 16000 kB
UCD-SNMP-MIB::memShared.0 = INTEGER: 361760 kB
UCD-SNMP-MIB::memBuffer.0 = INTEGER: 843248 kB
UCD-SNMP-MIB::memCached.0 = INTEGER: 0 kB
UCD-SNMP-MIB::memSwapError.0 = INTEGER: noError(0)
UCD-SNMP-MIB::memSwapErrorMsg.0 = STRING:

Swap je jasnej - celkem k dispozici a nepouzito. Rozdil je objem
pouziteho swapu a mel by se drzet nizko. BTW, pokud jsem si dobre
vsimnul, v tomhle se FBSD lisi od Linuxu, ktery swap pouziva
"preventivne", takze se na nule nedrzi ani kdyz (jeste) neni potreba.
V tomhle je (z hlediska monitoringu) FBSD sympatictejsi ;)

Cisla ohledne RAM ale moc nechapu... Ciste z nazvu hadam asi takhle:
TotalReal by mela byt asi celkova (fyzicka, instalovana) RAM.
AvailReal fyzicka, naprosto nevyuzita pamet. Cim se lisi od TotalFree netusim...
Shared snad pamet sdilena mezi procesy, takze hlavne binarky.
Buffer hlavne diskova cache.

Chtel bych se nejak dopocitat k pameti, kterou si procesy postupne
alokuji, ale nejak mi to teda z techto cisel nevychazi...

TotalReal - AvailReal - Buffer - Shared = 8G - 0.7G - 0.8G - 0.4G =~ 6G
V top:
Mem: 327M Active, 5884M Inact, 1036M Wired, 823M Buf, 644M Free

Kdyby tech 5.8G bylo v TotalFree, tak bych tomu rozumel - pak by cca
200M mely dynamicky naalokovany procesy. Takhle mi to ale moc smysl
nedava...

Zatim nemam cas ani chut studovat zdrojaky ucd, ale casem to asi budu
muset udelat, jestli chci tem cislum aspon zhruba porozumet... Takze
kdyz se vratim na zacatek:

Dne 29. prosince 2013 22:40 Dan Lukes <dan na obluda.cz> napsal(a):
> Sledovat celkove mnozstvi alokovane pameti (linearni)

Jak presne se k tomu cislu dopracovat?
vm.stats.vm.v_active_count + vm.stats.vm.v_wire_count  ?

Dne 29. prosince 2013 22:40 Dan Lukes <dan na obluda.cz> napsal(a):
> 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 je asi dobry reseni, ale pro mne zbytecne pracny - spravuju
systemy, ktery jsou vetsinou spis naddimenzovany, takze nejakej narust
vlivem memory leaku apod. mi tragicky nevadi a funkcnost nehrozuje,
spis bych o nem jenom proste chtel vedet :)

Dne 29. prosince 2013 22:40 Dan Lukes <dan na obluda.cz> napsal(a):
> 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.

Jo, takovou nejakou predstavu jsem mel. Data ukladam do RRD, takze
prumery pres delsi obdobi pro me nijak slozity nejsou. Dokonce ani moc
nepotrebuju nejaky vypocty, uplne by mi stacilo, kdybych se podival na
rekneme tydenni graf a mohl rict "Ha! Tady ten graf nam porad roste.
Co tototo?" :)

diky za podnety

Mirek