Ahoj 2014/1/6 Miroslav Prýmek <[email protected]>: >> 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. -- FreeBSD mailing list ([email protected]) http://www.freebsd.cz/listserv/listinfo/users-l
