Výkon MySQL:Identifikace dlouhých dotazů

Každá aplikace podporovaná MySQL může těžit z jemně vyladěného databázového serveru. Tým Liquid Web Heroic Support se v průběhu let setkal s mnoha situacemi, kdy některé drobné úpravy výrazně změnily výkon webových stránek a aplikací. V této sérii článků jsme nastínili některá běžnější doporučení, která měla největší dopad na výkon.

Předletová kontrola

Tento článek se týká většiny serverů MySQL VPS založených na Linuxu. To zahrnuje, ale není omezeno na, jak tradiční vyhrazené, tak cloudové VPS servery, na kterých běží různé běžné distribuce Linuxu. Článek lze použít s následujícími typy systémů Liquid Web:

• CentOS 6x/7x spravovaný jádrem
• Ubuntu 14.04/16.04 spravované jádrem
• Plně spravovaný cPanel CentOS 6/7
• Plně spravovaný CentOS 7 Plesk Onyx 17
• Samostatně spravované servery Linux

Tato série článků předpokládá obeznámenost s následujícími základními koncepty správy systému:

• Připojení SSH a základní navigace ve standardním prostředí příkazového řádku Linuxu.
• Otevírání, úpravy a ukládání souborů ve Vimu nebo ve vybraném systémovém editoru.
• Interaktivní režim MySQL a obecná syntaxe dotazů MySQL.

Co je optimalizace MySQL?

Pro pojem optimalizace MySQL neexistuje žádná jasně definovaná definice. Může to znamenat něco jiného v závislosti na osobě, správci, skupině nebo společnosti. Pro tuto sérii článků o optimalizaci MySQL budeme optimalizaci MySQL definovat jako: Konfiguraci serveru MySQL nebo MariaDB, který byl nakonfigurován tak, aby se vyhnul běžně se vyskytujícím úzkým místům, o kterých se v této sérii článků pojednává.

Co je to úzké hrdlo?

Úzké hrdlo jako technický termín je velmi podobné hrdlu na láhvi se sodou a představuje bod v konfiguraci aplikace nebo serveru, kterým může bez problémů projít malé množství provozu nebo dat. Větší objem stejného typu provozu nebo dat je však omezován nebo blokován a nemůže úspěšně fungovat tak, jak je. Viz následující příklad úzkého hrdla konfigurace:

V tomto příkladu je server schopen zpracovat 10 připojení současně. Konfigurace však přijímá pouze 5 připojení. Tento problém se neprojeví, pokud existuje 5 nebo méně připojení najednou. Když však provoz naroste na 10 připojení, polovina z nich začne selhávat kvůli nevyužitým prostředkům v konfiguraci serveru. Výše uvedené příklady ilustrují tvar úzkého hrdla, kde odvozuje svůj název, oproti optimalizované konfiguraci, která koriguje úzké hrdlo.

Kdy bych měl optimalizovat databázi MySQL?

V ideálním případě by ladění výkonu databáze mělo probíhat pravidelně a dříve, než bude ovlivněna produktivita. Nejlepším postupem je provádět týdenní nebo měsíční audity výkonu databáze, aby se předešlo problémům s nepříznivým vlivem na aplikace. Nejzjevnější příznaky problémů s výkonem jsou:

• Dotazy se v tabulce procesů MySQL hromadí a nikdy se nedokončí.
• Aplikace nebo webové stránky využívající databázi se zpomalují.
• Chyby vypršení časového limitu připojení, zejména ve špičce.

I když je normální, že na zaneprázdněném systému běží několik souběžných dotazů najednou, stává se problémem, když tyto dotazy pravidelně dokončují příliš dlouho. Ačkoli se konkrétní práh liší podle systému a aplikace, průměrné doby dotazů přesahující několik sekund se projeví jako zpomalení připojených webových stránek a aplikací. Tato zpomalení mohou někdy začít malá a zůstat nepovšimnuta, dokud velký nárůst provozu nezasáhne konkrétní úzké místo.

Identifikace problémů s výkonem

Vědět, jak zkoumat tabulku procesů MySQL, je zásadní pro diagnostiku konkrétního úzkého místa, na které narazíte. Existuje několik způsobů, jak zobrazit tabulku procesů v závislosti na konkrétním serveru a preferencích. Pro stručnost se tato série zaměří na nejběžnější metody používané prostřednictvím přístupu Secure Shell (SSH):

Metoda 1. Použití tabulky procesů MySQL

Použijte ‘mysqladmin “ nástroj příkazového řádku s příznakem „processlist “ nebo „proc 've zkratce. (Přidání příznaku „statistiky “ nebo „stat ’ ve zkratce zobrazí statistiky běhu pro dotazy od posledního restartu MySQL.)

Příkaz:

mysqladmin proc stat

Výstup:

 +-------+------+-----------+-----------+---------+------+-------+
 | Id    | User | Host      | db        | Command | Time | State | Info               | Progress |
 +-------+------+-----------+-----------+---------+------+-------+--------------------+----------+
 | 77255 | root | localhost | employees | Query   | 150  |       | call While_Loop2() | 0.000    |
 | 77285 | root | localhost |           | Query   | 0    | init  | show processlist   | 0.000    |
 +-------+------+-----------+-----------+---------+------+-------+--------------------+----------+
 Uptime: 861755  Threads: 2  Questions: 20961045  Slow queries: 0  Opens: 2976  Flush tables: 1  Open tables: 1011  Queries per second avg: 24.323

Metoda 2:Použití tabulky procesů MySQL

Spusťte dotaz „show processlist;“ z výzvy interaktivního režimu MySQL. (Apřidání „ plné Modifikátor ‘  příkazu zakáže zkrácení Informace sloupec. To je nutné při prohlížení dlouhých dotazů.)

Příkaz:

show processlist;

Výstup:

MariaDB [(none)]> show full processlist;
 +-------+------+-----------+-----------+---------+------+-------+-----------------------+----------+
 | Id    | User | Host      | db        | Command | Time | State | Info                  | Progress |
 +-------+------+-----------+-----------+---------+------+-------+-----------------------+----------+
 | 77006 | root | localhost | employees | Query   |  151 | NULL  | call While_Loop2()    |    0.000 |
 | 77021 | root | localhost | NULL      | Query   |    0 | init  | show full processlist |    0.000 |
 +-------+------+-----------+-----------+---------+------+-------+-----------------------+----------+

Použití protokolu pomalých dotazů

Dalším cenným nástrojem v MySQL je zahrnutá funkce pomalého protokolování dotazů. Tato funkce je preferovanou metodou pro pravidelné hledání dlouhotrvajících dotazů. Pro úpravu této funkce je k dispozici několik direktiv. Nejčastěji potřebná nastavení jsou však:

Tyto direktivy se nastavují v sekci [mysqld] konfiguračního souboru MySQL na adrese /etc/my.cnf a než se projeví, budou vyžadovat restart služby MySQL. Viz příklad níže pro formátování:

[mysqld]
 log-error=/var/lib/mysql/mysql.err
 innodb_file_per_table=1
 default-storage-engine=innodb
 innodb_buffer_pool_size=128M
 innodb_log_file_size=128M
 max_connections=300
 key_buffer_size = 8M
 slow_query_log=1
 slow_query_log_file=/var/lib/mysql/slowquery.log
 long_query_time=5

Jakmile je protokol pomalých dotazů povolen, budete jej muset pravidelně sledovat a kontrolovat nepoddajné dotazy, které je třeba upravit pro lepší výkon. Chcete-li analyzovat soubor protokolu pomalého dotazu, můžete jej analyzovat přímo a zkontrolovat jeho obsah. Následující příklad ukazuje statistiku pro ukázkový dotaz, který běžel déle než nakonfigurovaných 5 sekund:

# Time: 180717  0:23:28
 # User@Host: root[root] @ localhost []
 # Thread_id: 32  Schema: employees  QC_hit: No
 # Query_time: 627.163085  Lock_time: 0.000021  Rows_sent: 0  Rows_examined: 0
 # Rows_affected: 0
 use employees;
 SET timestamp=1531801408;
 call While_Loop2();

Volitelně můžete použít nástroj příkazového řádku mysqldumpslow, který analyzuje soubor protokolu pomalého dotazu a seskupuje jako dotazy dohromady kromě hodnot čísel a řetězcových dat:

~ $ mysqldumpslow -a /var/lib/mysql/slowquery.log
 Reading mysql slow query log from /var/lib/mysql/slowquery.log
 Count: 2  Time=316.67s (633s)  Lock=0.00s (0s)  Rows_sent=0.5 (1), Rows_examined=0.0 (0), Rows_affected=0.0 (0), root[root]@localhost
 call While_Loop2()

(Informace o použití naleznete v dokumentaci k MySQL zde – mysqldumpslow – shrnutí protokolů pomalých dotazů)

Závěr

Tím končí první část naší série Optimalizace databáze a poskytuje nám pevný základ, na který se můžeme odvolávat pro účely srovnávacích testů. Přestože problémy s databázemi mohou být komplikované, naše série tyto koncepty rozebere a poskytne prostředky k optimalizaci vaší databáze pomocí konverze databáze, konverze tabulek a indexování.

Jak vám můžeme pomoci?

Jsme hrdí na to, že jsme nejužitečnějšími lidmi v hostingu™!

Naše týmy podpory jsou plné zkušených linuxových techniků a talentovaných systémových administrátorů, kteří důvěrně znají různé technologie webhostingu, zejména ty, které jsou popsány v tomto článku.

Máte-li jakékoli dotazy týkající se těchto informací, jsme vždy k dispozici, abychom odpověděli na jakékoli dotazy týkající se problémů souvisejících s tímto článkem, 24 hodin denně, 7 dní v týdnu 365 dní v roce.

Pokud jste plně spravovaný server VPS, vyhrazený pro cloud, privátní cloud VMWare, soukromý nadřazený server, spravované cloudové servery nebo vlastníte vyhrazený server a není vám příjemné provádět kterýkoli z uvedených kroků, můžete kontaktovat telefonicky na @800.580.4985, chat nebo lístek podpory, který vám pomůže s tímto procesem.