Špatný výkon dotazů je nejčastějším problémem, se kterým se DBA musí vypořádat. Existuje mnoho způsobů, jak shromažďovat, zpracovávat a analyzovat data související s výkonem dotazů – jeden z nejpopulárnějších nástrojů, pt-query-digest, jsme popsali v některých z našich předchozích blogových příspěvků:
Staňte se sérií blogů MySQL DBA
- Analýza vaší úlohy SQL pomocí pt-query-digest
- Deep Dive SQL Workload Analysis pomocí pt-query-digest
Když však používáte ClusterControl, není to vždy potřeba. K vyřešení vašeho problému můžete použít data dostupná v ClusterControl. V tomto příspěvku na blogu se podíváme na to, jak vám může ClusterControl pomoci vyřešit problémy související s výkonem dotazů.
Může se stát, že dotaz nemůže být dokončen včas. Dotaz se může zaseknout kvůli některým problémům se zamykáním, nemusí být optimální nebo není správně indexován nebo může být příliš těžký na dokončení v rozumném čase. Mějte na paměti, že několik neindexovaných spojení může snadno skenovat miliardy řádků, pokud máte velkou produkční databázi. Ať už se stalo cokoli, dotaz pravděpodobně využívá některé prostředky – ať už jde o CPU nebo I/O pro neoptimalizovaný dotaz, nebo dokonce jen zámky řádků. Tyto zdroje jsou vyžadovány i pro jiné dotazy a to může věci vážně zpomalit. Jedním z velmi jednoduchých, ale důležitých úkolů by bylo určit problematický dotaz a zastavit jej.
To lze docela snadno provést z rozhraní ClusterControl. Přejděte na kartu Sledování dotazů -> sekce Spouštění dotazů - měli byste vidět výstup podobný snímku obrazovky níže.
Jak vidíte, uvízla nám hromada dotazů. Obvykle je problematický dotaz ten, který trvá dlouho, možná ho budete chtít zabít. Možná to budete chtít dále prozkoumat, abyste se ujistili, že vyberete ten správný. V našem případě jasně vidíme SELECT … FOR UPDATE, který spojuje několik tabulek a který je ve stavu ‚Odesílání dat‘, což znamená, že zpracovává data, za posledních 90 sekund.
Dalším typem otázky, na kterou DBA možná bude muset odpovědět, je – provedení kterých dotazů trvá nejvíce času? To je běžná otázka, protože takové dotazy mohou být málo visícím ovocem – mohou být optimalizovatelné a čím delší dobu provádění je daný dotaz zodpovědný za celý mix dotazů, tím větší je zisk z jeho optimalizace. Jde o jednoduchou rovnici – pokud je dotaz zodpovědný za 50 % celkové doby provádění, 10x rychlejší poskytne mnohem lepší výsledek než optimalizace dotazu, který je zodpovědný za pouhé 1 % celkové doby provádění.
ClusterControl vám může pomoci zodpovědět takové otázky, ale nejprve se musíme ujistit, že je aktivován Query Monitor. Monitor dotazů můžete zapnout na stránce Monitor dotazů. Dále můžete v Nastavení nakonfigurovat možnost „Dlouhá doba dotazování“ a „Zaznamenat dotazy nepoužívající indexy“ tak, aby vyhovovaly vaší pracovní zátěži:
Query Monitor v ClusterControl funguje ve dvou režimech v závislosti na tom, zda máte k dispozici Performance Schema s požadovanými údaji o běžících dotazech či nikoli. Pokud je k dispozici (a to platí ve výchozím nastavení v MySQL 5.6 a novějších), bude pro sběr dat dotazů použito schéma výkonu, čímž se minimalizuje dopad na systém. V opačném případě se použije protokol pomalého dotazu a použijí se všechna nastavení viditelná na výše uvedeném snímku obrazovky. Ty jsou docela dobře vysvětleny v uživatelském rozhraní, takže to není třeba dělat zde. Když Query Monitor používá schéma výkonu, tato nastavení se nepoužívají (kromě přepínání ON/OFF Query Monitor pro povolení/zakázání sběru dat).
Když potvrdíte, že je v ClusterControl povoleno sledování dotazů, můžete přejít na Sledování dotazů -> Nejčastější dotazy, kde se vám zobrazí obrazovka podobná té:
Zde můžete vidět seznam nejdražších dotazů (z hlediska doby provádění), které zasáhly náš cluster. Každý z nich má nějaké další podrobnosti - kolikrát byl proveden, kolik řádků bylo prozkoumáno nebo odesláno klientovi, jak se lišila doba provádění, kolik času cluster strávil prováděním daného typu dotazu. Dotazy jsou seskupeny podle typu dotazu a schématu.
Možná vás překvapí, že hlavním místem, kde se tráví čas provádění, je dotaz „COMMIT“. Ve skutečnosti je to docela typické pro rychlé OLTP dotazy prováděné na clusteru Galera. Potvrzení transakce je nákladný proces, protože musí proběhnout certifikace. To vede k tomu, že COMMIT je jedním z časově nejnáročnějších dotazů v mixu dotazů.
Když kliknete na dotaz, můžete vidět celý dotaz, maximální dobu provádění, počet výskytů, některé obecné optimalizační rady a výstup EXPLAIN pro něj – což je velmi užitečné pro zjištění, zda s ním není něco v pořádku. V našem příkladu jsme zkontrolovali SELECT … FOR UPDATE s velkým počtem zkoumaných řádků. Jak se dalo očekávat, tento dotaz je příkladem hrozného SQL - JOIN, který nepoužívá žádný index. Na výstupu EXPLAIN můžete vidět, že není použit žádný index, dokonce ani jeden nebyl považován za možné použít. Není divu, že tento dotaz vážně ovlivnil výkon našeho clusteru.
Dalším způsobem, jak získat přehled o výkonu dotazů, je podívat se na Query Monitor -> Query Outliers. Toto je v podstatě seznam dotazů, jejichž výkon se výrazně liší od jejich průměru.
Jak můžete vidět na výše uvedeném snímku obrazovky, druhý dotaz trval 0,01116 s (čas je uveden v milisekundách), přičemž průměrná doba provádění tohoto dotazu je mnohem nižší (0,000142 s). Máme také nějaké další statistické informace o směrodatné odchylce a maximální době provádění dotazu. Takový seznam dotazů se může zdát málo užitečný – ve skutečnosti to není pravda. Když v tomto seznamu vidíte dotaz, znamená to, že se něco liší od obvyklého – dotaz nebyl dokončen v pravidelném čase. Může to být náznak některých problémů s výkonem ve vašem systému a signál, že byste měli prozkoumat další metriky a zkontrolovat, zda se v tu dobu nestalo něco jiného.
Lidé mají tendenci se zaměřovat na dosažení maximálního výkonu a zapomínají, že nestačí mít vysokou propustnost – musí být také konzistentní. Uživatelé mají rádi stabilní výkon – možná budete schopni ze svého systému vytlačit více transakcí za sekundu, ale pokud to znamená, že se některé transakce začnou na několik sekund zastavovat, nestojí to za to. Pohled na Histogram dotazů v ClusterControl vám pomůže identifikovat takové problémy s konzistencí ve vašem mixu dotazů.
Příjemné sledování dotazů!
PS.:Chcete-li začít s ClusterControl, klikněte sem!