Съвети за осигуряване на производителност на базата данни на MySQL - част втора

Управлението на производителността на базата данни е област, в която фирмите, когато администраторите често се оказват да отделят повече време, отколкото са очаквали.

Наблюдението и реагирането на проблеми с производителността на производствената база данни е една от най-критичните задачи в работата на администратор на база данни. Това е непрекъснат процес, който изисква постоянни грижи. Приложенията и базовите бази данни обикновено се развиват с времето; увеличаване на размера, броя на потребителите, натоварването, промените в схемата, които идват с промени в кода.

Дългосрочните заявки рядко са неизбежни в MySQL база данни. При някои обстоятелства продължителната заявка може да бъде вредно събитие. Ако ви е грижа за вашата база данни, оптимизирането на производителността на заявките и откриването на продължителни заявки трябва да се извършват редовно.

В този блог ще разгледаме по-задълбочено действителното натоварване на базата данни, особено от страна на изпълняваните заявки. Ще проверим как да проследяваме заявки, каква информация можем да намерим в MySQL метаданните, какви инструменти да използваме за анализиране на такива заявки.

Обработка на продължителните заявки

Нека започнем с проверка на продължителни заявки. На първо място, трябва да знаем естеството на заявката, независимо дали се очаква да бъде продължителна или краткотрайна заявка. Предполага се, че някои аналитични и пакетни операции са дълготрайни заявки, така че засега можем да ги пропуснем. Освен това, в зависимост от размера на таблицата, промяната на структурата на таблицата с командата ALTER може да бъде продължителна операция (особено в MySQL Galera Clusters).

• Заключване на таблицата – Таблицата е заключена чрез глобално заключване или изрично заключване на таблицата, когато заявката се опитва да осъществи достъп до нея.
• Неефективна заявка – Използвайте неиндексирани колони при търсене или присъединяване, така че MySQL отнема повече време, за да съответства на условието.
• Застой – Заявка изчаква за достъп до същите редове, които са заключени от друга заявка.
• Наборът от данни не се вписва в RAM – Ако данните от работния ви набор се вписват в този кеш, тогава заявките SELECT обикновено ще бъдат сравнително бързи.
• Неоптимални хардуерни ресурси – Това може да са бавни дискове, възстановяване на RAID, наситена мрежа и др.

Ако видите, че изпълнението на заявка отнема повече време от обикновено, проучете я.

Използване на MySQL Show Process List

​MYSQL> SHOW PROCESSLIST;

Обикновено това е първото нещо, което стартирате в случай на проблеми с производителността. SHOW PROCESSLIST е вътрешна команда на mysql, която ви показва кои нишки се изпълняват. Можете също да видите тази информация от таблицата information_schema.PROCESSLIST или от командата mysqladmin process list. Ако имате привилегията PROCESS, можете да видите всички нишки. Можете да видите информация като идентификатор на заявка, време на изпълнение, кой го изпълнява, клиентски хост и т.н. Информацията е леко предпазлива в зависимост от вкуса и разпространението на MySQL (Oracle, MariaDB, Percona)

SHOW PROCESSLIST;

+----+-----------------+-----------+------+---------+------+------------------------+------------------+----------+

| Id | User            | Host | db | Command | Time | State                  | Info | Progress |

+----+-----------------+-----------+------+---------+------+------------------------+------------------+----------+

|  2 | event_scheduler | localhost | NULL | Daemon  | 2693 | Waiting on empty queue | NULL   | 0.000 |

|  4 | root            | localhost | NULL | Query   | 0 | Table lock   | SHOW PROCESSLIST | 0.000 |

+----+-----------------+-----------+------+---------+------+------------------------+------------------+----------+

можем веднага да видим обидната заявка веднага от изхода. В горния пример това може да бъде заключване на таблица. Но колко често се взираме в тези процеси? Това е полезно само ако сте наясно с дългосрочната транзакция. В противен случай няма да знаете, докато нещо не се случи – например връзките се натрупват или сървърът става по-бавен от обикновено.

Използване на MySQL Pt-query-digest

Ако искате да видите повече информация за конкретно натоварване, използвайте pt-query-digest. pt-query-digest е Linux инструмент от Percona за анализиране на MySQL заявки. Това е част от Percona Toolkit, който можете да намерите тук. Той поддържа най-популярните 64-битови Linux дистрибуции като Debian, Ubuntu и Redhat.

За да го инсталирате, трябва да конфигурирате хранилища на Percona и след това да инсталирате пакета perona-toolkit.

Инсталирайте Percona Toolkit, като използвате вашия мениджър на пакети:

Debian или Ubuntu:

sudo apt-get install percona-toolkit

RHEL или CentOS:

sudo yum install percona-toolkit

Pt-query-digest приема данни от списъка с процеси, общ дневник, двоичен дневник, бавен дневник или tcpdump В допълнение към това е възможно да се анкетира списъкът с процеси на MySQL на определен интервал - процес която може да е ресурсоемка и далеч от идеалната, но все пак може да се използва като алтернатива.

Най-често срещаният източник за pt-query-digest е бавен журнал на заявки. Можете да контролирате колко данни ще отидат там с параметър log_slow_verbosity.

Има редица неща, които могат да доведат до по-дълго изпълнение на заявката:

• микровреме – заявки с точност до микросекунди.
• query_plan – информация за плана за изпълнение на заявката.
• innodb  – Статистика на InnoDB.
• минимално – Еквивалентно на активиране само на микровреме.
• стандартен – Еквивалентно на активиране на микровреме,innodb.
• пълен – Еквивалентно на всички други стойности ИЛИ, свързани заедно без опциите за профилиране и profiling_use_getrusage.
• профилиране – Активира профилиране на всички заявки във всички връзки.
• profiling_use_getrusage – Разрешава използването на функцията getrusage.

източник:Документация на Percona

За пълнота използвайте log_slow_verbosity=full, което е често срещан случай.

Регистър на бавените заявки

Бавният регистър на заявките може да се използва за намиране на заявки, които отнемат много време за изпълнение и следователно са кандидати за оптимизация. Регистърът на бавните заявки улавя бавни заявки (SQL изрази, които отнемат повече от long_query_time секунди за изпълнение) или заявки, които не използват индекси за търсене (log_queries_not_using_indexes). Тази функция не е активирана по подразбиране и за да я активирате, просто задайте следните редове и рестартирайте MySQL сървъра:

[mysqld]
slow_query_log=1
log_queries_not_using_indexes=1
long_query_time=0.1

Бавният регистър на заявките може да се използва за намиране на заявки, които отнемат много време за изпълнение и следователно са кандидати за оптимизация. Въпреки това, разглеждането на дълъг бавен дневник на заявки може да бъде отнемаща време задача. Има инструменти за анализиране на MySQL бавни регистрационни файлове на заявки и обобщаване на съдържанието им като mysqldumpslow, pt-query-digest.

Схема за изпълнение

Performance Schema е чудесен инструмент, наличен за наблюдение на вътрешните елементи на MySQL Server и детайлите за изпълнение на по-ниско ниво. Имаше лоша репутация в ранна версия (5.6), тъй като разрешаването му често причиняваше проблеми с производителността, но последните версии не вреди на производителността. Следните таблици в Схемата на производителността могат да се използват за намиране на бавни заявки:

• events_statements_current
• events_statements_history
• events_statements_history_long
• events_statements_summary_by_digest
• events_statements_summary_by_user_by_event_name
• events_statements_summary_by_host_by_event_name

MySQL 5.7.7 и по-нови версии включват sys схемата, набор от обекти, които помагат на администраторите на база данни и разработчиците да интерпретират данните, събрани от схемата за ефективност, в по-лесно разбираема форма. Обектите на Sys схема могат да се използват за типични случаи на използване на настройка и диагностика.

Проследяване на мрежата

Ами ако нямаме достъп до регистрационния файл на заявките или директните регистрационни файлове на приложението. В този случай бихме могли да използваме комбинация от tcpdump и pt-query digest, които биха могли да помогнат за улавяне на заявки.

$ tcpdump -s 65535 -x -nn -q -tttt -i any port 3306 > mysql.tcp.txt

След като процесът на заснемане приключи, можем да продължим с обработката на данните:

$ pt-query-digest --limit=100% --type tcpdump mysql.tcp.txt > ptqd_tcp.out

Монитор на заявки за ClusterControl

ClusterControl Query Monitor е модул в контрола на клъстер, който предоставя комбинирана информация за дейността на базата данни. Той може да събира информация от множество източници, като показване на списък с процеси или бавен журнал на заявки, и да я представя по предварително обобщен начин.

Мониторингът на SQL е разделен на три секции.

Водещи заявки

представя информацията за заявки, които отнемат значителна част от ресурси.

Изпълнение на заявки

това е процесен списък с информация, комбинирана от всички възли на клъстер на база данни в един изглед. Можете да го използвате, за да унищожите заявки, които засягат операциите на вашата база данни.

Отклонения на заявката

представете списъка със заявки с време на изпълнение, по-дълго от средното.

Заключение

Това е всичко за част втора. Този блог не е предназначен да бъде изчерпателно ръководство за това как да се подобри производителността на базата данни, но се надяваме, че дава по-ясна картина за това кои неща могат да станат съществени и някои от основните параметри, които могат да бъдат конфигурирани. Не се колебайте да ни уведомите, ако сме пропуснали някои важни в коментарите по-долу.