ARCHIV

MySQL (66) - Ještě k ladění serveru

Ladění serveru MySQL na výkon je dost odborné téma. Dnes se podíváme alespoň na principy.

14.4.2006 06:00 | Petr Zajíc | Články autora | přečteno 21876×

Dnes budeme pokračovat v tématu "vylaďování" MySQL serveru tím, že si ukážeme, jak zjistit informace o běžícím serveru. Rovněž se podíváme na to, jak se dá výkon ovlivnit pomocí několika důležitých parametrů.

Zjišťování informací o běžícím serveru

Připomeňme, že v minulém díle jsme díky příkazu show variables mohli zjišťovat (a díky set měnit) hodnoty konfiguračních voleb. Jenomže to není při správě serveru vždy to, co potřebujeme. Často nás totiž ani tak nezajímá, jak je na serveru co nastaveno, jako spíše to, jak se s tím v praxi chudák server vůbec popere. Přidejme potřebu chtít zjistit něco víc o serveru jako takovém - a máme tady příkaz show status. Jeho nejjednodušší forma je - jak už asi tušíte - prostě ho bez skrupulí napsat.

Není na tom nic složitého; složité je nějak se ve výpisu vyznat. Proměnné jsou většinou pojmenovány intuitivně, někdy je však třeba zapátrat trochu v dokumentaci. Abyste si udělali představu, jak takový výpis vypadá, přikládám zkrácenou verzi z jednoho serveru, na který mám přístup (není to linuxsoft):

Co podstatného se dá vyčíst z tohoto seznamu? Především (a to je jedna z prvních věcí, na kterou byste se měli podívat) server běží jen krátce, protože jeho uptime v sekundách je 67925, což je okolo 18 hodin. Takže pokud byste jej chtěli ladit na výkon, bylo by asi lepší ještě nějakou dobu počkat a posbírat reprezetativnější statistiky. Dále, jak můžete vidět, tak během 18 hodin proběhlo otevření 756017 tabulek, došlo k 327488 spojením a tak dále.

Optimalizace cache tabulek

Tento server (bohužel, neb se jedná o údaje z jakéhosi webhostingu, kde by tomu mohl někdo rozumět) má bídně nastavenu jednu ze základních výkonostních charakteristik, a tou je table_cache. Zjednodušeně řečeno tato proměnná udává, kolik tabulek může maximálně MySQL udržovat v mezipaměti. Cachování tabulek v mezipaměti je přitom mnohem výkonnější než nejich načítání z disku. Abych mohl rozhodnout, zda je cachováno málo nebo hodně tabulek, je třeba vědět Uptime (v příkladu asi 18 hodin), Open_tables (v příkladu 64) a potřebuji navíc znát hodnotu table_cache z nastavení (to jsme probírali v minulém díle):

(v mém případě ukazuje údaj 64 tabulek). A teď závěr: Protože je povoleno otevření maximálně 64 tabulek, 64 je jich otevřeno, ale celkem jich již bylo otevřeno 756 tisíc, je server poddimenzovaný a je možné, že s ním budou problémy. Obdobně by se daly porovnat další související údaje z konfigurace s údaji z provozu. Pokud Vás něco takového zajímá, mohu nasměrovat zejména na:

• key_buffer_size, která optimalizuje čtení a zpracování indexů a souvisí s key_read_requests a key_reads
• max_connections, která optimalizuje spojení a souvisí s max_used_connections

Tyto parametry jsou pro výkon serveru klíčové. Celá řada dalších nastavení dolaďuje spíše jemné výkonostní detaily.

Všeho s mírou

Znamená to, co jsem uvedl výše, že byste měli ukamenovat svého webhostera poté, co zjistíte, že server není optimálně nastaven? V žádném případě. Informace, které jsem ukázal je nutné brát v širším kontextu. Například pro zvýšení table_cache bude zcela jistě zapotřebí dostatek operační paměti, kterou ale server nemusí mít k dispozici. Zvýšení maximálního počtu spojení nemusí být nutné, protože správce databáze může mít k dispozici i starší statistiky (například ty, které získal před restartem serveru). Aktuální počet transakcí se může dost měnit a tak dále.

Údaje z článku budete tedy potřebovat spíše v případě, kdy nastavujete server jakožto správci - a pak jistě časem získáte cvik a cit pro vyváženost.

Verze pro tisk

DISKUZE nastavenie key buffer size 20.4.2006 21:39 oron   Re: nastavenie key buffer size 20.4.2006 23:42 Aleš Hakl Zobrazit označené Zobrazit vše Příspívat do diskuze mohou pouze registrovaní uživatelé.