Проблемите с производителността са често срещани проблеми при администриране на MySQL бази данни. Понякога тези проблеми всъщност се дължат на бавни заявки. В този блог ще се занимаваме с бавни заявки и как да ги идентифицираме.
Проверка на вашите бавни регистрационни файлове за заявки
MySQL има способността да филтрира и регистрира бавни заявки. Има различни начини, по които можете да ги проучите, но най-често срещаният и ефективен начин е да използвате бавните регистрационни файлове за заявки.
Първо трябва да определите дали вашите бавни регистрационни файлове за заявки са активирани. За да се справите с това, можете да отидете на вашия сървър и да заявите следната променлива:
MariaDB [(none)]> show global variables like 'slow%log%';
+---------------------+-------------------------------+
| Variable_name | Value |
+---------------------+-------------------------------+
| slow_query_log | ON |
| slow_query_log_file | /var/log/mysql/mysql-slow.log |
+---------------------+-------------------------------+
2 rows in set (0.001 sec)Трябва да се уверите, че променливата slow_query_log е настроена на ON, докато slow_query_log_file определя пътя, където трябва да поставите вашите бавни регистрационни файлове за заявки. Ако тази променлива не е зададена, тя ще използва DATA_DIR от вашата MySQL директория с данни.
Придружени от променливата slow_query_log са long_query_time и min_examined_row_limit, които оказват влияние върху това как работи бавното регистриране на заявки. По принцип бавните регистрационни файлове на заявки работят като SQL изрази, които отнемат повече от long_query_time секунди за изпълнение и също така изискват най-малко min_examined_row_limit редове за проверка. Може да се използва за намиране на заявки, които отнемат много време за изпълнение и следователно са кандидати за оптимизация и след това можете да използвате външни инструменти, за да донесете отчета вместо вас, който ще говорим по-късно.
По подразбиране административните изрази (ALTER TABLE, ANALYZE TABLE, CHECK TABLE, CREATE INDEX, DROP INDEX, OPTIMIZE TABLE и REPAIR TABLE) не попадат в бавни регистрационни файлове на заявките. За да направите това, трябва да активирате променлива log_slow_admin_statements.
Списък на процесите на заявки и монитор на състоянието на InnoDB
В нормална DBA рутина тази стъпка е най-разпространеният начин за определяне на дълго изпълняваните заявки или активни изпълнявани заявки, които причиняват влошаване на производителността. Това дори може да доведе до блокиране на сървъра ви, последвано от натрупани опашки, които бавно се увеличават поради заключване, покрито от изпълнявана заявка. Можете просто да бягате,
SHOW [FULL] PROCESSLIST;или
SHOW ENGINE INNODB STATUS \GАко използвате ClusterControl, можете да го намерите като използвате
или като използвате
Анализиране на MySQL заявки
Регистърите на бавните заявки ще ви покажат списък със заявки, които са идентифицирани като бавни, въз основа на дадените стойности в системните променливи, както бе споменато по-рано. Дефиницията на бавните заявки може да се различава в различните случаи, тъй като има определени случаи, че дори 10-секундна заявка е приемлива и пак не е бавна. Въпреки това, ако приложението ви е OLTP, много често 10-секундна или дори 5-секундна заявка е проблем или причинява влошаване на производителността на вашата база данни. MySQL дневникът на заявките ви помага за това, но не е достатъчно да отворите регистрационния файл, тъй като не ви предоставя преглед на това какви са тези заявки, как се изпълняват и каква е честотата на тяхното появяване. Следователно инструментите на трети страни могат да ви помогнат с тях.
pt-query-digest
Използването на Percona Toolkit, за който мога да кажа, че е най-разпространеният инструмент за DBA, е да използвате pt-query-digest. pt-query-digest ви предоставя изчистен преглед на конкретен отчет, идващ от вашия бавен регистър на заявките. Например, този конкретен отчет показва чиста перспектива за разбиране на отчетите за бавни заявки в конкретен възел:
# A software update is available:
# 100ms user time, 100ms system time, 29.12M rss, 242.41M vsz
# Current date: Mon Feb 3 20:26:11 2020
# Hostname: testnode7
# Files: /var/log/mysql/mysql-slow.log
# Overall: 24 total, 14 unique, 0.00 QPS, 0.02x concurrency ______________
# Time range: 2019-12-12T10:01:16 to 2019-12-12T15:31:46
# Attribute total min max avg 95% stddev median
# ============ ======= ======= ======= ======= ======= ======= =======
# Exec time 345s 1s 98s 14s 30s 19s 7s
# Lock time 1s 0 1s 58ms 24ms 252ms 786us
# Rows sent 5.72M 0 1.91M 244.14k 1.86M 629.44k 0
# Rows examine 15.26M 0 1.91M 651.23k 1.86M 710.58k 961.27k
# Rows affecte 9.54M 0 1.91M 406.90k 961.27k 546.96k 0
# Bytes sent 305.81M 11 124.83M 12.74M 87.73M 33.48M 56.92
# Query size 1.20k 25 244 51.17 59.77 40.60 38.53
# Profile
# Rank Query ID Response time Calls R/Call V/M
# ==== ================================ ============= ===== ======= =====
# 1 0x00C8412332B2795DADF0E55C163... 98.0337 28.4% 1 98.0337 0.00 UPDATE sbtest?
# 2 0xDEF289292EA9B2602DC12F70C7A... 74.1314 21.5% 3 24.7105 6.34 ALTER TABLE sbtest? sbtest3
# 3 0x148D575F62575A20AB9E67E41C3... 37.3039 10.8% 6 6.2173 0.23 INSERT SELECT sbtest? sbtest
# 4 0xD76A930681F1B4CC9F748B4398B... 32.8019 9.5% 3 10.9340 4.24 SELECT sbtest?
# 5 0x7B9A47FF6967FD905289042DD3B... 20.6685 6.0% 1 20.6685 0.00 ALTER TABLE sbtest? sbtest3
# 6 0xD1834E96EEFF8AC871D51192D8F... 19.0787 5.5% 1 19.0787 0.00 CREATE
# 7 0x2112E77F825903ED18028C7EA76... 18.7133 5.4% 1 18.7133 0.00 ALTER TABLE sbtest? sbtest3
# 8 0xC37F2569578627487D948026820... 15.0177 4.3% 2 7.5088 0.00 INSERT SELECT sbtest? sbtest
# 9 0xDE43B2066A66AFA881D6D45C188... 13.7180 4.0% 1 13.7180 0.00 ALTER TABLE sbtest? sbtest3
# MISC 0xMISC 15.8605 4.6% 5 3.1721 0.0 <5 ITEMS>
# Query 1: 0 QPS, 0x concurrency, ID 0x00C8412332B2795DADF0E55C1631626D at byte 5319
# Scores: V/M = 0.00
# Time range: all events occurred at 2019-12-12T13:23:15
# Attribute pct total min max avg 95% stddev median
# ============ === ======= ======= ======= ======= ======= ======= =======
# Count 4 1
# Exec time 28 98s 98s 98s 98s 98s 0 98s
# Lock time 1 25ms 25ms 25ms 25ms 25ms 0 25ms
# Rows sent 0 0 0 0 0 0 0 0
# Rows examine 12 1.91M 1.91M 1.91M 1.91M 1.91M 0 1.91M
# Rows affecte 20 1.91M 1.91M 1.91M 1.91M 1.91M 0 1.91M
# Bytes sent 0 67 67 67 67 67 0 67
# Query size 7 89 89 89 89 89 0 89
# String:
# Databases test
# Hosts localhost
# Last errno 0
# Users root
# Query_time distribution
# 1us
# 10us
# 100us
# 1ms
# 10ms
# 100ms
# 1s
# 10s+ ################################################################
# Tables
# SHOW TABLE STATUS FROM `test` LIKE 'sbtest3'\G
# SHOW CREATE TABLE `test`.`sbtest3`\G
update sbtest3 set c=substring(MD5(RAND()), -16), pad=substring(MD5(RAND()), -16) where 1\G
# Converted for EXPLAIN
# EXPLAIN /*!50100 PARTITIONS*/
select c=substring(MD5(RAND()), -16), pad=substring(MD5(RAND()), -16) from sbtest3 where 1\G
# Query 2: 0.00 QPS, 0.01x concurrency, ID 0xDEF289292EA9B2602DC12F70C7A041A9 at byte 3775
# Scores: V/M = 6.34
# Time range: 2019-12-12T12:41:47 to 2019-12-12T15:25:14
# Attribute pct total min max avg 95% stddev median
# ============ === ======= ======= ======= ======= ======= ======= =======
# Count 12 3
# Exec time 21 74s 6s 36s 25s 35s 13s 30s
# Lock time 0 13ms 1ms 8ms 4ms 8ms 3ms 3ms
# Rows sent 0 0 0 0 0 0 0 0
# Rows examine 0 0 0 0 0 0 0 0
# Rows affecte 0 0 0 0 0 0 0 0
# Bytes sent 0 144 44 50 48 49.17 3 49.17
# Query size 8 99 33 33 33 33 0 33
# String:
# Databases test
# Hosts localhost
# Last errno 0 (2/66%), 1317 (1/33%)
# Users root
# Query_time distribution
# 1us
# 10us
# 100us
# 1ms
# 10ms
# 100ms
# 1s ################################
# 10s+ ################################################################
# Tables
# SHOW TABLE STATUS FROM `test` LIKE 'sbtest3'\G
# SHOW CREATE TABLE `test`.`sbtest3`\G
ALTER TABLE sbtest3 ENGINE=INNODB\GИзползване на performance_schema
Бавните регистрационни файлове на заявки може да са проблем, ако нямате директен достъп до файла, като например използване на RDS или използване на напълно управлявани услуги за бази данни, като Google Cloud SQL или Azure SQL. Въпреки че може да се нуждаете от някои променливи, за да активирате тези функции, това е удобно, когато отправяте заявки за заявки, влезли във вашата система. Можете да го поръчате, като използвате стандартен SQL оператор, за да извлечете частичен резултат. Например,
mysql> SELECT SCHEMA_NAME, DIGEST, DIGEST_TEXT, COUNT_STAR, SUM_TIMER_WAIT/1000000000000 SUM_TIMER_WAIT_SEC, MIN_TIMER_WAIT/1000000000000 MIN_TIMER_WAIT_SEC, AVG_TIMER_WAIT/1000000000000 AVG_TIMER_WAIT_SEC, MAX_TIMER_WAIT/1000000000000 MAX_TIMER_WAIT_SEC, SUM_LOCK_TIME/1000000000000 SUM_LOCK_TIME_SEC, FIRST_SEEN, LAST_SEEN FROM events_statements_summary_by_digest;
+--------------------+----------------------------------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+------------+--------------------+--------------------+--------------------+--------------------+-------------------+---------------------+---------------------+
| SCHEMA_NAME | DIGEST | DIGEST_TEXT | COUNT_STAR | SUM_TIMER_WAIT_SEC | MIN_TIMER_WAIT_SEC | AVG_TIMER_WAIT_SEC | MAX_TIMER_WAIT_SEC | SUM_LOCK_TIME_SEC | FIRST_SEEN | LAST_SEEN |
+--------------------+----------------------------------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+------------+--------------------+--------------------+--------------------+--------------------+-------------------+---------------------+---------------------+
| NULL | 390669f3d1f72317dab6deb40322d119 | SELECT @@`skip_networking` , @@`skip_name_resolve` , @@`have_ssl` = ? , @@`ssl_key` , @@`ssl_ca` , @@`ssl_capath` , @@`ssl_cert` , @@`ssl_cipher` , @@`ssl_crl` , @@`ssl_crlpath` , @@`tls_version` | 1 | 0.0373 | 0.0373 | 0.0373 | 0.0373 | 0.0000 | 2020-02-03 20:22:54 | 2020-02-03 20:22:54 |
| NULL | fba95d44e3d0a9802dd534c782314352 | SELECT `UNIX_TIMESTAMP` ( ) | 2 | 0.0002 | 0.0001 | 0.0001 | 0.0001 | 0.0000 | 2020-02-03 20:22:57 | 2020-02-03 20:23:00 |
| NULL | 18c649da485456d6cdf12e4e6b0350e9 | SELECT @@GLOBAL . `SERVER_ID` | 2 | 0.0001 | 0.0001 | 0.0001 | 0.0001 | 0.0000 | 2020-02-03 20:22:57 | 2020-02-03 20:23:00 |
| NULL | dd356b8a5a6ed0d7aee2abd939cdb6c9 | SET @? = ? | 6 | 0.0003 | 0.0000 | 0.0001 | 0.0001 | 0.0000 | 2020-02-03 20:22:57 | 2020-02-03 20:23:00 |
| NULL | 1c5ae643e930af6d069845d74729760d | SET @? = @@GLOBAL . `binlog_checksum` | 2 | 0.0001 | 0.0001 | 0.0001 | 0.0001 | 0.0000 | 2020-02-03 20:22:57 | 2020-02-03 20:23:00 |
| NULL | ad5208ffa004a6ad7e26011b73cbfb4c | SELECT @? | 2 | 0.0001 | 0.0000 | 0.0000 | 0.0001 | 0.0000 | 2020-02-03 20:22:57 | 2020-02-03 20:23:00 |
| NULL | ed0d1eb982c106d4231b816539652907 | SELECT @@GLOBAL . `GTID_MODE` | 2 | 0.0001 | 0.0000 | 0.0000 | 0.0001 | 0.0000 | 2020-02-03 20:22:57 | 2020-02-03 20:23:00 |
| NULL | cb47e22372fdd4441486b02c133fb94f | SELECT @@GLOBAL . `SERVER_UUID` | 2 | 0.0001 | 0.0000 | 0.0000 | 0.0001 | 0.0000 | 2020-02-03 20:22:57 | 2020-02-03 20:23:00 |
| NULL | 73301368c301db5d2e3db5626a21b647 | SELECT @@GLOBAL . `rpl_semi_sync_master_enabled` | 2 | 0.0001 | 0.0000 | 0.0000 | 0.0000 | 0.0000 | 2020-02-03 20:22:57 | 2020-02-03 20:23:00 |
| NULL | 0ff7375c5f076ba5c040e78a9250a659 | SELECT @@`version_comment` LIMIT ? | 1 | 0.0001 | 0.0001 | 0.0001 | 0.0001 | 0.0000 | 2020-02-03 20:45:59 | 2020-02-03 20:45:59 |
| NULL | 5820f411e67a393f987c6be5d81a011d | SHOW TABLES FROM `performance_schema` | 1 | 0.0008 | 0.0008 | 0.0008 | 0.0008 | 0.0002 | 2020-02-03 20:46:11 | 2020-02-03 20:46:11 |
| NULL | a022a0ab966c51eb820da1521349c7ef | SELECT SCHEMA ( ) | 1 | 0.0005 | 0.0005 | 0.0005 | 0.0005 | 0.0000 | 2020-02-03 20:46:29 | 2020-02-03 20:46:29 |
| performance_schema | e4833a7c1365b0b4492e9a514f7b3bd4 | SHOW SCHEMAS | 1 | 0.1167 | 0.1167 | 0.1167 | 0.1167 | 0.0001 | 2020-02-03 20:46:29 | 2020-02-03 20:46:29 |
| performance_schema | 1107f048fe6d970cb6a553bd4727a1b4 | SHOW TABLES | 1 | 0.0002 | 0.0002 | 0.0002 | 0.0002 | 0.0000 | 2020-02-03 20:46:29 | 2020-02-03 20:46:29 |
...Можете да използвате таблицата performance_schema.events_statements_summary_by_digest. Въпреки че има вероятност записите в таблиците от performance_schema да бъдат изравнени, можете да решите да запишете това в конкретна таблица. Разгледайте тази външна публикация от дайджест на заявката на Percona MySQL със схема на производителност.
В случай, че се чудите защо трябва да разделим колоните с времето за изчакване (SUM_TIMER_WAIT, MIN_TIMER_WAIT_SEC, AVG_TIMER_WAIT_SEC), тези колони използват пикосекунди, така че може да се наложи да направите малко математика или някои закръгляване, за да направите той е по-четлив за вас.
Анализиране на бавни заявки с помощта на ClusterControl
Ако използвате ClusterControl, има различни начини да се справите с това. Например, в MariaDB Cluster, който имам по-долу, той ви показва следния раздел (Монитор на заявки) и неговите падащи елементи (Най-популярни заявки, Изпълняващи се заявки, Отклонения на заявки):
- Водещи заявки – обобщен списък с всичките ви най-популярни заявки, изпълнявани на всички възли на вашия клъстер от база данни
- Изпълняващи се заявки – Преглеждайте текущите изпълнявани заявки в клъстера от база данни, подобно на командата SHOW FULL PROCESSLIST в MySQL
- Отклонения на заявката – Показва заявки, които са извънредни. Отклонение е заявка, която отнема повече време от нормалната заявка от този тип.
Освен това, ClusterControl също така улавя производителността на заявката с помощта на графики, които ви предоставят бърз поглед върху това как се представя вашата система от база данни по отношение на производителността на заявката. Вижте по-долу,
Чакай, още не е свършило. ClusterControl също така предлага метрика с висока разделителна способност, използвайки Prometheus и показва много подробни показатели и улавя статистически данни в реално време от сървъра. Обсъдихме това в предишните ни блогове, които са разделени на две серии от блогове. Разгледайте блоговете на част 1 и след това на част 2. Той ви предлага как ефективно да наблюдавате не само бавните заявки, но и цялостната производителност на вашите сървъри на база данни MySQL, MariaDB или Percona.
Има и други инструменти в ClusterControl, които предоставят указатели и подсказки, които могат да доведат до бавна производителност на заявката, дори ако тя все още не е възникнала или уловена от бавния регистър на заявките. Вижте раздела за производителност, както се вижда по-долу,
тези елементи ви предоставят следното:
- Общ преглед – Можете да видите графики на различни броячи на базата данни на тази страница
- Съветници – Списъци с насрочени резултати от съветници, създадени в ClusterControl> Управление> Developer Studio с помощта на ClusterControl DSL.
- Състояние на DB – състоянието на DB предоставя бърз преглед на състоянието на MySQL във всички възли на базата данни, подобно на израза SHOW STATUS
- DB променливи – DB променливите предоставят бърз преглед на променливите на MySQL, които са зададени във всичките ви възли на базата данни, подобно на израза SHOW GLOBAL VARIABLES
- Растеж на базата данни – Предоставя обобщение на растежа на вашата база данни и таблици на дневна база за последните 30 дни.
- InnoDB Status – Извлича текущия изход на InnoDB монитор за избран хост, подобно на командата SHOW ENGINE INNODB STATUS.
- Schema Analyzer – анализира схемите на вашата база данни за липсващи първични ключове, излишни индекси и таблици, използвайки механизма за съхранение на MyISAM.
- Регистър на транзакциите – Изброява продължителни транзакции и блокирания в клъстера на базата данни, където можете лесно да видите какви транзакции причиняват блокирането. Прагът на времето за заявка по подразбиране е 30 секунди.
Заключение
Проследяването на вашия проблем с производителността на MySQL не е наистина трудно с MySQL. Има различни външни инструменти, които ви осигуряват ефективността и възможностите, които търсите. Най-важното е, че е лесен за използване и вие сте в състояние да осигурите производителност по време на работа. Поправете най-нерешените проблеми или дори избягвайте определено бедствие, преди то да може да се случи.
