Wattstatistiky dočasně OFF

[mypower.cz]

... dokud nedokončím novou verzi. Současná verze už bohužel nestačí z hlediska výkonu.

[JML...]

Tak tomu rozumím...
Mě běží monitoring na OLinuXinu a celý Debian a SQL je uSD kartě, a i když je rychlá tak výpočet historie a ekonomiky FVE trvá 19 sekund, přičítám to rychlosti SD karty. Bohužel jsem se nedostal k nasazení 16Gb SATA SSD, což bude znamenat úpravu bootu jádra Debianu.

Filipe můžeš zveřejnit jak mohutné jsou databáze?
Jak budeš algoritmy optimalizovat, nějakou kumulací?
Zajímá mě to čistě z technického hlediska zpracování takové hromady dat.

[mypower.cz]

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:

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

[JML...]

To už není masakr ale kramasax!
Když se podívám na CPU Load... to je asi od úloh pod Cronem. Binárka v C by to urychlila bez interpretace PHPkem, ale stejně to je tahání SQL dat.
To je fyzickej stroj nebo virtualizovanej? Protože musí mít velkou RAMku, když stále prolézá tam a zpátky takovou SQL, nebo má rychlej swap?
Něco podobnýho mám na MS NAV serverech, ale to je jinde než Deb distro.

[mypower.cz]

Hlavni server je ted na VPS s 2GB ram a jednim "Intel(R) Xeon(R) CPU X5675 @ 3.07GHz" podle lshw, ale je tam SSD disk, takze zase na diskove IO je to dost svizne, pokud to teda zrovna nedrti wattstatistiky, nebo nejaky vnejsi vliv. Nektere z replikacnich zaloznich serveru jsou na tom lepe z pohledu ram i poctu CPU, ale nebyla to doted priorita to plnohodnotne rozhodit. Z kazdeho replikacniho serveru lze udelat plnohodnotny server az ale po manualnim zasahu.

[drama]

Proč nestačí malá tabulka ve které by byl pro daný den sloupec pro každou měřenou FV? Za dva roky by měla velikost 365*2*PočetMěřenýchFVE*sizeof(int). Nad tím by MAX či SUM byl rychlostí blesku...

[střídač]

Ono by taky stačilo přenést veškerou logiku tam kde je jí nejlépe, což je databáte. Tam je již k tomu určených rutin v C dostatek a optimalizovány. Na php, když již musí být, tak jen otevřít spojení s databází, polknout data a následně vyvrhnout do prostoru. Určitě by se tomu železu dostatečně ulevilo.

[mypower.cz]

Ono by taky stačilo přenést veškerou logiku tam kde je jí nejlépe, což je databáte. Tam je již k tomu určených rutin v C dostatek a optimalizovány. Na php, když již musí být, tak jen otevřít spojení s databází, polknout data a následně vyvrhnout do prostoru. Určitě by se tomu železu dostatečně ulevilo.

Výpočet wattstatistik je několik vnořených selectů v jednom běhu, kdy každý rodičovský pracuje s násobně nižším, předpočítaným objemem dat. Databáze pracuje asi 8 sekund u Kokonínské FVE. 90% výpočtů a průměrování řeší databáze právě kvůli spoléhání se na optimalizované algoritmy v samotném engine databázového serveru. Výsledkem jsou hotové a dle času setříděné hodinové wattstatistiky. (Xlet*365*24 řádků) Tento výsledek vezme PHP a ve smyčce dopočítá součty za dny, měsíce a roky, které uloží bokem. Také se v PHP z připravených hodinových výsledků dopočítá to co by pro databázi už bylo docela náročné na implementaci pomocí jednoduchého SQL dotazu, a to jsou teoretické maxima a minima, kdy se hýbeme s desetidenním časovým oknem a hledáme v něm nejsilnější a nejslabší hodiny z hlediska výkonu, ze kterých rekonstruujeme nejvýkonnější (teoretické maximum - ThMAX) a nejslabší (teoretické minimum - ThMIN) dny. Celé je to uloženo do souboru jako serializované pole (krátký plaintext soubor s hotovými daty), odkud to jde do wattstatistik na web.

V současném stavu, kdy limituju práci výpočtu pouze na poslední měsíc jsem dle včerejších testů prováděných pozdě v noci dosáhl výsledku asi kolem 0.3 sekundy pro výpočet nad posledními 30ti dny. Teď řeším vlastně zcela korektní navázání takového částečného výpočtu na předtím spočítaná data (merge) a drobnou ale nezbytnou úpravu konfigurace všech FVE s wattstatistikama.

Pak mě čeká zkontrolovat správnost výpočtu ThMAX a ThMIN

C je v tomto případě velmi vhodné pro to, že smyčka v PHP provádí stále dokola tisíce zbytných operací nad výpočtem ThMAX a ThMIN, které by se v C daly řešit daleko efektivněji přímo zkompilováním do strojového kódu a bez režie spojené s interpretováním bytekódu programu, psaném v PHP jen proto, že vytvořit takový SQL dotaz, který by řešil totéž si dost nedokážu představit, ale určitě by to nějaký SQL guru dal .

V takové smyčce je pak jasné, že i když řešíme sice triviální úkol, tak se každé odseknutí zbytné režie a tím zrychlení i o malý čas může projevit dost citelně v momentě, kdy smyčka proběhne třeba desettisíckrát. 10000x0.001s úspora = 10s * 6 FVE = více než minuta vytíženého serveru, která se konat nebude a přitom dostaneme stejný výsledek, který potřebujeme, jen za nižších nároků na výkon serveru.

Proč nestačí malá tabulka ve které by byl pro daný den sloupec pro každou měřenou FV? Za dva roky by měla velikost 365*2*PočetMěřenýchFVE*sizeof(int). Nad tím by MAX či SUM byl rychlostí blesku...

Ta malá tabulka vzniká právě po tom obrovském přepočtu z dvou/pětiminutových vzorků proudů, napětí, výkonů, korekcí a různých souvislostí mezi nimi a závislostmi na výkonech (do / z baterií / z FV / do spotřeby = 3 veličiny měřené dvěma čidly = výpočet na straně serveru). Jen je potřeba ji nepočítat stále znovu nad daty, které se nezměnily a kterých je obvykle 99%, zbytek byl spočítán minule.

[drama]

Dobrá, v případě FVE bez automatického generování denní výroby tomu výpočtu rozumím, ale proč si to nevypočítat a neuložit jednou denně o půlnoci do té mikrotabulky? Já to vlastně dělám také tak pro generování http://postolka.klikva.net/denni-vyroba.png

[mypower.cz]

No právě to teď dělám. Jen kvůli ThMax a ThMin to nemůžu dělat jen za poslední den, ale za posledních 30 dnů, což výkonnostně je už doufám na delší dobu přijatelné:)

[vata]

Zdravím, tak tak, tabulek s agregovanými daty se mi to začíná v mé db taky jenom hemžit Db si je vyrábí vždy za poslední den a u některých kategorií (např. zrovna spotřeba) jednou za hodinu. Protože v mé db mám i data z elektroměrů a zajímá mě okamžitá spotřeba, musela jsem řešit i tento typ dopočtu kdy je nutné srovnávat data dvou vzorků, to už bylo nad tabulkou o téměř půl miliónu záznamů prakticky nemožné počítat v reálném čase. U složitějších výpočtů jsem rezignovala na čisté SQL a používám tu implementaci T-SQL v mysql (v uložených procedurách, nevím teď, jak se tomu jazyku říká). Dá se to pak po sobě s odstupem i přečíst.
Protože jsem si nechtěla komplikovat situaci, prohlásila jsem, že vizualizace agregovaných dat může být na klientu hodinu stará, což v praxi ale vůbec nevadí. Nejnáročnější jsou výpočty cyklů baterie, ty počítám jenom jednou denně.
No a nad předpočítanými daty švihá vizualizace jedna radost, a když se k tomu ještě přidá kouzlo vícero asynchronně volaných ajaxových volání o různá data, je to docela použitelné
Jenže znáte to, jak se člověk ponoří do světa optimalizací, je dost těžké přestat

[mypower.cz]

No a ja dodam jen info, ze vim ze mi to "trva 100 let", ale mam na to denne pres dalsi povinnosti strasne malo casu a tak na tom makam casto pozde do noci. Jsem ve fazi kdy navazu neuplny propocet ThMIN a ThMAX na predem provedeny propocet a dospeju tim ve vysledku ke kompletnimu propoctu, otestuju na svych datech, na ostatnich datech, hodim to na produkcni server a udivim co to udela a hotovo. Tak snad pres vikend uz to pojede a dopocitaji se wattstatistiky i ty, ktere se nespocitaly, respektive beztak musim propocist wattstatistiky u vsech znovu, protoze se zmenil i format predulozenych propoctu, takze mazec, ale uz se to blizi. Samotneho me to dost irituje, ze to jeste nejede a ze nevim kolik jsem vyrobil.

Pokud bude zajem, dam sem i log z vystupu wattstatistik, ma-li nekdo zajem o detaily jak jsem to nakonec teda vymyslel, aby to jelo snad na hodne dlouho. I kdyz obavam se ze beztak i s timto zpusobem budu muset z databaze mereni odsekavat alespon roky (starsi data nez 2 roky treba), jinak to zacne byt jako jedna velka tabulka na FVE taky dost neunosne a server by to bud musel drzet v pameti (alespon index od toho), nebo nevim. Ale vice mensich tabulek je urcite lepsi nez jedna giganticka.

[vata]

Mimochodem, jestli říkáš, že server jede na SSD - řešíš nějak optimalizaci zápisových operací? Já už něco vymýšlela - celý den zapisuju do RAM tabulky odkud se data až v noci přesunou do hlavní a dotazům, které potřebují všechno, podsunu zkrátka union.

[mypower.cz]

Veci kolem SQL jsou v rezii MySQL, veci kolem PHP serializovanych dat v souborech na BTRFS filesystemu, tak s temi pracuji zasadne v pameti - nactu asi 300kb komprimovanych dat (za 2 roky = 2*365*24 radku), v pameti spocitam, ulozim cely vysledek v jedne - z pohledu programu v PHP blokove operaci [file_put_contents()] a optimalizace kolem raw zapisu na SSD, to uz resi linuxove jadro, ktere bezi pod vmware, ktere bezi pod dalsim linuxovym jadrem, ktere si to uz resi kdo vi jak

[vata]

no však to se pozná časem Nicméně je fakt, že můj SSD si ani po roce nonstop po této stránce neoptimalizovaného provozu nestěžuje... Taky to buduju s myšlenkou na maliny a jejich SD karty, což je samozřejmě jiná "liga"...

[mypower.cz]

Teorie: Mějme okno 10 po sobě následujících dnů, ve kterém jsme v každém dni v deset hodin dopoledne zjistili výrobu ve watthodinách. Někdy co nejblíže kolem 20.8.2012 (začátek mého 24V archivu)

Kód: Vybrat vše

  ["whin"]=>
  array(10) {
    [0]=>float(154.543)
    [1]=>float(232.298)
    [2]=>float(182.155)
    [3]=>float(320.693)
    [4]=>float(178.628)
    [5]=>float(56.173)
    [6]=>float(155.018)
    [7]=>float(155.778)
    [8]=>float(158.195)
    [9]=>float(153.335)
  }

Z těchto hodnot získávám maximum a minimum - což mi dá teoretické maximum a minimum pro desátou hodinu zjištěné z okna sousedních 10 dnů co nejblíže kolem zjišťovaného datumu 20.8.2012 a v každém dni nás zajímá vždy jen 10. hodina.

Jelikož nový algoritmus je dost rychlý, přidal jsem ještě teoretický průměr z těchto hodnot a ptám se, dokud to řeším, zdali nás zajímá ještě něco jiného, třeba maximální a minimální rozptyl.... ? Nebo napadá někoho nějaký speciální výpočet nad takto připravenými daty, který bych nechal běhat nad daty z měřených FVE? To časové okno 10 dnů se pro každý zjišťovaný den samozřejmě posouvá, takže výsledky se průběžně pomalu mění avšak někdy i ostřeji. Rád bych teoretická maxima a minima časem kreslil i do grafů, což není už komplikované a bylo by to určitě zajímavé sledovat, jak se to hýbe a v jakých souvislostech. Dalo by to další rozměr pohledu na naše FVE.

[mypower.cz]

hm tak algoritmus je tak rychly, ze pri vypoctu teoretickeho prumeru, minima, maxima v kazde hodine pro 5 ruznych vykonu (FV1, FV2, BAT, DCOUT, ACOUT) jsem na 1320.5 zaznamech za sekundu u sebe na notebooku. Jeden zaznam je jedna hodina behem dne, pro kterou po vypoctu zname teoreticke maximum, minimum a prumer pro FV1, FV2, BAT, DCOUT, ACOUT. Vypocet celeho meho archivu od 20.8.2012 do dnes (mereno ve 2minutovych intervalech proud a napeti na ruznych mistech) trva 12 sekund, cele to zabere 33 mega ram.

Stav predtim byl cca 1000 zaznamu teoreticke minimum a maximum a jen pro udaj FVIN, tedy vyrobu, a asi 60 mega v ram.

Vzhledem k tomu ze to nebude dokola pocitat cely archiv ale vzdy jen poslednich 30 dnu, tak to vidim velmi dobre Cely archiv bude pocitan vzdy jen pri vyjimecnych situacich, napriklad nekonzistence dat, zmena merenych hodnot, atd.

EDIT: Kdyby to nebylo v PHP ale v C, tak je to 10x rychlejsi

[#]EDIT2 [23/02/2014 01:42]: Zajimava finta. Kdyz pocitam teoreticke maximum (hybu s desetidennim oknem) pozpatku, tedy ne od zacatku archivu ale od konce smerem k zacatku, tak se vlastne automaticky s vypoctem muzu zastavit v momente, kdy mi data zacnou s vypoctem z minula nekolik dnu po sobe vychazet stejne. To znamena ze jsem narazil na puvodni data a teoreticke vypocty uz jsou nemenne. To znamena vylepseni, ze neni potreba tahat z databaze poslednich 30 dnu a ty kalkulovat znovu ale staci skutecne jen nove data a pak na to pustit funkci vypoctu teoretickeho maxima a ona si na zaklade teto vlastnosti uz poradi a sama se zastavi co nejdrive to bude vhodne ... To je velmi zajimave .. Uz to velmi brzy pojede a bude to obohaceno o dosti zajimave funkce, napriklad pokud mame nalezene v dane hodine nejake teoreticke maximum, tak se bude dat kliknutim zjistit kdy to teoreticke maximum nastalo v danem desetidennim okne a z ceho ten algoritmus vlastne ten teoreticky nejvykonnejsi den seskladal. Coz se bude dat i zvizualizovat .. hmmm ..

[Frenky]

Admin zprovoznil dnes watt statistiky, DĚKUJEME.
Blíží se týden se slunečným počasím, takže ať se křivky kroutí nahoru a ať se nám do statistik dostávají samí vembloudi

[mypower.cz]

Zatim bych jeste neslavil. Jeste to neni uplne ono. Dam vedet jak bude hotovo. Spise ted asi budou nasledovat mozna vypadky, protoze uz jsem pravda dneska chtel nove wattstatistiky nasadit na produkcni server ale nedopadlo to dobre. Vypocty sice bezi uz bokem mimo hlavni server na 4jadrovem miniPC ve Zline, s pripojenim k beznemu netu (neni potreba nic rychleho, protoze se prenasi mala data (vysledky vypoctu) a pracuje lokalne s replikovanou databazi).

Budu tam muset presunout jeste asi i rendering grafu a znacne vyoptimalizovat homepage, protoze dnesni vypadky jsou dusledkem nasazeni novych wattstatistik, ktere se samozrejme u me na notebooku chovaji ponekud jinak nez na vytizenem produkcnim serveru pod plnou palbou uzivatelu. Souvisi to nejen s wattstatistikami ale i s homepage, protoze na tu se data z wattstatistik pouzivaji, je to uz dosti komplikovane...

Bohuzel cela tahle sranda mypower.cz si zacina vyzadovat me extremni casove vytizeni

Mala ochutnavka:



Vic k tomu pozdeji v samostatnem prispevku (clanku).

[mypower.cz]

Info: Server je v tuto chvili (6 rano) takovy ne uplne funkcni.. Forum funguje zrejme bez problemu, melo by to byt o hodne rychlejsi ted (pokud nekdo pocituje zrychleni odezvy, prosim o potvrzeni, pripadne vyvraceni meho dojmu, ale load na serveru je ted uzasnych 0.13 minutovy prumer, ale pravda skoro nikdo tu neni , takze server nema co delat ) Wattstatistiky jsou stale zatim schovane, neni bezpecne to mit zatim online, shop nejede (zatim nevim proc) ale pojede, a pokracovani a dokonceni jak se vyspim, protoze uz nemuzu ...