MySQL Performance Cheat Sheet

MySQL je rozsáhlé a má spoustu oblastí k optimalizaci a vyladění pro požadovaný výkon. Některé změny lze provádět dynamicky, jiné vyžadují restart serveru. Je docela běžné najít instalaci MySQL s výchozí konfigurací, i když ta nemusí být sama o sobě vhodná vzhledem k vaší pracovní zátěži a nastavení.

Zde jsou klíčové oblasti v MySQL, které jsem převzal z různých expertních zdrojů ve světě MySQL, stejně jako naše vlastní zkušenosti zde na Somenines. Tento blog by posloužil jako váš cheat pro vyladění výkonu a aby vaše MySQL byla opět skvělá :-)

Pojďme se na ně podívat nastíněním klíčových oblastí v MySQL.

Systémové proměnné

MySQL má spoustu proměnných, které můžete změnit. Některé proměnné jsou dynamické, což znamená, že je lze nastavit pomocí příkazu SET. Jiné vyžadují restart serveru poté, co jsou nastaveny v konfiguračním souboru (např. /etc/my.cnf, etc/mysql/my.cnf). Nicméně se podívám na běžné věci, které je docela běžné vyladit, aby byl server optimalizován.

sort_buffer_size

Tato proměnná řídí, jak velká je vyrovnávací paměť pro řazení souborů, což znamená, že kdykoli dotaz potřebuje seřadit řádky, použije se hodnota této proměnné k omezení velikosti, kterou je třeba alokovat. Uvědomte si, že tato proměnná je pro každý dotaz, který je zpracován (nebo pro připojení), což znamená, že když nastavíte vyšší hodnotu a máte více připojení, která vyžadují řazení vašich řádků, bude to mít nedostatek paměti. Své potřeby však můžete sledovat kontrolou globální stavové proměnné Sort_merge_passes. Pokud je tato hodnota velká, měli byste zvážit zvýšení hodnoty systémové proměnné sort_buffer_size. V opačném případě to vezměte na mírný limit, který potřebujete. Pokud toto nastavíte příliš nízko nebo pokud máte ke zpracování velké dotazy, může být efekt řazení řádků pomalejší, než se očekávalo, protože data jsou načítána náhodně při procházení disků. To může způsobit snížení výkonu. Nejlepší je však své dotazy opravit. V opačném případě, pokud je vaše aplikace navržena pro stahování velkých dotazů a vyžaduje třídění, je efektivní použít nástroje, které zpracovávají ukládání dotazů do mezipaměti, jako je Redis. Ve výchozím nastavení je v MySQL 8.0 aktuální nastavená hodnota 256 kB. Nastavte toto pouze v případě, že máte dotazy, které intenzivně využívají nebo volají druhy.

read_buffer_size

Dokumentace MySQL uvádí, že pro každý požadavek, který provádí sekvenční skenování tabulky, přiděluje vyrovnávací paměť pro čtení. Systémová proměnná read_buffer_size určuje velikost vyrovnávací paměti. Je také užitečná pro MyISAM, ale tato proměnná ovlivňuje také všechny úložné stroje. U tabulek MEMORY se používá k určení velikosti paměťového bloku.

V podstatě každé vlákno, které provádí sekvenční skenování tabulky MyISAM, alokuje vyrovnávací paměť této velikosti (v bajtech) pro každou tabulku, kterou skenuje. Platí to pro všechny úložné stroje (včetně InnoDB), takže je užitečné pro dotazy, které třídí řádky pomocí ORDER BY a ukládají jeho indexy do mezipaměti v dočasném souboru. Pokud provádíte mnoho sekvenčních skenů, hromadné vkládání do tabulek oddílů, ukládání výsledků vnořených dotazů do mezipaměti, zvažte zvýšení jeho hodnoty. Hodnota této proměnné by měla být násobkem 4KB. Pokud je nastavena na hodnotu, která není násobkem 4KB, bude její hodnota zaokrouhlena dolů na nejbližší násobek 4KB. Počítejte s tím, že nastavení na vyšší hodnotu spotřebuje velkou část paměti vašeho serveru. Doporučuji to nepoužívat bez řádného srovnávání a monitorování vašeho prostředí.

read_rnd_buffer_size

Tato proměnná se zabývá čtením řádků z tabulky MyISAM v seřazeném pořadí po operaci třídění klíčů, řádky jsou čteny přes tuto vyrovnávací paměť, aby se zabránilo hledání disku. Dokumentace říká, že při čtení řádků v libovolném pořadí nebo z tabulky MyISAM v seřazeném pořadí po operaci třídění klíčů jsou řádky čteny přes tuto vyrovnávací paměť (a určovány prostřednictvím této velikosti vyrovnávací paměti), aby se zabránilo hledání disku. Nastavením proměnné na vysokou hodnotu můžete o dost zlepšit výkon ORDER BY. Jedná se však o vyrovnávací paměť přidělenou každému klientovi, takže byste neměli nastavovat globální proměnnou na vysokou hodnotu. Místo toho změňte proměnnou relace pouze z těch klientů, kteří potřebují spouštět velké dotazy. Měli byste však vzít v úvahu, že to neplatí pro MariaDB, zejména při využívání výhod MRR. MariaDB používá mrr_buffer_size, zatímco MySQL používá read_buffer_size read_rnd_buffer_size.

velikost_bufferu

Ve výchozím nastavení je hodnota 256 kB. Minimální velikost vyrovnávací paměti, která se používá pro prohledávání prostého indexu, prohledávání indexu rozsahu a spojení, která nepoužívají indexy, a proto provádějí úplné prohledávání tabulky. Používá se také optimalizací BKA (která je ve výchozím nastavení zakázána). Zvyšte jeho hodnotu, abyste získali rychlejší úplné spojení, když není možné přidat indexy. Upozornění však mohou být problémy s pamětí, pokud toto nastavíte příliš vysoko. Pamatujte, že pro každé úplné spojení mezi dvěma tabulkami je přidělena jedna vyrovnávací paměť spojení. Pro komplexní spojení mezi několika tabulkami, pro které se nepoužívají indexy, může být zapotřebí více vyrovnávacích pamětí spojení. Nejlepší je ponechat globálně nízké a nastavit vysoké v relacích (pomocí syntaxe SET SESSION), které vyžadují velká úplná spojení. Na 64bitových platformách Windows zkrátí hodnoty nad 4 GB na 4 GB-1 s varováním.

max_heap_table_size

Toto je maximální velikost v bajtech pro uživatelem vytvořené tabulky MEMORY, které mohou růst. To je užitečné, když vaše aplikace pracuje s tabulkami paměťového modulu MEMORY. Nastavení proměnné, když je server aktivní, nemá žádný vliv na existující tabulky, pokud nejsou znovu vytvořeny nebo změněny. Menší z max_heap_table_size a tmp_table_size také omezuje interní tabulky v paměti. Tato proměnná je také ve spojení s tmp_table_size, aby se omezila velikost interních tabulek v paměti (to se liší od tabulek vytvořených explicitně jako Engine=MEMORY, protože platí pouze max_heap_table_size), použije se mezi těmito dvěma podle toho, která je menší.

tmp_table_size

Největší velikost pro dočasné tabulky v paměti (nikoli tabulky MEMORY), ačkoli pokud je max_heap_table_size menší, použije se spodní limit. Pokud dočasná tabulka v paměti překročí limit, MySQL ji automaticky převede na dočasnou tabulku na disku. Zvyšte hodnotu tmp_table_size (a max_heap_table_size v případě potřeby), pokud provádíte mnoho pokročilých dotazů GROUP BY a máte velký dostupný paměťový prostor. Počet vytvořených interních dočasných tabulek na disku můžete porovnat s celkovým počtem vytvořených interních dočasných tabulek porovnáním hodnot proměnných Created_tmp_disk_tables a Created_tmp_tables. V ClusterControl to můžete sledovat pomocí Dashboard -> Graf Temporary Objects.

table_open_cache

Hodnotu této proměnné můžete zvýšit, pokud máte v sadě dat velký počet tabulek, ke kterým často přistupujete. Bude použito pro všechna vlákna, to znamená na bázi připojení. Hodnota udává maximální počet tabulek, které může server ponechat otevřené v jedné instanci mezipaměti tabulky. I když zvýšení této hodnoty zvyšuje počet deskriptorů souborů, které mysqld vyžaduje, můžete také zvážit kontrolu hodnoty open_files_limit nebo zkontrolovat, jak velký je limit SOFT a HARD nastavený ve vašem operačním systému *nix. Zkontrolováním stavové proměnné Opened_tables můžete sledovat, zda potřebujete zvýšit mezipaměť tabulky. Pokud je hodnota Opened_tables velká a nepoužíváte FLUSH TABLES často (což pouze nutí všechny tabulky k uzavření a opětovnému otevření), měli byste zvýšit hodnotu proměnné table_open_cache. Pokud máte malou hodnotu pro table_open_cache a často se přistupuje k velkému počtu tabulek, může to ovlivnit výkon vašeho serveru. Pokud si všimnete mnoha položek v seznamu procesů MySQL se stavem „Otevírání tabulek“ nebo „Zavírání tabulek“, pak je čas upravit hodnotu této proměnné, ale vezměte na vědomí výše zmíněnou výhradu. V ClusterControl to můžete zkontrolovat v části Dashboards -> Table Open Cache Status nebo Dashboards -> Open Tables. Více informací naleznete zde.

table_open_cache_instances

Nastavení této proměnné by pomohlo zlepšit škálovatelnost a samozřejmě výkon, což by snížilo spory mezi relacemi. Hodnota, kterou zde nastavíte, omezuje počet instancí mezipaměti otevřených tabulek. Mezipaměť otevřených tabulek lze rozdělit na několik menších instancí mezipaměti o velikosti table_open_cache/table_open_cache_instances. Relace potřebuje uzamknout pouze jednu instanci, aby k ní měla přístup pro příkazy DML. Toto segmentuje přístup k mezipaměti mezi instancemi, což umožňuje vyšší výkon pro operace, které používají mezipaměť, když k tabulkám přistupuje mnoho relací. (Příkazy DDL stále vyžadují zámek celé mezipaměti, ale takové příkazy jsou mnohem méně časté než příkazy DML.) Na systémech, které běžně používají 16 nebo více jader, se doporučuje hodnota 8 nebo 16.

table_definition_cache

Definice tabulek mezipaměti, tj. zde se CREATE TABLE ukládají do mezipaměti, aby se urychlilo otevírání tabulek a pouze jedna položka na tabulku. Bylo by rozumné zvýšit hodnotu, pokud máte velký počet tabulek. Mezipaměť definic tabulek zabírá méně místa a na rozdíl od běžné mezipaměti tabulek nepoužívá deskriptory souborů. Peter Zaitsev z Percona navrhuje, zda můžete vyzkoušet nastavení vzorce níže,

The number of user-defined tables + 10% unless 50K+ tables

Vezměte však na vědomí, že výchozí hodnota je založena na následujícím vzorci omezeném na 2000.

MIN(400 + table_open_cache / 2, 2000)

Takže v případě, že máte větší počet tabulek ve srovnání s výchozím nastavením, pak je rozumné zvýšit jeho hodnotu. Vezměte v úvahu, že u InnoDB se tato proměnná používá jako měkký limit počtu instancí otevřených tabulek pro mezipaměť datového slovníku. Jakmile překročí aktuální hodnotu této proměnné, použije mechanismus LRU. Tento limit pomáhá řešit situace, ve kterých by bylo použito značné množství paměti k ukládání zřídka používaných instancí tabulek do mezipaměti do příštího restartu serveru. Instance nadřazených a podřízených tabulek se vztahy cizích klíčů tedy nejsou umístěny na seznamu LRU a mohly by způsobit vyšší limit, než je limit definovaný pomocí table_definition_cache, a během LRU nepodléhají vyřazení z paměti. Table_definition_cache navíc definuje měkký limit pro počet tabulkových prostorů InnoDB soubor na tabulku, které lze otevřít najednou, což je také řízeno innodb_open_files a ve skutečnosti se mezi těmito proměnnými použije nejvyšší nastavení, pokud jsou obě nastaveny. . Pokud není nastavena žádná proměnná, použije se tabulka_definice_cache, která má vyšší výchozí hodnotu. Pokud počet otevřených popisovačů souborů tabulkového prostoru překročí limit definovaný pomocí table_definition_cache nebo innodb_open_files, prohledá mechanismus LRU v seznamu LRU souboru tabulkového prostoru soubory, které jsou plně vyprázdněny a nejsou aktuálně rozšiřovány. Tento proces se provádí pokaždé, když je otevřen nový tabulkový prostor. Pokud neexistují žádné „neaktivní“ tabulkové prostory, žádné soubory tabulkových prostorů se neuzavřou. Mějte to na paměti.

max_allowed_packet

Toto je maximální velikost vráceného dotazu SQL nebo řádku na připojení. Hodnota byla naposledy zvýšena v MySQL 5.6. Nicméně v MySQL 8.0 (alespoň na 8.0.3) je aktuální výchozí hodnota 64 MiB. Můžete zvážit úpravu, pokud máte velké řádky BLOB, které je třeba vytáhnout (nebo přečíst), jinak můžete toto výchozí nastavení ponechat s 8.0, ale ve starších verzích je výchozí hodnota 4 MiB, takže se o to můžete postarat v případě, že dojde k chybě ER_NET_PACKET_TOO_LARGE. Největší možný paket, který lze přenést na nebo ze serveru nebo klienta MySQL 8.0, je 1 GB.

max_connections

Toto je počet povolených připojení pro váš server MySQL. Pokud zjistíte chybu v MySQL „Příliš mnoho připojení“, můžete zvážit nastavení vyšší. Ve výchozím nastavení není hodnota 151 dostatečná, zejména na produkční databázi a vzhledem k tomu, že máte větší zdroje serveru (neplýtvejte zdroji serveru, zejména pokud se jedná o vyhrazený server MySQL). Musíte však mít dostatek deskriptorů souborů, jinak vám dojdou. V takovém případě zvažte úpravu limitu SOFT a HARD vašich operačních systémů *nix a nastavte vyšší hodnotu open_files_limit v MySQL (5000 je výchozí limit). Počítejte s tím, že se velmi často stává, že aplikace neuzavře spojení s databází správně a nastavení vysoké max_connections může mít za následek nereagování nebo vysoké zatížení vašeho serveru. Použití fondu připojení na úrovni aplikace může pomoci vyřešit problém zde.

thread_cache_size

Toto je mezipaměť, aby se zabránilo nadměrnému vytváření vláken. Když se klient odpojí, vlákna klienta se umístí do mezipaměti, pokud je tam méně vláken než thread_cache_size. Požadavky na vlákna jsou uspokojeny opětovným použitím vláken převzatých z mezipaměti, pokud je to možné, a pouze když je mezipaměť prázdná, je vytvořeno nové vlákno. Tuto proměnnou lze zvýšit, aby se zlepšil výkon, pokud máte mnoho nových připojení. Pokud máte dobrou implementaci vlákna, toto obvykle neposkytuje výrazné zlepšení výkonu. Pokud však váš server vidí stovky připojení za sekundu, měli byste normálně nastavit thread_cache_size dostatečně vysoko, aby většina nových připojení používala vlákna uložená v mezipaměti. Zkoumáním rozdílu mezi stavovými proměnnými Connections a Threads_created můžete zjistit, jak efektivní je mezipaměť vláken. Při použití vzorce uvedeného v dokumentaci je 8 + (max_connections / 100) dostačující.

query_cache_size

Pro některé nastavení je tato proměnná jejich nejhorším nepřítelem. U některých systémů, které zažívají vysoké zatížení a jsou zaneprázdněny vysokými čteními, vás tato proměnná zarazí. Existují benchmarky, které byly dobře a testovány například společností Percona. Tato proměnná musí být nastavena na 0 spolu s query_cache_type =0, aby byla vypnuta. Dobrou zprávou v MySQL 8.0 je, že tým MySQL toto přestal podporovat, protože tato proměnná může skutečně způsobit problémy s výkonem. Na jejich blogu musím souhlasit, že pravděpodobně nezlepší předvídatelnost výkonu. Pokud používáte ukládání dotazů do mezipaměti, doporučuji použít Redis nebo ProxySQL.

Storage Engine – InnoDB

InnoDB je úložiště kompatibilní s ACID s různými funkcemi, které nabízí spolu s podporou cizích klíčů (deklarativní referenční integrita). Zde je třeba říci mnoho věcí, ale určité proměnné, které je třeba vzít v úvahu při ladění:

innodb_buffer_pool_size

Tato proměnná funguje jako klíčový buffer MyISAM, ale nabízí spoustu věcí. Vzhledem k tomu, že InnoDB se silně spoléhá na fond vyrovnávacích pamětí, měli byste zvážit nastavení této hodnoty obvykle na 70 % až 80 % paměti vašeho serveru. Je také výhodné, že máte větší paměťový prostor než vaše datová sada a nastavíte vyšší hodnotu pro váš buffer pool, ale ne příliš. V ClusterControl to lze sledovat pomocí našich Dashboards -> InnoDB Metrics -> InnoDB Buffer Pool Pages graf. Můžete to také sledovat pomocí SHOW GLOBAL STATUS pomocí proměnných Innodb_buffer_pool_pages*.

innodb_buffer_pool_instances

Pro vaši pracovní zátěž souběžnosti může nastavení této proměnné zlepšit souběžnost a omezit spory jako různá vlákna pro čtení/zápis na stránky uložené v mezipaměti. Minimální innodb_buffer_pool_instances by mělo být mezi 1 (minimum) a 64 (maximum). Každá stránka, která je uložena nebo čtena z fondu vyrovnávacích pamětí, je přiřazena k jedné z instancí fondu vyrovnávacích pamětí náhodně pomocí hašovací funkce. Každá oblast vyrovnávacích pamětí spravuje své vlastní volné seznamy, seznamy vyrovnávací paměti, LRU a všechny ostatní datové struktury připojené k oblasti vyrovnávacích pamětí a je chráněna vlastním mutexem oblasti vyrovnávacích pamětí. Mějte na paměti, že tato možnost se projeví pouze v případě, že innodb_buffer_pool_size>=1GiB a její velikost je rozdělena mezi instance fondu vyrovnávacích pamětí.

innodb_log_file_size

Tato proměnná je soubor protokolu ve skupině protokolů. Kombinovaná velikost souborů protokolu (innodb_log_file_size * innodb_log_files_in_group) nemůže překročit maximální hodnotu, která je o něco menší než 512 GB. Podle Vadima je větší velikost souboru protokolu lepší pro výkon, ale má to nevýhodu (významnou), o kterou se musíte starat:doba obnovy po havárii. Potřebujete vyvážit dobu obnovy ve vzácných případech zotavení po havárii a maximalizaci propustnosti během špičkových operací. Toto omezení se může promítnout do 20x delšího procesu obnovy po havárii!

Abychom to propracovali, větší hodnota by byla dobrá pro protokoly transakcí InnoDB a jsou zásadní pro dobrý a stabilní výkon zápisu. Čím větší je hodnota, tím menší je potřeba vyprázdnění kontrolního bodu ve fondu vyrovnávacích pamětí, čímž se šetří diskový vstup/výstup. Proces obnovy je však velmi pomalý, jakmile byla vaše databáze abnormálně vypnuta (zhroucení nebo zabití, buď OOM nebo náhodné). V ideálním případě můžete mít 1-2GiB ve výrobě, ale samozřejmě to můžete upravit. Srovnání těchto změn může být velkou výhodou, abyste viděli, jak si vedou, zejména po havárii.

innodb_log_buffer_size

Pro uložení I/O disku zapíše InnoDB's data změn do vyrovnávací paměti protokolu a použije hodnotu innodb_log_buffer_size s výchozí hodnotou 8MiB. To je výhodné zejména pro velké transakce, protože není nutné zapisovat protokol změn na disk před potvrzením transakce. Pokud je váš provoz při zápisu příliš vysoký (vkládání, mazání, aktualizace), zvětšení vyrovnávací paměti šetří diskový vstup/výstup.

innodb_flush_log_at_trx_commit

Když je innodb_flush_log_at_trx_commit nastaven na 1, vyrovnávací paměť protokolu se vyprázdní při každém potvrzení transakce do souboru protokolu na disku a poskytuje maximální integritu dat, ale má také dopad na výkon. Nastavení na 2 znamená, že vyrovnávací paměť protokolu se vyprázdní do mezipaměti souborů OS při každém potvrzení transakce. Důsledek 2 je optimální a zlepšuje výkon, pokud můžete zmírnit požadavky na ACID a můžete si dovolit ztratit transakce na poslední sekundu nebo dvě v případě selhání operačního systému.

innodb_thread_concurrency

S vylepšeními enginu InnoDB se doporučuje umožnit enginu řídit souběžnost tak, že ji ponecháte na výchozí hodnotě (která je nula). Pokud vidíte problémy se souběžností, můžete tuto proměnnou vyladit. Doporučená hodnota je dvojnásobek počtu CPU plus počet disků. Je to dynamická proměnná, což znamená, že ji lze nastavit bez restartování serveru MySQL.

innodb_flush_method

Tuto proměnnou však musíte vyzkoušet a otestovat na tom, který hardware vám nejlépe vyhovuje. Pokud používáte pole RAID s mezipamětí zálohovanou baterií, DIRECT_IO pomáhá snížit tlak na vstupy a výstupy. Přímý I/O není ukládán do mezipaměti, takže se vyhýbá dvojitému ukládání do vyrovnávací paměti s vyrovnávací pamětí a mezipamětí souborového systému. Pokud je váš disk uložen v SAN, O_DSYNC může být rychlejší pro zátěž s velkým čtením s většinou příkazů SELECT.

innodb_file_per_table

innodb_file_per_table je ve výchozím nastavení zapnuto od MySQL 5.6. To se obvykle doporučuje, protože se tím vyhnete velkému sdílenému tabulkovému prostoru a protože vám to umožňuje získat zpět prostor, když tabulku zrušíte nebo zkrátíte. Oddělený tabulkový prostor je také výhodný pro schéma částečného zálohování Xtrabackup.

innodb_stats_on_metadata

To se snaží udržet procento špinavých stránek pod kontrolou a před pluginem Innodb to byl opravdu jediný způsob, jak vyladit špinavé vyplachování vyrovnávací paměti. Viděl jsem však servery s 3 % znečištěných vyrovnávacích pamětí a dosahují maximálního stáří kontrolních bodů. Způsob, jakým se tím zvyšuje vyplachování špinavé vyrovnávací paměti, se také neškáluje dobře na subsystémech s vysokým io, ale efektivně pouze zdvojnásobuje vyplachování špinavé vyrovnávací paměti za sekundu, když % špinavých stránek překročí toto množství.

innodb_io_capacity

Toto nastavení, navzdory všem našim velkým naději, že umožní Innodb lépe využívat naše IO ve všech operacích, jednoduše řídí množství vyprázdnění nečistých stránek za sekundu (a další úlohy na pozadí, jako je čtení napřed). Zvětšete to, budete splachovat více za sekundu. To se nepřizpůsobí, prostě to udělá tolik iopů každou sekundu, pokud jsou k propláchnutí špinavé pufry. Účinně eliminuje jakoukoli optimalizaci konsolidace IO, pokud máte dostatečně nízkou zátěž při zápisu (to znamená, že špinavé stránky se vyprázdní téměř okamžitě, v tomto případě by nám možná bylo lépe bez protokolu transakcí). Pokud nastavíte příliš vysokou hodnotu, může také rychle zrušit čtení a zápis dat do transakčního protokolu.

innodb_write_io_threads

Řídí, kolik vláken bude mít probíhající zápisy na disk. Nejsem si jistý, proč je to stále užitečné, pokud můžete použít nativní AIO pro Linux. Ty mohou být také neužitečné u souborových systémů, které neumožňují paralelní zápis do stejného souboru více než jedním vláknem (zvláště pokud máte relativně málo tabulek a/nebo používáte globální tabulkové prostory)

innodb_adaptive_flushing

Určuje, zda se má dynamicky upravovat rychlost splachování nečistých stránek ve fondu vyrovnávacích pamětí InnoDB na základě pracovní zátěže. Dynamické nastavení rychlosti splachování má zabránit nárazům I/O aktivity. Toto je obvykle ve výchozím nastavení povoleno. Pokud je tato proměnná povolena, snaží se být chytřejší, pokud jde o agresivnější splachování na základě počtu nečistých stránek a rychlosti růstu protokolu transakcí.

innodb_dedicated_server

Tato proměnná je nová v MySQL 8.0, která se používá globálně a vyžaduje restart MySQL, protože se nejedná o dynamickou proměnnou. Jak však dokumentace uvádí, že tuto proměnnou je žádoucí povolit pouze v případě, že vaše MySQL běží na vyhrazeném serveru. V opačném případě to nepovolujte na sdíleném hostiteli ani sdílejte systémové prostředky s jinými aplikacemi. Když je toto povoleno, InnoDB provede automatickou konfiguraci množství paměti detekované pro proměnné innodb_buffer_pool_size, innodb_log_file_size, innodb_flush_method. Jedinou nevýhodou je, že nemůžete mít možnost použít požadované hodnoty na zmíněné detekované proměnné.

MyISAM

key_buffer_size

InnoDB je nyní výchozím úložištěm MySQL, výchozí hodnotu pro key_buffer_size lze pravděpodobně snížit, pokud nepoužíváte MyISAM produktivně jako součást své aplikace (ale kdo teď používá MyISAM v produkci?). Zde bych navrhoval nastavit možná 1 % RAM nebo 256 MiB na začátku, pokud máte větší paměť, a vyhradit zbývající paměť pro mezipaměť vašeho OS a vyrovnávací paměť InnoDB.

Další ustanovení o výkonu

slow_query_log

Tato proměnná samozřejmě nepomůže zvýšit váš MySQL server. Tato proměnná vám však může pomoci analyzovat dotazy s pomalým výkonem. Hodnotu lze nastavit na 0 nebo OFF pro deaktivaci protokolování. Chcete-li to povolit, nastavte jej na 1 nebo ON. Výchozí hodnota závisí na tom, zda je zadána volba --slow_query_log. Cíl pro výstup protokolu je řízen systémovou proměnnou log_output; pokud je tato hodnota NONE, nebudou zapsány žádné položky protokolu, i když je protokol povolen. Můžete nastavit název souboru nebo cíl souboru protokolu dotazů nastavením proměnné slow_query_log_file.

long_query_time

Pokud dotaz trvá déle než tento počet sekund, server zvýší stavovou proměnnou Slow_queries. Pokud je povolen protokol pomalého dotazu, dotaz se zaprotokoluje do souboru protokolu pomalého dotazu. Tato hodnota se měří v reálném čase, nikoli v čase CPU, takže dotaz, který je pod prahovou hodnotou na málo zatíženém systému, může být nad prahovou hodnotou na silně zatíženém systému. Minimální a výchozí hodnoty long_query_time jsou 0 a 10. Vezměte také na vědomí, že pokud je proměnná min_examined_row_limit nastavena> 0, nezaznamenává dotazy, i když to trvá příliš dlouho, pokud je počet vrácených řádků menší než hodnota nastavená v min_examined_row_limit.

Další informace o vyladění pomalého protokolování dotazů naleznete v dokumentaci zde.

sync_binlog

Tato proměnná určuje, jak často bude MySQL synchronizovat binlogy na disk. Ve výchozím nastavení (>=5.7.7) je toto nastaveno na 1, což znamená, že se před potvrzením transakcí synchronizuje s diskem. To však má negativní dopad na výkon kvůli zvýšenému počtu zápisů. Ale toto je nejbezpečnější nastavení, pokud chcete přísně ACID kompatibilní s vašimi otroky. Případně to můžete nastavit na 0, pokud chcete zakázat synchronizaci disku a spoléhat se na to, že OS čas od času vyprázdní binární protokol na disk. Nastavení vyšší než 1 znamená, že binlog se synchronizuje s diskem poté, co bylo shromážděno N skupin odevzdání binárního protokolu, kde N je> 1.

Vypsat/obnovit fond vyrovnávacích pamětí

Je docela běžnou věcí, že se vaše produkční databáze potřebuje zahřát po studeném startu/restartu. Vyprázdněním aktuálního fondu vyrovnávacích pamětí před restartem by došlo k uložení obsahu z fondu vyrovnávacích pamětí, a jakmile bude spuštěn, načte obsah zpět do fondu vyrovnávacích pamětí. Tím se vyhnete nutnosti zahřívat databázi zpět na mezipaměť. Vezměte na vědomí, že tato verze byla od té doby představena ve verzi 5.6, ale Percona Server 5.5 ji již má k dispozici, pro případ, že by vás to zajímalo. Chcete-li tuto funkci povolit, nastavte obě proměnné innodb_buffer_pool_dump_at_shutdown =ON a innodb_buffer_pool_load_at_startup =ON.

Hardware

Nyní jsme v roce 2019, došlo k mnoha novým vylepšením hardwaru. Obvykle neexistuje žádný tvrdý požadavek, že by MySQL vyžadovala konkrétní hardware, ale záleží na tom, co potřebujete, aby databáze dělala. Očekával bych, že tento blog nečtete, protože provádíte test, zda běží na Intel Pentium 200 MHz.

Pro CPU budou rychlejší procesory s více jádry optimální pro MySQL v nejnovějších verzích minimálně od 5.6. Procesory Intel Xeon/Itanium mohou být drahé, ale testovány pro škálovatelné a spolehlivé výpočetní platformy. Amazon dodává své instance EC2 běžící na architektuře ARM. Ačkoli jsem osobně nezkoušel spustit nebo si vzpomenout na spuštění MySQL na architektuře ARM, existují benchmarky, které byly vytvořeny před lety. Moderní CPU mohou škálovat své frekvence nahoru a dolů na základě teploty, zátěže a zásad úspory energie OS. Existuje však šance, že vaše nastavení CPU ve vašem operačním systému Linux je nastaveno na jiný guvernér. Můžete to zkontrolovat nebo nastavit pomocí regulátoru „výkonu“ takto:

echo performance | sudo tee /sys/devices/system/cpu/cpu[0-9]*/cpufreq/scaling_governor

Pro paměť je velmi důležité, aby byla vaše paměť velká a mohla odpovídat velikosti vaší datové sady. Ujistěte se, že máte swappiness =1. Můžete to zkontrolovat kontrolou sysctl nebo kontrolou souboru v procfs. Toho dosáhnete následujícím postupem:

$ sysctl -e vm.swappiness
vm.swappiness = 1

Nebo jej nastavte na hodnotu 1 následovně

$ sudo sysctl vm.swappiness=1
vm.swappiness = 1

Další skvělá věc, kterou je třeba zvážit při správě paměti, je zvažování vypnutí THP (Transparrent Huge Pages). V minulosti si vzpomínám, že jsme měli nějaké podivné problémy s využitím CPU a mysleli jsme si, že to bylo kvůli diskovým I/O. Ukázalo se, že problém byl s vláknem khugepaged jádra, které dynamicky alokuje paměť za běhu. Nejen to, během defragmentace jádra bude vaše paměť rychle alokována, když ji předá THP. Standardní paměť HugePages je předem přidělena při spuštění a během běhu se nemění. Můžete to ověřit a zakázat takto:

$ cat /sys/kernel/mm/transparent_hugepage/enabled
$ echo "never" > /sys/kernel/mm/transparent_hugepage/enabled

Pro Disk je důležité, abyste měli dobrou propustnost. Použití RAID10 je nejlepší nastavení pro databázi se záložní baterií. S příchodem flash disků, které nabízejí vysokou propustnost disku a vysoký diskový vstup/výstup pro čtení/zápis, je důležité, aby zvládaly vysoké využití disku a diskové vstupy/výstupy.

Operační systém

Většina produkčních systémů běžících na MySQL běží na Linuxu. Je to proto, že MySQL bylo testováno a testováno na Linuxu a zní to tak, že je to de facto standard pro instalaci MySQL. Nic vám však samozřejmě nebrání v jeho používání na platformě Unix nebo Windows. Bylo by snazší, kdyby byla vaše platforma otestována a existuje široká komunita, která vám pomůže v případě problémů. Většina nastavení běží na systémech RHEL/Centos/Fedora a Debian/Ubuntu. V AWS má Amazon svůj Amazon Linux, který, jak vidím, někteří také používají ve výrobě.

Při nastavení je nejdůležitější zvážit, zda váš systém souborů používá buď XFS nebo Ext4. Mezi těmito dvěma souborovými systémy jsou klady a zápory, ale nebudu zde zacházet do podrobností. Někteří říkají, že XFS překonává Ext4, ale existují také zprávy, že Ext4 překonává XFS. ZFS také vychází z obrazu jako dobrý kandidát na alternativní souborový systém. Jervin Real (z Percony) má k tomu skvělý zdroj, tuto prezentaci si můžete prohlédnout na konferenci ZFS.

Externí odkazy

https://developer.okta.com/blog/2015/05/22/tcmalloc

https://www.percona.com/blog/2012/07/05/impact-of-memory-allocators-on-mysql-performance/

https://www.percona.com/live/18/sessions/benchmark-noise-reduction-how-to-configure-your-machines-for-stable-results

https://zfs.datto.com/2018_slides/real.pdf

https://docs.oracle.com/en/database/oracle/oracle-database/12.2/ladbi/disabling-transparent-hugepages.html#GUID-02E9147D-D565-4AF8-B12A-8E6E9F74BEEA