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í
×
    dnes 17:44 | Zajímavý článek

    Jak si zobrazit pomocí Chrome a na Chromiu založených webových prohlížečích stránky s neplatným certifikátem? Stačí napsat thisisunsafe.

    Ladislav Hagara | Komentářů: 0
    dnes 00:33 | Bezpečnostní upozornění

    V repozitáři AUR (Arch User Repository) linuxové distribuce Arch Linux byly nalezeny a odstraněny tři balíčky s malwarem. Jedná se o librewolf-fix-bin, firefox-patch-bin a zen-browser-patched-bin.

    Ladislav Hagara | Komentářů: 8
    dnes 00:22 | Komunita

    Dle plánu by Debian 13 s kódovým názvem Trixie měl vyjít v sobotu 9. srpna.

    Ladislav Hagara | Komentářů: 0
    včera 13:22 | Komunita

    Vývoj linuxové distribuce Clear Linux (Wikipedie) vyvíjené společností Intel a optimalizováné pro jejich procesory byl oficiálně ukončen.

    Ladislav Hagara | Komentářů: 1
    18.7. 14:00 | Zajímavý článek

    Byl publikován aktuální přehled vývoje renderovacího jádra webového prohlížeče Servo (Wikipedie).

    Ladislav Hagara | Komentářů: 0
    18.7. 12:00 | Nová verze

    V programovacím jazyce Go naprogramovaná webová aplikace pro spolupráci na zdrojových kódech pomocí gitu Forgejo byla vydána ve verzi 12.0 (Mastodon). Forgejo je fork Gitei.

    Ladislav Hagara | Komentářů: 1
    17.7. 18:44 | Zajímavý článek

    Nová čísla časopisů od nakladatelství Raspberry Pi zdarma ke čtení: Raspberry Pi Official Magazine 155 (pdf) a Hello World 27 (pdf).

    Ladislav Hagara | Komentářů: 1
    17.7. 16:11 | Nová verze

    Hyprland, tj. kompozitor pro Wayland zaměřený na dláždění okny a zároveň grafické efekty, byl vydán ve verzi 0.50.0. Podrobný přehled novinek na GitHubu.

    Ladislav Hagara | Komentářů: 4
    17.7. 15:55 | Komunita

    Patrick Volkerding oznámil před dvaatřiceti lety vydání Slackware Linuxu 1.00. Slackware Linux byl tenkrát k dispozici na 3,5 palcových disketách. Základní systém byl na 13 disketách. Kdo chtěl grafiku, potřeboval dalších 11 disket. Slackware Linux 1.00 byl postaven na Linuxu .99pl11 Alpha, libc 4.4.1, g++ 2.4.5 a XFree86 1.3.

    Ladislav Hagara | Komentářů: 6
    16.7. 21:22 | IT novinky

    Ministerstvo pro místní rozvoj (MMR) jako první orgán státní správy v Česku spustilo takzvaný „bug bounty“ program pro odhalování bezpečnostních rizik a zranitelných míst ve svých informačních systémech. Za nalezení kritické zranitelnosti nabízí veřejnosti odměnu 1000 eur, v případě vysoké závažnosti je to 500 eur. Program se inspiruje přístupy běžnými v komerčním sektoru nebo ve veřejné sféře v zahraničí.

    Ladislav Hagara | Komentářů: 19
    Kolik tabů máte standardně otevřeno ve web prohlížeči?
     (25%)
     (19%)
     (6%)
     (6%)
     (3%)
     (6%)
     (3%)
     (31%)
    Celkem 32 hlasů
     Komentářů: 4, poslední dnes 16:33
    Rozcestník

    Administrace komentářů

    Jste na stránce určené pro řešení chyb a problémů týkajících se diskusí a komentářů. Můžete zde našim administrátorům reportovat špatně zařazenou či duplicitní diskusi, vulgární či osočující příspěvek a podobně. Děkujeme vám za vaši pomoc, více očí více vidí, společně můžeme udržet vysokou kvalitu AbcLinuxu.cz.

    Příspěvek
    5.3.2013 10:41 Lyco
    Rozbalit Rozbalit vše Re: MyISAM vs. InnoDB
    TL;DR: vykašli se na MyISAM a používej InnoDB.

    Podrobněji: Nenapsal jsi, co přesně na tom chceš provozovat, a jak vypadá zátěž. Píšeš že poměr selectů a insertů je 30:70, to je nějaké divné - skutečně máš dvakrát víc insertů než selectů? Dále nevíme, jestli ti v databázi běhají nějaké dlouhodobější dotazy - generování nějakých reportů, dávkové importy a podobně. Taky by se hodilo vědět něco o struktuře databáze - jsou tabulky normalizované a děláš tím pádem hodně JOINů, nebo je všechno denormalizované? Jsou nějaká data používanější než jiná? Kolik jich je? Jak je databáze velká? (Vejde se do paměti? Vejdou se tam aspoň "horká" data?) Opakují se dotazy, nebo je každý select unikát? Provozuješ na serveru kromě databáze ještě něco, jako třeba webserver? Pokud ano, kolik je statických dat? Kolik máš najednou běžících dotazů (pokud ti tam opravdu běží v jednu chvíli 300 dotazů, tak máš vážný problém).

    Než se pustím do nějakého většího rozboru: vykašli se na fakeraid. Pokud nemáš HW řadič, tak použij mdraid. Fakeraid spojuje nevýhody obojího a nepřináší žádný prospěch. RAID 10 je dobrá volba, pokud potřebuješ výkon.

    Budu předpokládat následující věci (pokud něco z toho neplatí, pak nemusí platit moje závěry): Databáze je na samostatném serveru. Databázi používá webserver, který si dělá connection pooling. Většina otevřených spojení nic nedělá, v jednu chvíli se vykonává 5 - 20 dotazů. Na serveru se provádí dlouho trvající dotazy, ale jen v noci. Není potřeba je optimalizovat víc než aby kvůli nim server nepadal. V tuhle chvíli server nepadá, takže je můžeme ignorovat. Data se nevejdou do RAM, ale vejdou se tam často používaná data, takže na disk se při běžném provozu sahá jen občas, a jen v jednom nebo dvou vláknech. Databáze je z větší části normalizovaná, řekněme druhá normální forma. Běžné dotazy sahají na jednu až tři tabulky. Na všech sloupcích podle kterých se joinuje jsou indexy. Poměr selectů:zápisů je 30:70, selecty se obvykle příliš neopakují. Z tabulek, do kterých se zapisuje, se taky čte. (Tzn. nemáš "write only" tabulku.) Předpokládám, že umíš optimalizovat dotazy. Tzn. neřeším kam dát jaké indexy, jak a kdy se vyhnout sekvenčním čtením tabulek a podobně.

    Protože se ti dotazy moc neopakují, je zbytečné používat query cache, jenom přidává další (globální) zámky. Zkus ji vypnout.

    MyISAM je rychlý jen při splnění následující podmínky: do databáze se nezapisuje. Jakmile se začnou střídat čtení a zápisy (na vytíženém serveru stačí klidně 5 % zápisů), výkon prudce klesá, protože se zamykají celé tabulky. Vzhledem k tomu, že ty zapisuješ často, je MyISAM nesmysl. Používej InnoDB, začni pracovat s transakcemi a pokud můžeš, nepoužívej SERIALIZABLE (opět kvůli zamykání). Přechod na InnoDB je nejzásadnější optimalizace.

    InnoDB používá vlastní cache. Nastav si innodb_buffer_pool_size na cca 40 - 50 % dostupné RAM. Taky nezapomeň na key_buffer, cca 10 - 20 % RAM. Zbytek nech volný pro souborovou cache operačního systému. Experimentuj. Tohle je druhá nejdůležitější optimalizace.

    Pokud potřebuješ výkon a jsi ochotný riskovat malou ztrátu dat, nastav innodb_flush_log_at_trx_commit = 2. Nepoužívej = 0. Tohle je třetí nejdůležitější optimalizace.

    Používej EXPLAIN. Používej slow log. Používej pt-query-digest (v Debianu je ještě jako mk-query-digest). Používej indexy na více sloupcích. RTFM.

    InnoDB tabulky jsou vlastně indexy, které obsahují kromě primárního klíče i zbytek řádku (tomuhle uspořádání se říká cluster index). Všechny ostatní indexy obsahují indexované sloupce a hodnotu primárního klíče. Pokud v tabulce primární klíč není, InnoDB vytvoří skrytý sloupec a bere ten, ale tenhle sloupec je poměrně velký (6 byte). Aby byly indexy co nejrychlejší, měly by být taky co nejmenší (pak se jich vejde víc do paměti a rychleji se čtou z disku). Proto potřebuješ na každé tabulce primární klíč, a potřebuješ ho co nejkratší (ideálně INTEGER). Pozor, změna primárního klíče znamená, že se musí tabulka postavit úplně znova.

    InnoDB je optimalizované na režim, kdy jsou data všech tabulek v jednom souboru. Bohužel, InnoDB neumí svoje datové soubory zmenšovat (se zvětšováním nemá problém). Nech si dost místa na disku. Dávej si pozor, abys do databáze nenasypal spoustu data která pak budeš mazat - místo by se neuvolnilo.

    Pokud potřebuješ fulltext, vykašli se na MySQL. Použij třeba elasticsearch nebo sphinx. MySQL má fulltext který je pomalý, nic neumí a nedá se konfigurovat.

    Vyhni se počítání řádků (count(*)). Protože je InnoDB transakční, musí přečíst každý řádek jen aby vědělo, jestli ho transakce vidí. Pokud ti stačí přibližná data, vezmi je z information_schema. Pokud potřebuješ přesná, omez důkladně počet řádků které se musí přečíst (tzn. musíš tam mít index).

    InnoDB nemá stabilní statistiky jako MyISAM, místo toho dělá random dives (http://dev.mysql.com/doc/refman/5.1/en/innodb-restrictions.html#idp100219904). Výsledky EXPLAINu se můžou měnit samy od sebe. Pouštěj EXPLAIN víckrát a dělej mezi tím ANALYZE TABLE.

    V tomto formuláři můžete formulovat svou stížnost ohledně příspěvku. Nejprve vyberte typ akce, kterou navrhujete provést s diskusí či příspěvkem. Potom do textového pole napište důvody, proč by měli admini provést vaši žádost, problém nemusí být patrný na první pohled. Odkaz na příspěvek bude přidán automaticky.

    Vaše jméno
    Váš email
    Typ požadavku
    Slovní popis
    ISSN 1214-1267   www.czech-server.cz
    © 1999-2015 Nitemedia s. r. o. Všechna práva vyhrazena.