Efektivní monitorování MySQL pomocí řídicích panelů SCUMM:Část 3

V našich předchozích blozích jsme diskutovali o řídicích panelech souvisejících s MySQL. Studiem grafů jsme zdůraznili věci, z nichž může DBA těžit, zejména při provádění svých každodenních činností z diagnostiky, metrických sestav a plánování kapacity. V tomto blogu budeme diskutovat o InnoDB Metrics a MySQL Performance Schema, což je velmi důležité zejména při sledování transakcí InnoDB, diskových/cpu/paměti I/O, optimalizaci vašich dotazů nebo ladění výkonu serveru.

Tento blog se dotýká hlubokého tématu výkonu, vezmeme-li v úvahu, že InnoDB by vyžadoval rozsáhlé pokrytí, pokud bychom se vypořádali s jeho vnitřnostmi. Schéma výkonu je také rozsáhlé, protože pokrývá jádro a základní části MySQL a storage engine.

Začněme procházet grafy.

Metriky MySQL InnoDB

Tento řídicí panel je skvělý pro každého uživatele MySQL DBA nebo ops, protože nabízí velmi dobrý pohled do úložiště InnoDB. Jsou zde určité grafy, které musí uživatel při aktivaci zvážit, protože ne ve všech situacích jsou proměnné v konfiguraci MySQL nastaveny správně.

Innodb Checkpoint Age

Podle příručky je kontrolní bod definován následovně:„Jak jsou provedeny změny na datových stránkách, které jsou uloženy v mezipaměti v vyrovnávací paměti , tyto změny se zapíší do datových souborů o něco později proces známý jako proplachování . Kontrolní bod je záznam o posledních změnách (reprezentovaný LSN value), které byly úspěšně zapsány do datových souborů “. Tento graf je užitečný, když chcete zjistit, jak váš server provádí kontrolu dat na váš disk. To může být dobrou referencí, pokud je váš transakční protokol (redo log nebo ib_logfile0) příliš velký. Tento graf je také dobrým indikátorem, pokud potřebujete upravit proměnné, jako je innodb_log_file_size,, innodb_log_buffer_size, innodb_max_dirty_pages_pct nebo innodb_adaptive_flushing_method. Čím více se stáří kontrolního bodu blíží maximálnímu stáří kontrolního bodu, tím více jsou protokoly vyplněny a InnoDB bude provádět více I/O, aby v protokolech udrželo nějaké volné místo. Mechanismus kontrolních bodů se v jemných detailech liší mezi příchutěmi založenými na Percona XtraDB, MariaDB a verzí Oracle, rozdíly v jeho implementaci můžete také najít mezi verzemi MySQL.
Transakce InnoDB

Kdykoli na vašem serveru MySQL probíhá velká transakce, je tento graf dobrou referencí. Bude počítat transakce, které byly vytvořeny v konkrétním čase, a délka historie (nebo je ve skutečnosti délka seznamu historie nalezená v SHOW ENGINE INNODB STATUS) je počet stránek v protokolu zpět. Trendy, které zde uvidíte, jsou dobrým zdrojem pro kontrolu, zda by to mohlo například znamenat, že čištění je zpožděno kvůli velmi vysoké rychlosti vkládání při opětovném načítání dat nebo kvůli dlouhotrvající transakci, nebo jestli čištění prostě může nedrží krok kvůli vysokému I/O disku ve svazku, kde je umístěn váš $DATADIR.
Operace řádků Innodb

U určitých úloh DBA možná budete chtít určit počet odstranění, vložení, přečtení a aktualizovaných řádků. Pak je tento graf to, co můžete použít ke kontrole.
Doba uzamčení řádku Innodb

Tento graf je dobrým zdrojem, na který se můžete podívat, když si všimnete, že vaše aplikace naráží na mnoho výskytů „Časový limit čekání na zámek byl překročen; zkuste transakci restartovat “. To vám také může pomoci určit, zda můžete mít indikaci pro použití špatných dotazů při manipulaci se zámky. To je také dobrý odkaz, na který se můžete podívat při optimalizaci vašich dotazů, které zahrnují zamykání řádků. Pokud je doba čekání příliš dlouhá, musíte zkontrolovat protokol pomalých dotazů nebo spustit pt-query-digest a zjistit, jaké jsou ty podezřelé dotazy, které způsobují nafouknutí v grafu.
InnoDB I/O

Kdykoli chcete určit množství čtení dat InnoDB, vyprázdnění disku, zápisů a zápisů do protokolu, tento graf má to, na co se musíte podívat. Tento graf můžete použít k určení, zda jsou vaše proměnné InnoDB dobře vyladěny, aby zvládly vaše specifické požadavky. Pokud například máte mezipaměť modulu Battery Backup Module, ale nedosahujete příliš jeho optimálního výkonu, můžete se spolehnout na tento graf, abyste zjistili, zda je vaše fsyncs() vyšší, než se očekávalo. Pak může problém vyřešit změna proměnné innodb_flush_method a použití O_DSYNC.
Využití souboru protokolu InnoDB každou hodinu

Tento graf ukazuje pouze počet bajtů zapsaných do souborů protokolu InnoDB redo a nárůst vašich souborů protokolu InnoDB na základě 24hodinového časového rozsahu aktuálního data.
Výkon protokolování InnoDB

Tento graf úzce souvisí s hodinovým grafem využití souboru protokolu InnoDB. Tento graf musíte použít vždy, když potřebujete určit, jak velký musí být váš innodb_log_file_size. Můžete určit počet bajtů zapsaných do souborů redo log souborů InnoDB a jak efektivně vaše MySQL vyprázdní data z paměti na disk. Kdykoli zaznamenáte nedostatek času v potřebě použít prostor redo logu, znamená to, že musíte zvětšit velikost souboru innodb_log_file. V takovém případě by vám tento graf řekl, že to musíte udělat. Chcete-li však podrobněji zjistit, kolik potřebujete pro svůj soubor innodb_log_file, může být smysluplnější zkontrolovat LSN (sekvenční číslo protokolu) v části SHOW ENGINE INNODB STATUS. Percona má s tím související dobrý blog, který je dobrým zdrojem, na který se můžete podívat.
Zablokování InnoDB

V určitých situacích, kdy váš aplikační klient často uvízne, nebo se musíte podívat na to, jak moc vaše MySQL zablokuje, tento graf slouží tomuto účelu. Zablokování značí, že máte špatný návrh SQL, což vede k tomu, že vaše transakce vytvářejí spor, který způsobuje uváznutí.

Rozložení stavu indexu

Malé slovo opatrnosti při pohledu na tento graf. Nejprve musíte určit, že máte globální proměnnou MySQL innodb_monitor_enable nastavenou na správnou hodnotu, která je module_icp. V opačném případě se zobrazí „Žádné datové body“, jak je uvedeno níže:

Účel grafu, má-li datové body definované jako to, co mám ve vzorových výstupech, poskytne DBA přehled o tom, jak dobře vaše dotazy těží z Pushdown indexu nebo zkráceně ICP. ICP je skvělá funkce v MySQL, která nabízí optimalizaci pro vaše dotazy. Místo toho, aby MySQL četl celé řádky filtrované ve vašich dotazech WHERE při načítání, přidá další kontroly za vaše sekundární indexy. To přidává větší granularitu a šetří čas, jinak musí stroj místo toho číst celé řádky tabulky, když je založen pouze na filtrovaném indexu a nepoužívá se žádný ICP. Vyhnete se tak čtení celých řádků odpovídajících vašim indexovým n-ticím, které odpovídají vašim sekundárním indexům.

Dovolte mi, abych tento graf trochu rozvedl, řekněme, že mám tabulku s názvem:

mysql> show create table a\G
*************************** 1. row ***************************
       Table: a
Create Table: CREATE TABLE `a` (
  `id` int(11) NOT NULL,
  `age` int(11) NOT NULL,
  KEY `id` (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=latin1
1 row in set (0.00 sec)

A má několik malých dat:

mysql> select * from a;
+----+-----+
| id | age |
+----+-----+
|  1 |   1 |
|  2 |   1 |
|  3 |   1 |
|  3 |  41 |
|  4 |  41 |
|  5 |   4 |
|  4 |   4 |
|  4 |   4 |
+----+-----+
8 rows in set (0.00 sec)

Když je povoleno ICP, výsledky jsou efektivnější a proveditelnější:

mysql> explain extended select * from a where id>2 and id<4 and age=41;
+----+-------------+-------+------------+-------+---------------+------+---------+------+------+----------+------------------------------------+
| id | select_type | table | partitions | type  | possible_keys | key  | key_len | ref  | rows | filtered | Extra                              |
+----+-------------+-------+------------+-------+---------------+------+---------+------+------+----------+------------------------------------+
|  1 | SIMPLE      | a     | NULL       | range | id            | id   | 4       | NULL |    2 |    12.50 | Using index condition; Using where |
+----+-------------+-------+------------+-------+---------------+------+---------+------+------+----------+------------------------------------+
1 row in set, 2 warnings (0.00 sec)

Než bez ICP,

mysql> set optimizer_switch='index_condition_pushdown=off';
Query OK, 0 rows affected (0.00 sec)

mysql> explain extended select * from a where id>2 and id<4 and age=41;
+----+-------------+-------+------------+-------+---------------+------+---------+------+------+----------+-------------+
| id | select_type | table | partitions | type  | possible_keys | key  | key_len | ref  | rows | filtered | Extra       |
+----+-------------+-------+------------+-------+---------------+------+---------+------+------+----------+-------------+
|  1 | SIMPLE      | a     | NULL       | range | id            | id   | 4       | NULL |    2 |    12.50 | Using where |
+----+-------------+-------+------------+-------+---------------+------+---------+------+------+----------+-------------+
1 row in set, 2 warnings (0.00 sec)

Toto je jednoduchý příklad ICP a toho, jak může tento graf prospět DBA.

Obsah InnoDB Buffer Pool

Při práci s MySQL a používání enginu InnoDB je tento graf jednou z nejběžnějších hodnot (innodb_buffer_pool*), kterou musíte vyladit, abyste optimalizovali výkon MySQL. Konkrétně pokud jde o obsah fondu vyrovnávacích pamětí, zobrazuje trendy pro nečisté stránky v porovnání s celkovým obsahem fondu vyrovnávacích pamětí. Celkový obsah fondu vyrovnávacích pamětí zahrnuje čisté stránky kromě špinavých stránek. Tento graf slouží k určení toho, jak efektivně vaše MySQL zpracovává zásobník vyrovnávacích pamětí.
Stránky fondu vyrovnávací paměti InnoDB

Tento graf je užitečný, když chcete zkontrolovat, jak efektivní MySQL využívá váš InnoDB buffer. Tento graf můžete použít například, pokud váš denní provoz nenaplňuje přiřazenou innodb_buffer_pool_size, pak to může znamenat, že určité části aplikace nejsou užitečné nebo neslouží žádnému účelu nebo pokud nastavíte innodb_buffer_pool_size velmi vysoko což by mohlo být dobré snížit hodnotu a získat zpět místo v paměti.
InnoDB Buffer Pool I/O

Když musíte zkontrolovat počet stránek vytvořených a zapsaných v tabulkách InnoDB nebo načtení stránek do fondu vyrovnávací paměti InnoDB pomocí operací s tabulkami InnoDB.
Požadavky na fond vyrovnávací paměti InnoDB

Pokud chcete zjistit, jak efektivně vaše dotazy přistupují k fondu vyrovnávacích pamětí InnoDB, tento graf slouží tomuto účelu. Tento graf ukazuje trendy založené na datových bodech o tom, jak váš server MySQL funguje, když motor InnoDB často přistupuje k disku (indikace fondu vyrovnávacích pamětí se ještě nezahřál), jak často požadavky fondu vyrovnávacích pamětí zpracovávaly požadavky na čtení a zápis. požadavky.
InnoDB Read-Ahead

Když máte proměnnou innodb_random_read_ahead nastavenou na ON, přidejte tento graf jako hodnotný trend, na který se můžete podívat jako na součást vaší rutiny DBA. Ukazuje trendy, jak vaše úložiště MySQL InnoDB spravuje fond vyrovnávací paměti pomocí vlákna na pozadí pro čtení napřed, jak spravuje ty, které byly následně vystěhovány, aniž by k nim byly přistupovány dotazy, a jak InnoDB spouští náhodné čtení napřed, když je dotaz skenován. velká část tabulky, ale v náhodném pořadí.
InnoDB Change Buffer

Když máte spuštěný Percona Server 5.7, je tento graf užitečný při sledování toho, jak dobře InnoDB alokovalo ukládání změn do vyrovnávací paměti. Tyto změny zahrnují vložení, aktualizace a odstranění, které jsou určeny proměnnou innodb_change_buffering. Ukládání změn do vyrovnávací paměti pomáhá urychlit dotazy a vyhnout se podstatnému I/O s náhodným přístupem, které by bylo nutné pro načtení sekundárních indexových stránek z disku.
InnoDB Change Buffer Activity

To souvisí s grafem InnoDB Change Buffer, ale rozkládá informace na životaschopnější datové body. Tyto poskytují více informací pro sledování toho, jak InnoDB zpracovává ukládání změn do vyrovnávací paměti. To je užitečné v konkrétní úloze DBA, abyste zjistili, zda je vaše innodb_change_buffer_max_size nastavena na příliš vysokou hodnotu, protože ukládání změn do vyrovnávací paměti sdílí stejnou paměť zásobníku vyrovnávacích pamětí InnoDB, čímž se snižuje paměť dostupná pro datové stránky mezipaměti. Možná budete muset zvážit vypnutí ukládání změn do vyrovnávací paměti, pokud se pracovní sada téměř vejde do fondu vyrovnávacích pamětí nebo pokud vaše tabulky mají relativně málo sekundárních indexů. Pamatujte, že ukládání změn do vyrovnávací paměti nepředstavuje zvláštní režii, protože se vztahuje pouze na stránky, které nejsou ve fondu vyrovnávacích pamětí. Tento graf je také užitečný, pokud musíte určit, jak jsou sloučení užitečná, pokud musíte svou aplikaci porovnávat na základě určitých požadavků pro konkrétní scénáře. Řekněme, že máte hromadné vkládání, musíte nastavit innodb_change_buffering=insert a určit, zda nastavení hodnot ve fondu vyrovnávací paměti a innodb_change_buffer_max_size neovlivní vstup/výstup disku, zvláště během obnovy nebo pomalého vypínání (nezbytné, pokud chcete provést převzetí služeb při selhání s nízkými požadavky na prostoje). Tento graf může také sloužit vašemu účelu k vyhodnocení určitých scénářů, protože sloučení vyrovnávací paměti změn může trvat několik hodin, pokud existuje mnoho sekundárních indexů k aktualizaci a mnoho ovlivněných řádků. Během této doby se zvýší vstup/výstup disku, což může způsobit výrazné zpomalení dotazů vázaných na disk.

Schéma výkonu MySQL

MySQL Performance Schema je složité téma. Je to dlouhé a těžké, ale budu diskutovat pouze o informacích, které jsou specifické pro grafy, které máme ve SCUMM. Existují také určité proměnné, které musíte vzít v úvahu a zajistit, aby byly správně nastaveny. Ujistěte se, že máte proměnnou innodb_monitor_enable =all a userstat=1, abyste v grafech viděli datové body. Poznámka:Když zde používám slovo „událost“, neznamená to, že to souvisí s plánovačem událostí MySQL. Mluvím o konkrétních událostech, jako je MySQL analyzuje dotaz, MySQL čte nebo zapisuje do relay/binárního log souboru atd.

Pokračujme tedy s grafy.

Performance Schema File IO (události)

Tento graf načítá datové body související s jakýmikoli událostmi, ke kterým došlo v MySQL, které mohly být instrumentovány k vytvoření více instancí instrumentovaného objektu (např. čtení binárního protokolu nebo čtení datového souboru InnoDB). Každý řádek shrnuje události pro daný název události. Pokud například existuje nástroj pro mutex, který je vytvořen pro každé připojení, může existovat mnoho instancí této instrumentované události, protože existuje více připojení. Souhrnný řádek pro nástroj shrnuje všechny tyto instance. Další informace naleznete v příručce MySQL pro souhrnné tabulky schémat výkonu.
Performance Schema File IO (Načíst)

Tento graf je stejný jako graf „Performance Schema File IO (Události)“ kromě toho, že je instrumentován na základě zatížení.
Performance Schema File IO (bajty)

Tento graf je stejný jako graf „Performance Schema File IO (Events)“ kromě toho, že je instrumentován na základě velikosti v bajtech. Například kolik času zabrala konkrétní událost, když MySQL spustila událost wait/io/file/innodb/innodb_data_file.
Schéma výkonu čeká (události)

Tento graf obsahuje datový graf pro všechna čekání strávená na konkrétní události. Další informace naleznete v tabulkách souhrnu událostí čekání v příručce.
Schéma výkonu čeká (načtení)

Stejné jako graf „Performance Schema Waits (Events)“, ale tentokrát ukazuje trendy zatížení.
Operace přístupu k indexu (načtení)

Tento graf je agregací všech událostí čekání I/O indexu tabulky seskupených podle indexu(ů) tabulky, jak je generuje nástroj wait/io/table/sql/handler. Další informace naleznete v příručce MySQL o tabulce Performance Schema table_io_waits_summary_by_index_usage.
Operace přístupu k tabulkám (načíst)

Graf „Stejné jako operace přístupu k indexu (načtení)“, je to agregace všech událostí čekání I/O tabulky seskupení po tabulce, jak je generuje nástroj wait/io/table/sql/handler. To je velmi užitečné pro DBA. Chtěli byste například sledovat, jak rychle trvá přístup (načtení) nebo aktualizace (vložení, odstranění, aktualizace) konkrétní tabulky. Další informace naleznete v příručce MySQL o tabulce Performance Schema table_io_waits_summary_by_table.
Schéma výkonu SQL a externí zámky (události)

Tento graf je agregací (počítá, kolikrát k tomu došlo) všech událostí čekání na uzamčení tabulky, jak je generuje nástroj wait/lock/table/sql/handler, který je seskupen po tabulce. Zámek SQL zde v grafu znamená vnitřní zámky. Tyto vnitřní zámky jsou normální pro čtení, čtení se sdílenými zámky, čtení s vysokou prioritou, čtení bez vložení, zápis povolený zápis, souběžné vkládání se zápisem, zpožděný zápis, zápis s nízkou prioritou, normální zápis. Zatímco externí zámky jsou externí čtení a externí zápis. V jakékoli úloze DBA je to velmi užitečné, pokud musíte sledovat a zkoumat zámky na konkrétní tabulce bez ohledu na její typ. Další informace najdete v tabulce table_lock_waits_summary_by_table.
Schéma výkonu SQL a externí zámky (v sekundách)

Stejné jako graf „Schéma výkonu SQL &externí zámky (události)“, ale specifikováno v sekundách. Pokud chcete hledat zámky stolu podle sekund, kdy zámky držely, pak je tento graf vaším dobrým zdrojem.

Závěr

Metriky InnoDB a schéma výkonu MySQL jsou některé z nejpodrobnějších a nejkomplikovanějších částí v doméně MySQL, zvláště když neexistuje žádná vizualizace, která by pomohla interpretaci. Přechod na ruční sledování a vyšetřování vám tedy může zabrat trochu času a tvrdé práce. Řídicí panely SCUMM nabízejí velmi efektivní a schůdný způsob, jak je zvládnout a snížit dodatečné zatížení jakéhokoli rutinního úkolu DBA.

V tomto blogu jste se naučili, jak používat řídicí panely pro InnoDB a Performance Schema ke zlepšení výkonu databáze. Tyto řídicí panely vám mohou zefektivnit analýzu výkonu.