MySQL mi pri startu alokuje 12 procesu a kazdy po 20M.A to mam tabulku z 10 sloupci a 35 zaznamu.A to jse pouzil my-small.cnf.Teda Vam reknu, ze pekny zrout.
Tady by stačilo zhruba dvacet minut věnovat přečtení manuálu MySQL a snadno a rychle tam najdete jak tyto věci nastavit. Právě nastavení velikosti paměti několika bufferů, které si MySQL drží, a jejichž velikost můžete v e velkém rozmezí škálovat je docela dobrá věc. MySQL tak nějak předpokládá, že si těch prá parametrů nastavíte podle toho, co potřebujete. Pokud použijete prefabrikované řešení typu my-small.cnf, tak se nesmíte divit.
Právě možnost tyto informace rychle najít a použít, kterou mám u MySQL mi hrozně chybí u Firebirdu, kde v podstatě nemám možnost podobné údaje vůbec najít.
Musím zde napsat, že i po optimalizaci mi MySQL (InnoDB) brala víc prostředků, než bylo zdrávo. Firebird vše zvládal s třetinovými nároky stejně rychle.
Jestli chcete optimalizovat MySQL na šetrnost k prostředkům počítače, nepoužívejte InnoDB. InnoDB je trochu kanón na vrabce a je dělaná na výkon a rozhodně prostředky počítače nešetří. Pokud vám záleží na každém bajtu, který databáze zabere, postavte to na MyISAM a pohrajte si s hodnotami bufferů.
Mám takhle na stařičkém notebooku (Pentium 166 MHz, 32 MB paměti, Windows 95) databázi nemovitostí v MySQL s několika stovkami tisíc záznamů a asi třiceti tabulkami a databázový server MySQL zabírá v paměti asi 1,5 MB. Práce s databází je velice rychlá.
Je třeba si také uvědomit určení databáze. Pokud potřebujete kvalitní databázi se všemi vymožnostmi relačních databází, myslím si, že MySQL není dobrá volba. Pro mě je MySQL takové inteligentnější pokračování DBF databází.
Tady jste mě asi nepochopil. To, že potřebuji minimalizovat nároky na pamět nutně neznamená, že se nejedná o mission-critical aplikaci. Je to klíčový informační systém firmy, který nelze na MySQL provozovat na jiných tabulkách, než typu InnoDB.
MySQL určitě nebyla dobrá volba, ale jak se aplikace rozrůstala, tak se stalo prakticky nemožné migrovat jinam. Používám příliš proprietárních věcí a když bylo potřeba použít vlastnosti dostupné na InnoDB, tak se to prostě přeplo. Proč taky ne, když to MySQL nabízí. Jinak jsem s provozem spokojen, po dobu 2 let žádný výpadek, zálohy probíhají korektně od prvotního nastavení. Jen té paměti si to žere...
Aha, rozumím. To je potom těžké, protože InnoDb je opravdu žravé. I když i to se dá částečně vyladit. Chce to pohrát si s konfiguračními volbami pro InnoDb, je jich slušná řádka. Ale samotná MySQL počítá s tím, že pro ní bude vyhrazeno asi 80% paměti stroje, na to byla navrhovaná. Dá se samozřejmě vyladit na daleko menší spotřebu, ale chce to si chvíli hrát s konfigurací.
Ano, opravdu je to žrout. Možná je to tím, že je to v MySQL jakoby "navíc" - DB nebyla takto navržená. Nevím, vyladit by se to zcela jistě dalo, ale při zběžném přečtení manuálu jsem na to nepřišel.
To máte naprostou pravdu. Taky mi někdy připadá, že InnoDb je v MySQL v podstatě cizí element.
S laděním MySQL jsem si už v životě docela dost užil. Asi největší zkušeností pro mě bylo, když jsem administroval MySQL pro dnes už neexistující DC hub - CZ PRO. Nad MySQL běželo několik náročných klientů a jedním z bych byl verlihub, ke kterému bylo běžně připojeno kolem 6000 uživatelů. Jak verlihub, tak i MySQL byli paměťoužrouti a bylo potřeba u MySQL nechat vysoký výkon za rozumné spotřeby paměti. Co mě ale velice překvapilo, že mě bohatě stačily k ladění informace z manuálu k MySQL.
Tedy k vašemu problému. Jak se ladí MySQL? Nejdříve si musíte uvědomit, jaké SQL oprerace se na něm skutečně provádějí, a které z nich jsou kritické. To asi nejvíce víte vy sám, co vám tam běhá.
1) Nejdříve je dobré nastavit obecné velikosti bufferů v konfiguraci MySQL serveru, které nezávisí na typu tabulek. Informace o tom v manuálu jsou, ale jsou bohužel rozházeny na různých místech. Klíčové je vhodně nastavit parametry key_buffer_size, join_buffer_size a sort_buffer_size. Jejich význam si snadno najdete v manuálu pomocí fulltextového vyhledávání.
2) Potom je vhodné nastavit parametry, které se týkají pouze InnoDb tabulek. Těch je trochu více a je potřeba jejich význam pochopit trochu do hloubky. Zde je ale manuál dobře popisuje, jejich přehled se základním popisem dostanete třeba zde (doporučuji ovšem návdavkem přečíst celou část o InnoDB):
Pokud uděláte první pokus, nejspíše se dostanete na dost vysokou hodnotu ve spotřebě paměti, ale je potřeba body 1) a 2) párkrát opakovat, než to iterací dojde do vyladěného stavu.
Také velmi doporučuji přečíst si část pojednávající o optimalizaci MySQL obecně: