abclinuxu.cz AbcLinuxu.cz itbiz.cz ITBiz.cz HDmag.cz HDmag.cz abcprace.cz AbcPráce.cz
AbcLinuxu hledá autory!
Inzerujte na AbcPráce.cz od 950 Kč
Rozšířené hledání
×

včera 13:11 | Nová verze

Po téměř dvou letech byla vydána nová verze 4.0 linuxové distribuce Audiophile Linux (též AP-Linux-V4). Tato distribuce vychází z Arch Linuxu, používá systemd, správce oken Fluxbox a vlastní real-time jádro pro nižší latence. Z novinek můžeme jmenovat podporu nových procesorů Intel Skylake a Kaby Lake nebo možnost instalace vedle jiných OS na stejný disk. Pokud se zajímáte o přehrávání hudby v Linuxu, doporučuji návštěvu webu této

… více »
Blaazen | Komentářů: 0
27.4. 18:55 | Nová verze

Byla vydána nová stabilní verze 1.9 (1.9.818.44) webového prohlížeče Vivaldi (Wikipedie). Z novinek vývojáři zdůrazňují podporu nového vyhledávače Ecosia. Ten z příjmů z reklam podporuje výsadbu stromů po celém světě (YouTube). Nově lze přeskupovat ikonky rozšíření nebo řadit poznámky. Nejnovější Vivaldi je postaveno na Chromiu 58.0.3029.82.

Ladislav Hagara | Komentářů: 19
27.4. 17:00 | Nová verze

Byla vydána verze 3.7.0 svobodného systému pro správu obsahu (CMS) Joomla!. V oznámení o vydání (YouTube) se píše o 700 vylepšeních. Opraveno bylo také 8 bezpečnostních chyb.

Ladislav Hagara | Komentářů: 0
27.4. 08:22 | Komunita

Grsecurity (Wikipedie) je sada bezpečnostních patchů pro linuxové jádro (porovnání se SELinuxem, AppArmorem a KSPP). Od září 2015 nejsou stabilní verze těchto patchů volně k dispozici. Dle včerejšího oznámení (FAQ) nejsou s okamžitou platností volně k dispozici už ani jejich testovací verze.

Ladislav Hagara | Komentářů: 60
26.4. 23:33 | Komunita

OpenBSD 6.1 vyšlo již 11. dubna. Po dvou týdnech byla vydána i oficiální píseň. Její název je Winter of 95 a k dispozici je ve formátech MP3 a OGG.

Ladislav Hagara | Komentářů: 0
26.4. 18:55 | Nová verze

Byla vydána verze 2017.1 linuxové distribuce navržené pro digitální forenzní analýzu a penetrační testování Kali Linux. S vydáním verze 2016.1 se Kali Linux stal průběžně aktualizovanou distribucí. Aktualizovat jej lze pomocí příkazů "apt update; apt dist-upgrade; reboot".

Ladislav Hagara | Komentářů: 0
26.4. 18:22 | Nová verze

Po téměř pěti letech od vydání verze 2.00 byla vydána nová stabilní verze 2.02 systémového zavaděče GNU GRUB (GRand Unified Bootloader). Přehled novinek v souboru NEWS.

Ladislav Hagara | Komentářů: 24
26.4. 17:55 | Komunita

Vývojáři Debianu oznámili, že od 1. listopadu letošního roku nebudou jejich archivy dostupné pomocí protokolu FTP. Již v lednu oznámil ukončení podpory FTP kernel.org (The Linux Kernel Archives).

Ladislav Hagara | Komentářů: 28
26.4. 17:00 | Bezpečnostní upozornění

V oblíbeném webmailu postaveném na PHP SquirrelMail (Wikipedie) byla nalezena bezpečnostní chyba CVE-2017-7692, jež může být útočníkem zneužita ke spuštění libovolných příkazů a kompletnímu ovládnutí dotčeného serveru. Zranitelnost se týká pouze instancí, kde je pro transport používán Sendmail.

Ladislav Hagara | Komentářů: 3
26.4. 13:11 | Zajímavý článek

Soudní dvůr Evropské unie rozhodl (tisková zpráva) ve věci C-527/15: Prodej multimediálního přehrávače, který umožňuje zdarma a jednoduše zhlédnout na televizní obrazovce filmy protiprávně zpřístupněné na internetu, může představovat porušení autorského práva.

Ladislav Hagara | Komentářů: 32
Chystáte se pořídit CPU AMD Ryzen?
 (4%)
 (35%)
 (1%)
 (6%)
 (45%)
 (9%)
Celkem 341 hlasů
 Komentářů: 50, poslední 27.4. 04:06
    Rozcestník

    Dotaz: Pětiminutový průměr

    15.5.2014 13:29 Pavel | skóre: 17
    Pětiminutový průměr
    Přečteno: 1153×
    Zdravím, do DB ukládám každou minutu data, která pak zobrazuju v jpgraphu. Pokud ještě zobrazuju data za celý den (1440 záznamů) tak to ještě jde, ale pokud chci zobrazit celý týden, tak jak dotaz, tak následné vykreslení grafu trvá dlouho. Jde nějak v MySQL rovnou číst data jako pětiminutový, nebo hodinový průměr? Pokud ne, tak bych asi musel data zrcadlit do druhé DB a tam ten průměr počítat.

    Odpovědi

    15.5.2014 15:15 iKoulee | skóre: 19
    Rozbalit Rozbalit vše Re: Pětiminutový průměr
    Asi bude zalezet na schematu tabulky, teoreticky by to slo za pomoci AVG a GROUP BY.

    Ale jinak myslim ze lepsi by bylo pouzit misto mysql, rrd databazi, ta je na takovehle ukoly primo navrzena.
    Even if you fall on your face, you’re still moving forward
    wamba avatar 15.5.2014 15:33 wamba | skóre: 37 | blog: wamba
    Rozbalit Rozbalit vše Re: Pětiminutový průměr
    v sqllite to jde takhle (průměr za hodinu),
    select datetime(avg(strftime('%s',hod)),'unixepoch') from cas group by strftime('%Y-%m-%d %H',hod);
    přímo z času to průměr nepočítalo
    This would have been so hard to fix when you don't know that there is in fact an easy fix.
    15.5.2014 15:24 Ivan
    Rozbalit Rozbalit vše Re: Pětiminutový průměr
    Podivej se na Exponential_moving_average. Ten se pouziva skoro vsude. Pokud bys' to chtel pocitat primo v databazi, tak v Oracle by se na to pouzila MODEL clause.

    Vetsinou se takovy data ukladaji to rrd.
    Josef Kufner avatar 23.5.2014 23:06 Josef Kufner | skóre: 67
    Rozbalit Rozbalit vše Re: Pětiminutový průměr
    Dělal jsem nějaké podobné statistiky a došel jsem k tomu, že nejlepší je si ty data pro zvolené intervaly spočítat a uložit vedle. Tedy udělat nějaký ten pomalý výpočet, ale udělat ho jen na tom posledním kousku dat, co se ještě nepočítal. Navíc pak můžeš velmi stará podrobná data zahodit/archivovat a ponechat si jen souhrnné statistiky (např. pro roční pohled).
    Hello world ! Segmentation fault (core dumped)
    23.5.2014 23:18 Pavel | skóre: 17
    Rozbalit Rozbalit vše Re: Pětiminutový průměr
    Rozumná odpověď, proč zbytečně několikrát počítat to samé, když jde pohodlně výsledek uložit.
    24.5.2014 13:29 Šangala | skóre: 56 | blog: Dutá Vrba - Wally
    Rozbalit Rozbalit vše Re: Pětiminutový průměr

    Je to jedna a dobrá možnost, ukládat si mezivýsledky to pomocné permanentní tabulky. Tyto mezi výsledky lze generovat na pozadí (třeba cron-em) nebo jen na vyžádání, a pro zobrazení tahat vždy z této tabulky.

    Druhá, nevím jak dobrá možnost, ale pokud je to dobře/abstraktně udělané snadno se implementuje kdykoliv za chodu, a to je udělat cache na SQL dotazy (třeba jejich SHA1 otisk) a SQL výsledek uložit v nějakém serializovaném formátu, s logikou neexistuje provedu SQL/seraializuji/uložím/přečtu/vrátim, existuje-li přečtu/vrátím. Tato cache lze periodicky čistit, tím nic nebobtná a data jsou vždy buď rychle nebo pomalu (samozřejmě to lze i uprvního). Výhoda tohoto to řešení je, že nemusíš vědět co chceš předpřipravit a nemusíš na to nic speciálně chystat jakýkoliv obskurní dotaz pak vytvoříš, je to tam. Nevýhodou je trochu přemýšlení prvotní pracnost s vytvořením rozhraní, kde se musí myslet jak na dotaz, tak i případě připravených dotazů i na data a identifikátor (SHA1) musí být tvořen jak z SQL dotazu tak s dat, a taky je potřeba myslet na to, že ne každý dotaz pracuje s neměnnými daty (při volání dotazu současně přidat jeho platnost). Tato možnost se mi právě u statik osvědčila…, freqventované dotazy jsou přes cron předpřipraveny a potřebné se chystají in-time a není to zatížené změnami požadavků, jakýkoliv výstup přidáš automaticky je poprvé pomalý a pak v cache.

    Poslední možnost (která lze kombinovat s oběma, je správné navržení dotazu a případně doplnění pomocných polí, či vytvoření pomocné tabulky). Obecně jakákoliv práce s časem a datem je záludná a náročná, lepší je si třeba ukládat přímo konkrétní pětimunutu od nějakého pevného bodu a nedopočítávat ji, pak lze udělat pomocnou tabulku s číselnou řadou či řadami a provázat a group-ovat podle ní, ale to záleží jak přesně (jaká je struktura) to máš.

    Ono to vychází ze zvláštnosti statistiky, že se často pracuje s neměnnými daty, takže lze jakýmkoliv způsobem výsledky předpočítat, takže finálně třeba nemusíš nic jen generuješ až finální statický výsledek (html/graf apod.), tedy máš aktuální data na výstupu s nějakým definovaným zpožděním a možní nějaký náhled na živá data, ale jen kousek do zadu…

    .
    To, že trpíš stihomamem, ještě neznamená, že po tobě nejdou. ⰞⰏⰉⰓⰀⰜⰉ ⰗⰞⰅⰜⰘ ⰈⰅⰏⰉ ⰒⰑⰎⰉⰁⰕⰅ ⰏⰉ ⰒⰓⰄⰅⰎ ·:⁖⁘⁙†
    Josef Kufner avatar 24.5.2014 13:35 Josef Kufner | skóre: 67
    Rozbalit Rozbalit vše Re: Pětiminutový průměr
    SQL dotazy a jejich výsledky kešuje už databázový server. Občas stačí jen přidat paměť použitou na cache (někde v konfiguráku). Aby takové kešování fungovalo lépe, je potřeba počítat se zvláštními vlastnostmi dané úlohy, což databáze nebo vlastní kešování na úrovni SQL dotazů dělat nemůže.
    Hello world ! Segmentation fault (core dumped)
    24.5.2014 15:22 Šangala | skóre: 56 | blog: Dutá Vrba - Wally
    Rozbalit Rozbalit vše Re: Pětiminutový průměr

    Statistika je často o tom, že z velkého množství dat je třeba získat „nečetný“ výsledek. Velmi často kešování takových úloh na straně DB serveru je sci-fi až pro stovky MiB RAM vyhrazenou pro DBE cache, která je aplikačně neovldatelná, user-cache je plně ovladatelná a zajistí že výsledek žádaný dnes a včera, je dnes vrácen z toho včerejšího a netrvá 2 min. Co jsem tak vyšmíroval, tak ve velkém se to dělá na tři úrovně, první jsou vytvořené plně statické výsledky, druhá úroveň se pracuje na pomocnými a||nebo omezenými předpřipravenými daty a třetí úroveň jsou živá data (která nemusí být v DB, ale třeba v souborech) a o ty úlohy se „žádá“ (řadí se do fronty).

    Běžné malé věci jsem měl dřív vždy nad živými daty a nechal to nad DB, ale jednou jsem udělal řešení, které pracovalo s velkým objemem dat a podávalo de-facto jen statistické výsledky. Jakmile jsem doplnil tuto cache a předgenerování expandovaných dotazů v mrtvém čas a hlavně sériově, tak se to mohlo odsunou na virtuál s 2GiB RAM (db několik GiB, možná na jednom místě to už budou vyšší desítky GiB přímo na železe - nemám to ve správě, nevím) a pohoda a mohlo s tím pracovat i více lidí. Takové řešení je velká úspora zdrojů (tedy nad neměnnými daty, nebo kde jsou výsledky relevantní pro deleší dobu), takže to už aplikuji častěji a věci co těžce nesl DB server, zvládne lokání mini DB konfigurace (píšu o MySQL a MSSQL - s PostgreSQl jsem to ještě nedělal, jen testoval, MySQL je šetrnější na tyto věci a MSSSL bylo prostě zadání)

    To, že trpíš stihomamem, ještě neznamená, že po tobě nejdou. ⰞⰏⰉⰓⰀⰜⰉ ⰗⰞⰅⰜⰘ ⰈⰅⰏⰉ ⰒⰑⰎⰉⰁⰕⰅ ⰏⰉ ⰒⰓⰄⰅⰎ ·:⁖⁘⁙†
    Heron avatar 12.6.2014 16:52 Heron | skóre: 51 | blog: root_at_heron | Olomouc
    Rozbalit Rozbalit vše Re: Pětiminutový průměr
    SQL dotazy a jejich výsledky kešuje už databázový server.

    Jak který. PostgreSQL query cache nemá (z dobrých důvodů) a i u MySQL se doporučuje to s její velikostí moc nepřehánět (256MB), protože režie spojená s invalidací cache může být větší, než přínos té cache. Netuším, zda se něco změnilo, ale MySQL vylejvala z cache všechny querry, které se týkaly měněné tabulky, takže v praxi se ta cache často ani nenaplnila. (Nevím co je v této oblasti nového, MySQL už mi nesmí přes práh.)

    Pokud nějaký proces cache využije, je mnohem lepší, když si ji řídí sám (protože ví jak, což ta obecná query cache nikdy neví). A může na to použít věci jako memcached apod.

    24.5.2014 17:57 ebik | skóre: 2
    Rozbalit Rozbalit vše Re: Pětiminutový průměr
    Hmm, jenže tady výsledek toho dotazu se mění každou minutu. Takže cache se hodí, jen když stejných dotazů bude více do minuty. IMHO se zde jedná o méně časté, zato náročnější dotazy.
    24.5.2014 20:45 Šangala | skóre: 56 | blog: Dutá Vrba - Wally
    Rozbalit Rozbalit vše Re: Pětiminutový průměr

    To je otázka, mění se přece jen aktuální data, tedy poslední 5-ti minuta/hodina… Právě proto, že se jedná (jestli se tedy jedná - těch dat, tak jak je to popisované, je trocha, tak by to mělo být hned) o náročné dotazy, je na místě cache nebo dopočítaná tabulka

    To, že trpíš stihomamem, ještě neznamená, že po tobě nejdou. ⰞⰏⰉⰓⰀⰜⰉ ⰗⰞⰅⰜⰘ ⰈⰅⰏⰉ ⰒⰑⰎⰉⰁⰕⰅ ⰏⰉ ⰒⰓⰄⰅⰎ ·:⁖⁘⁙†
    24.5.2014 01:01 Pavel | skóre: 17
    Rozbalit Rozbalit vše Re: Pětiminutový průměr
    A ještě dotaz. Je lepší průměry počítat v php ihned při zadávání, nebo každých pět minut spouštět script, případně zjistit kolik je toho potřeba spočítat a činit tak až když se to potřebuje?

    Dle mého názoru bych to počítal okamžitě...
    Josef Kufner avatar 24.5.2014 02:04 Josef Kufner | skóre: 67
    Rozbalit Rozbalit vše Re: Pětiminutový průměr
    Já bych to počítal až když je něco bude chtít.
    Hello world ! Segmentation fault (core dumped)
    24.5.2014 11:08 Zopper | skóre: 14
    Rozbalit Rozbalit vše Re: Pětiminutový průměr
    Jen pokud bude chtít něco relativně často. Pokud se bude na graf koukat jednou za dva týdny, tak to pak potrvá strašně dlouho a co když přijde timeout...

    Takže záleží na konkrétní situaci.
    "Dlouho ještě chcete soudit proti právu, stranit svévolníkům?" Ž 82,2
    24.5.2014 17:54 ebik | skóre: 2
    Rozbalit Rozbalit vše Re: Pětiminutový průměr
    Pokud se budou průměry ukládat "průběžně", tak timeout nezahodí vypočtenou práci.
    24.5.2014 18:00 ebik | skóre: 2
    Rozbalit Rozbalit vše Re: Pětiminutový průměr
    Já jsem také pro okamžité počítání, když tam budeš mít "if" na "pátou" minutu, tak je to ekvivalentní tomu pětiminutovému skriptu, jen to bude vše na jednom místě (v jednom zdrojáku), což je IMHO pro jednoduché úlohy přehlednější.
    24.5.2014 19:33 VM
    Rozbalit Rozbalit vše Re: Pětiminutový průměr
    Vzhledem k tomu že týden má nějakých 10 tisíc minut, tak by se to nemělo číst zas tak dlouho, jinak je někde něco shnilého. Začal bych tím.

    Také bych výsledné grafy kešoval na disk, aby dva přístupy během pěti vteřin nezpůsobily dvojí nové generování. Případně se dá graf generovat cronem, a klientovi se jen pošle výsledný soubor.

    To zda ukládat minutová nebo pětiminutová data bych nechal čistě na tom, která mě zajímají.

    Založit nové vláknoNahoru

    Tiskni Sdílej: Linkuj Jaggni to Vybrali.sme.sk Google Del.icio.us Facebook

    ISSN 1214-1267   www.czech-server.cz
    © 1999-2015 Nitemedia s. r. o. Všechna práva vyhrazena.