bsnmp a RAM

[David Pasek]

Ahoj

2014/1/6 Miroslav Prýmek <m.prymek at gmail.com>:
>> Kdybys toto chtel, tak bys to
>> mohl zkusit odhadnout podle trendu aktivni pameti.
>
> Presne tam jsem miril. Je teda zaver, ze pro hrubou kontrolu _trendu_
> by mi stacilo sledovat
>  vm.stats.vm.v_active_count + vm.stats.vm.v_wire_count  popr. jenom
> prvni z nich?
>
> Pod "hrubou kontrolou trendu" si predstavuju neco jako "poznam, ze se
> nejak podezrele splasilo MySQL a zacalo si najednou alokovat nejak moc
> pameti".

Ano. Ja si myslim, ze ano. Akorat, ze nebudes vedet, jestli je to
MySQL nebo neco jineho. Dostanes informaci, ze ubyva pamet. To je vse.
Zbytek si musis dohledat bud rucne a nebo to take zautomatizovat.

Pro trend pameti,  bych zkusil korelovat nasledujici metriky:
M_RAM_USED_KB = vm.stats.vm.v_active_count + vm.stats.vm.v_wire_count
M_ SWAP_USED_KB =memTotalSwap - memAvailSwap

tyto metriky bych prevedl na % vuci totalni fyzicke RAM a totalni
velikosti swapu.
M_RAM_USED_PCT
M_ SWAP_USED_PCT

no a pak bych se snazil nadefinovat a nastavit pozadovane warning a
error thresholdy.
Napriklad takto;
  na M_RAM_USED_PCT warning 50% error 80% - rozhodne bych si tam
nechal vatu, protoze monitorujes aktivni pametove stranky
  na M_SWAP_USED_PCT warning >0% (ale jenom tehdy, kdyz je prekrocen
error threshold M_RAM_USED_PCT) error >20% (vzdy).

U swapu je lepsi nez sledovat obsazenost, tak sledovat metriky SWAP_IN
a SWAP_OUT, ktere jsou vetsinou v KB/s za nejaky casovy interval a
rikaji vice o tom, jak se swapem pracuje.  SWAP_OUT je odswapovani
pametove stranky do swapu a SWAP_IN je logicky opacny smer. Zkus se
podivat, jesli takovouto metriku umis ve FreeBSD najit. Verim, ze si
nemusime rikat, ze je mozne si nadefinovat vlastni SNMP MIB OIDs a
namapovat to na lokalni commandy nebo scripty, tim lze pozadovane
metriky dostat pomoci SNMP, aniz by to standardni MIB obsahovala.

Podobny monitoring resim v hostovanych virtualizovanych datovych
centrech a trendy u pameti resim prave podle aktivni pameti, volne
pameti a swapu. Hypervisor je take jenom OS, jen je vice uzpusoben ke
konkretnimu ucelu :-)

Dokonce ted s kolegou delame na open-source projektu na monitoring a
korelaci infrastrukturnich parametru tohoto typu. Je to velmi
zajimave, nicmene nejdulezitejsi je prave detailne rozumet
architekture a chovani monitorovanych systemu a vytahnout z tech
systemu ty prave metriky a spravne je korelovat. Coz je presne to, co
se snazis ty v tomto konkretnim pripade s pameti na FreeBSD za vyuziti
RRDtools.

Podobna korelace a trendova analyza je potreba napriklad pro
preventivni odhad blizicich se performance problemu na diskovem
subsystemu, kde treba korelujeme pocet diskovych transakci, response
time a zatizeni fronty (device/LUN queue).  Nebo odhad prichazejich
CPU performance problemu, kde relativni vykon aplikaci na vicecestnych
systemech neni jen o MHz usage, ale i o dalsich metrikach, jako je
wait na I/O, co-scheduling wait multi-threadovych procesu, apod.
Mimochodem virtualni machine nad hypervisorem je take jen 1-n procesu.

Bohuzel ja FreeBSD dnes jiz pouzivam spise pro provoz podpurnych
aplikaci nez pro kriticke systemy, takze konkretni metriky ti musi
prozradit nekdo, kdo s FreeBSD pracuje na denni bazi a provozuje na
nem kriticke sluzby.

Takovych lidi by tady mohlo byt dost, ale ne kazdy se snazi
monitorovat a predikovat infrastrukturni problemy natolik presne.
Nekdy to proste nestoji za to, ale ja si take myslim, ze to za to
stoji. Teda alespon v tech prostredich, kde se provozuji business
critical aplikace. Tam kde ja provozuji business critical aplikace mi
tyto hodnoty dava infrastrukturni virtualizacni vrstva a tam ty
metriky, korelace a thresholdy znam, ale to uz je hodne off-topic :-)

Nicmene z high-level pohledu si myslim, ze se blizis k vytouzenemu
cili, takze vytrvej, zkousej a reportuj do konference. Treba tim
nekoho zvyklas k tomu, aby se tim zabyval take a ty spravne metriky i
korelacni vzorec najdes. A pak je to o tom si nastavit nejaky rozumny
threshold, ktery indikuje ten blizici se problem. A to je mozna to
nejtezsi.

Hodne stesti,
David.