Aktualni databaze vsech mereni zabira cca 4GB dat.
- Kód: Vybrat vše
[root@server3]# du -sh fvlog
3.9G fvlog
Algoritmus wattstatistik byl resen tak, ze pocital vzdy cele mereni pro danou FVE od zacatku, a to z duvodu ze by se mohly delat korekce dat, tak aby se prepocitaly i wattstatistiky a upravilo teoreticke maximum a minimum. To ale znamena ze vypocet je nad cim dal tim vetsim objemem dat a trva dele a dele. Ted tedy resim to, aby data byly z databaze vybirany ne za celou dobu mereni, ale za poslednich 30 dnu. Teoreticke maximum pracuje s oknem 10ti dnu, takze musim zacit pocitat teoreticke maximum nejmene 10 dnu pred prvnim celym desetidennim oknem, protoze se blizke sousedni dny co se tyce teoretickeho maxima vzajemne ovlivnuji, takze musim jakoby nejmene 10 dnu najet vypocet teoretickeho maxima, 10 dnu bych mel dostavat stejna data jako pri poslednim vypoctu, a pak dalsich 10 dnu uz mirne odlisna data, podle toho co prijde jako nova data. Prave o to plovouci casove okno pri kalkulaci teoretickeho maxima se to komplikuje. Vicemene tedy resim lepsi "kesovani" dat (ukladani mezivypoctu bokem) a pocitani maximalne s 30ti dny misto propoctu celych 2 let. Bude to taky pracovat tak, ze pokud nastanou nejake upravy v datech z mereni v historii, bude to zdetekovano a provede se kompletni vypocet od zacatku mereni, tedy neco co na serveru trva u brezniku, kokonina, marsova a podobnych nejdele merenych FVE asi 20 sekund. To je proste moc, pokud server jeste ma resit docela zivy HTTP provoz, kreslit "on the fly + 2min cache" rrd grafy ruznych velikosti, casovych useku, intervalu, rozsahu, rozliseni, typu... Taky planuju lepsi rozhozeni mezi geograficky oddelene servery, ktere ted mam k dispozici. Ted mezi nimi funguje pouze databazova replikace a rsync, kdyby se nahodou stalo neco s hlavnim serverem, prehodim DNS jinam a jedeme po expiraci DNS zaznamu prakticky s cerstvymi posledne znamymi daty. Nebo z maximalne den stare zalohy (rdiff-backup + mysql replikace). Chci aby jeden ze serveru slouzil vylozene pro prijem dat z mereni a treba synchronizoval a pripravoval data z eshopu jednotlivych dodavatelu, druhy by resil PHPBB, treti hlavni stranku, a ctvrty pocital veci na pozadi.. treba teoreticke maxima, atd. Jednoduse receno vice tu architekturu zclusterovatet, ale musi to byt zaroven osetreno z pohledu vypadku clusteroveho node, aby byl snadno nahraditelny a cely takto rozlozeny system se z toho nesesypal a umel se z toho zotavit a projekt dale fungoval.
No ale zpet k tem wattstatistikam ... ted to je v PHP, bylo by dobre to prepsat do C++ a zkompilovat to, v PHP je to strasne neefektivni.
Nejaka grafika:
cpuload_cpuload_370d_900x300.png
cpuusage_cpuusage_370d_900x300.png
Jsme na naprosto otresnem serverloadu (3 a vice stabilne, pricemz load 1 je uz znamka toho, ze je neco moc zle a server zacina byt v prodleve), takze otimalizuju kde se da, sem tam nastane nejaka extra spicka, viz posledni finta s navazovanim spojeni (load 250 a podobne vtipy). V červenci 2013 jsem udelal prvni radikalni rez wattstatistik. Zaroven prisel novy engine pro renderovani grafu, kdy se grafy kresli az na vyzadani a ne cronem neustale dokola cela sada vsech variant, i kdyz o ne nikdo nestoji. V souvislosti s rustem naroku na objemy dat z mereni se do toho muzu pustit za pul roku znovu a tentokrat dukladneji a udrzitelneji. To znamena to je ono 30ti denni maximalni okno, proste vic tech dat uz pro jeden vypocet nebude

Leda ze by prisly nejake jine vypocty, ale ty uz by byly zalozeny na faktu, ze dat je strasne kvantum. Navic jak se to rozlozi ta zatez i na servery bokem, alebrz decentralizace (to je to co tu vlastne vsichni resime z pohledu energie) tak to pojede jak vino. Zase prijdou jine komplikace .. no ..
PS: Dodam jen zkusenost z praxe, nebyt BTRFS, znamenal by kazdy vypadek replikace a nutnost snapshotu serverovych dat asi pulhodinovy vypadek fora (to povazuji za neakceptovatelne). S BTRFS tenhle snapshot pomoci copyonwrite trva asi 2 sekundy (kopie 5GB dat) a forum nic nepozna, krome 2s prodlevy v odpovedi serveru, kdy je databaze zamknuta. Neocenitelna vlastnost. Nicmene BTRFS za jistych okolnosti muze znacne server zbrzdit a to dost zasadne, jakmile naroste strom zavislosti pri copyonwrite a ruznych ficurach BTRFS. Tohle budu muset taky peclive uvazit kdy vyuzit vyhody BTRFS a kdy naopak uprednostnit rychlost jinych FS, napriklad ext4 apod.
Ciste technicky ..

pokud by to nekoho az tak zajimalo, tak kreslim si prubezne takove schematko, abych se v tom uplne neztratil, ale neni to jeste zcela presne a dokoncene. Je to komplikovanejsi nez to vypada

A jak se do toho pridaji oddelene servery, tak bez schematu jsem uplne mimo

mypower-web-schema.png
Nemáte oprávnění prohlížet přiložené soubory.