Běh serveru lze ovlivnit mnoha parametry. Podíváme se na to, jak a kde se dají v MySQL nastavovat.
31.3.2006 06:00 | Petr Zajíc | přečteno 22049×
Přiznám se, že napsat tenhle článek bylo pro mě jednou z nejtěžších věcí v celém seriálu o MySQL. Jde totiž o téma, které se dá pojmout velmi různě - o nastavení serveru. Člověk by mohl sklouznout k mnoha špatným metodám, jak o něčem takovém napsat povídání. Mohl bych například podat suchopárný, nezáživný, vyčerpávající a nezapamatovatelný seznam konfiguračních voleb; mohl bych opsat originální dokumentaci nebo bych se mohl vášnivě rozhovořit o tom, jak to dělám na "svých" instalacích MySQL a proč právě to je "ta nejlepší" cesta.
Pokusil jsem se to všechno neudělat;
a mám k tomu moc dobrý důvod. Nastavování serveru totiž není jako
nastavování pračky. Databázový server může být používán mnoha způsoby a
proto také musí být odlišně vyladěn. Proč? Není to snad tak, že
server MySQL slouží jen jako úložiště dat? Ano a ne. Uvědomme si, že
jeden a tentýž databázový server může být nastaven různě - a přece
pokaždé "správně". Co tedy spolurozhoduje o tom, jak nastavit (kolega
by řekl "vytunit") MySQL?
Když se nad tím zamyslíte, mohou to být například následující činitele
(přičemž mnoho dalších jsem pro jednoduchost vynechal):
Jak uvídíme, vzít to všechno v úvahu je silně nad rámec seriálu.
Proto jsem se rozhodl popsat celé nastavení na několika málo příkladech
a doufat, že vnímavý čtenář si odvodí odpovídající postupy i pro další
proměnné a volby.
Není to zase tak složité. Pokud chcete v MySQL něco nastavit,
potřebujete vlastně "jen":
Popíšu celé na příkladu. Zjistíme třeba, že řazení záznamů nám
trvá neúměrně dlouho a že by bylo třeba si trochu pohrát s nastavením
výkonu pro příkaz ORDER BY.
Pravda, příklad je trošku vyumělkovaný, ale záměrně jsem zvolil něco
jednoduchého.
Neexistuje obecný návod; leda byste si každou z voleb pamatovali.
Pokud budete chtít optimalizovat řazení dat, pravděpodobně se podíváte do
manuálu a zjistíte, že výkon řazení může ovlivnit proměnná sort_buffer_size. Udává velikost
bufferu, který si alokuje každé vlákno vykonávající řazení dat. S
hodnotou si můžeme samozřejmě pohrát; přičemž je třeba vzít v úvahu,
kolik paměti vlastně máme celkem pro server k dispozici a kolik vláken
nám (odhadem) bude zároveň potřebovat řadit data.
Pozn.: Údaj "kolik paměti máme pro
server" je ošidný sám o sobě. Nezapomeňte, že v reálném světě nám může
na jednom stroji kromě MySQL běžet ještě řada služeb či programů a ty
potřebují další paměť. Takže to berte opravdu jen jako příklad.
Začněme tím, že si ukážeme, jak vlastně zjistit aktuální hodnotu konfiguračních voleb. To je jednoduché. Stačí se připojit k databázi a zadat příkaz:
show variables;
Cože? Že se v nich nemůžete vyznat? Jenom jsem Vás zkoušel. Moje instalace MySQL 5 obsahuje 209 konfiguračních proměnných, takže v nich se opravdu špatně hledá. Mnohem lepší je
show variables like
'sort_buffer_size';
A hned vidíte, jak na tom jste. Když už jsme u příkazu SHOW VARIABLES, tak bych měl asi upřesnit, že neobsahuje jen měnitelné, konfigurovatelné hodnoty. Obsahuje rovněž například informace o verzi serveru, kterou pochopitelně přepsat nemůžete. Změnit hodnotu proměnné - když to jde - můžete příkazem SET, nějak takto:
set
sort_buffer_size=1000000;
Zapamatujte si, že pokud to uděláte, bude nová hodnota platit ihned, ovšem pouze do ukončení aktuálního spojení a pouze pro toto spojení. Jestliže vy nebo někdo jiný otevřete jiné spojení, bude v novém spojení opět původní hodnota proměnné. Což je hezké, ale jak změnit hodnotu pro všechna připojení? Použitím klíčového slova GLOBAL, nějak takto:
set global
sort_buffer_size=1000000;
V tomto případě bude nová hodnota platit pro všechna od této chvíle vytvořená nová spojení až do restartu serveru. Z toho ovšem
vyplývá, že pro spojení, které proměnnou nastavilo nová hodnota neplatí
(pozor na to).
Pokud nám ani to nestačí a potřebujete proměnnou nastavit pro celý server a po každém spuštění, je třeba zabrousit do konfiguračního souboru. Ten bude umístěn typicky v /etc/my.cnf (nebo jinde podle distribuce) a bude mít formát jako ... ini soubor ve Windows. Takže změnu sort_buffer_size provedeme editací příslušné sekce:
[mysqld]
...
sort_buffer_size=100K
...
Pozor, konfigurační hodnoty jsou načítány při startu serveru, tudíž
při jejich změně bude nutné MySQL restartovat. A ještě informace pro
opravdové znalce: hodnoty konfiguračních voleb můžete povětšinou zadat
při startu serveru rovněž jako přepínače do příkazového řádku. Načítání
voleb ze souboru mi však přijde mnohem přehlednější.
Docela problém, protože většina voleb má na výkon relativně malý dopad. Dopad změny velikosti proměnné sort_buffer_size bychom mohli ověřit nějak takto:
set
sort_buffer_size=100K;
select * from obrovska_tabulka order by pole limit 1000,100;
set sort_buffer_size=100M;
select * from obrovska_tabulka order by pole limit 1000,100;
Čas potřebný ke zpracování výsledků by neměl být stejný, zejména
pokud provedete více měření na reálném provozu.
Jak jste asi pochopili, občas bude mít význam vyzkoušet si změnu
serverové proměnné pouze pro dané spojení. O návrat do původního stavu
se pak vlastně nemusíme starat, protože po ukončení spojení se
specifické nastavení ztratí. Jestliže nastavíte proměnnou pomocí set global, její hodnota se obnoví
po restartu serveru na původní hodnoty. Pokud se chcete zabývat změnami
konfiguračních souborů, je jasné, že bude třeba si je nejprve
zálohovat. Pokud se něco pokazí, lze se vrátit k záloze. A ještě něco:
do konfiguračních souborů lze psát poznámky. Využijte toho, napište si
třeba datum a čas změny, původní hodnotu proměnné nebo proč jste tu
kterou volbu měnili. Uvidíte, že to není zbytečná práce.
Protože sort_buffer_size byla použita opravdu jen jako příklad, podíváme se v dalším díle na to, které serverové proměnné mohou ovlivnit naši konfiguraci opravdu podstatným způsobem a také si řekneme, jak zjišťovat stavové informace o právě běžící instanci serveru. Takže se máte na co těšit.