Производителност на MySQL:Идентифициране на дълги заявки

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

Проверка преди полета

Тази статия се отнася за повечето базирани на Linux MySQL VPS сървъри. Това включва, но не се ограничава до, както традиционните, така и облачните VPS сървъри, работещи с различни общи дистрибуции на Linux. Статията може да се използва със следните типове системи Liquid Web:

• Управляван от ядро ​​CentOS 6x/7x
• Управляван от ядро ​​Ubuntu 14.04/16.04
• Напълно управляван CentOS 6/7 cPanel
• Напълно управляван CentOS 7 Plesk Onyx 17
• Самоуправляеми Linux сървъри

Тази серия от статии предполага запознаване със следните основни концепции за системно администриране:

• SSH връзки и основна навигация в стандартната среда на командния ред на Linux.
• Отваряне, редактиране и запазване на файлове във Vim или избран системен редактор.
• Интерактивен режим на MySQL и общ синтаксис на MySQL заявка.

Какво е MySQL оптимизация?

Няма ясно дефинирана дефиниция за термина MySQL оптимизация. Може да означава нещо различно в зависимост от лицето, администратора, групата или компанията. За тази серия от статии за MySQL оптимизацията ще дефинираме MySQL оптимизацията като: Конфигурацията на MySQL или MariaDB сървър, който е конфигуриран да избягва често срещани пречки, обсъждани в тази серия от статии.

Какво е тесно място?

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

В този пример сървърът е в състояние да обработва 10 връзки едновременно. Въпреки това, конфигурацията приема само 5 връзки. Този проблем няма да се прояви, стига да има 5 или по-малко връзки наведнъж. Въпреки това, когато трафикът нараства до 10 връзки, половината от тях започват да се провалят поради неизползвани ресурси в конфигурацията на сървъра. Горните примери илюстрират формата на тесното място, където тя получава името си, спрямо оптимизирана конфигурация, която коригира тесното място.

Кога трябва да оптимизирам моята MySQL база данни?

В идеалния случай настройката на производителността на базата данни трябва да се извършва редовно и преди да бъде засегната производителността. Най-добрата практика е да провеждате седмични или месечни одити на производителността на базата данни, за да предотвратите неблагоприятно въздействие на проблемите върху приложенията. Най-очевидните симптоми на проблеми с производителността са:

• Заявките се натрупват и никога не се завършват в таблицата на процесите на MySQL.
• Приложенията или уебсайтовете, използващи базата данни, стават бавни.
• Грешки при изчакване на връзката, особено в пиковите часове.

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

Идентифициране на проблеми с производителността

Познаването как да изследвате таблицата на процесите на MySQL е жизненоважно за диагностицирането на специфичното затруднение, което се среща. Има няколко начина за преглед на таблицата с процеси в зависимост от вашия конкретен сървър и предпочитания. За краткост тази серия ще се съсредоточи върху най-често срещаните методи, използвани чрез Secure Shell (SSH) достъп:

Метод 1. Използване на MySQL Process Table

Използвайте „mysqladmin ’ инструмент на командния ред с флага „списък на процеси “ или „proc ' на кратко. (Добавяне на флага „статистика “ или „stat ’ накратко ще покаже текущи статистически данни за заявки след последното рестартиране на MySQL.)

Команда:

mysqladmin proc stat

Изход:

 +-------+------+-----------+-----------+---------+------+-------+
 | 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

Метод 2:Използване на MySQL Process Table

Изпълнете заявката „show processlist;“ от подканата за интерактивен режим на MySQL. (Добавяне на „ пълен ’  модификатор към командата деактивира отрязването на Информация колона. Това е необходимо, когато преглеждате дълги заявки.)

Команда:

show processlist;

Изход:

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 |
 +-------+------+-----------+-----------+---------+------+-------+-----------------------+----------+

Използване на дневника на бавните заявки

Друг ценен инструмент в  MySQL е включената функция за бавно регистриране на заявки. Тази функция е предпочитаният метод за редовно намиране на дълготрайни заявки. Има няколко налични директиви за регулиране на тази функция. Въпреки това, най-често необходимите настройки са:

Тези директиви са зададени в секцията [mysqld] на конфигурационния файл на MySQL, намиращ се в /etc/my.cnf и ще изискват рестартиране на MySQL услугата, преди да влязат в сила. Вижте примера по-долу за форматиране:

[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

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

# 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();

По избор можете да използвате инструмента от командния ред mysqldumpslow, който анализира бавния регистрационен файл на заявките и групира заедно като заявки, с изключение на стойности на числови и низови данни:

~ $ 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()

(За информация за употреба посетете документацията на MySQL тук - mysqldumpslow — Обобщение на бавни регистрационни файлове на заявките)

Заключение

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

Как можем да помогнем?

Гордеем се, че сме най-полезните хора в хостинг™!

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

Ако имате въпроси относно тази информация, ние винаги сме на разположение, за да отговорим на всички въпроси, свързани с тази статия, 24 часа в денонощието, 7 дни в седмицата, 365 дни в годината.

Ако сте напълно управляван VPS сървър, Cloud Dedicated, VMWare Private Cloud, Private Parent Server, Managed Cloud Servers, или собственик на специален сървър и се чувствате неудобно да изпълнявате някоя от описаните стъпки, ние можете да се свържете по телефона на @800.580.4985, чат или билет за поддръжка, за да ви помогнем с този процес.