Профилирование в MySQL

Percona Toolkit — это набор инструментов, который предоставляет собой расширенные средства по управлению MySQL, сбору аналитической информации и ее обработке, проведению рутинных операций, восстановлению данных и т.п. Пакет входит во все распространенные дистрибутивы Linux систем:

apt-get install percona-toolkit

После установки Вам будет доступно около 20 инструментов.

Анализ медленных запросов

Для профилирования запросов MySQL используется инструмент pt-query-digest. Перед его использованием убедитесь, что включен лог медленных запросов в my.cnf" target="_blank" title="my.cnf"> my.cnf:

log_slow_queries	/var/log/mysql/mysql-slow.log
long_query_time		1

Для того, чтобы провести анализ log файла, нужно выполнить:

pt-query-audit /var/log/mysql/mysql-query.log > digest; cat digest

После этого будет сгенерирован достаточно длинный отчет. Сверху будет приведена общая информация о всех медленных запросах:

# Attribute          total     min     max     avg     95%  stddev  median
# ============     ======= ======= ======= ======= ======= ======= =======
# Exec time           634s      1s     54s      4s      8s      6s      2s
# Lock time            7ms       0   953us    48us   167us   151us       0
# Rows sent        107.62M       0   1.52M 720.30k   1.46M 619.39k 462.39k
# Rows examine     107.62M       0   1.52M 720.30k   1.46M 619.38k 462.39k
# Query size        70.38k      45  10.94k  471.04   88.31   1.93k   49.17

Обратите внимание на медианы. В примере — половина всех запросов выполняется дольше 2 секунд — это плохо.

Ниже можно посмотреть общий профиль всех медленных запросов:

# Rank Query ID           Response time  Calls R/Call V/M   Item
# ==== ================== ============== ===== ====== ===== ==============
#    1 0x67A347A2812914DF 440.2687 69.5%   119 3.6997  1.61 SELECT stats_min
#    2 0x0212FEF8C81EF1B6  78.2438 12.3%     8 9.7805 27.12 UPDATE files
#    3 0x2D2411FF42855142  67.4195 10.6%    10 6.7419 33.64 UPDATE projects
#    4 0xE5418AFB28BC18CF  25.1232  4.0%     7 3.5890  2.62 INSERT UPDATE files

Все запросы отсортированы по общему времени выполнения time. Оптимизировать запросы нужно в таком же порядке — это даст наибольший эффект. Кроме этого обратите внимание на колонку R/Call — там указано среднее время выполнения одного запроса. В примере у второго запроса это время больше 9 секунд, следует выяснить причины.

После этого в отчете можно увидеть детальный профиль каждого запроса:

# Query 1: 0.00 QPS, 0.00x concurrency, ID 0x67A347A2812914DF at byte 98907
# Scores: V/M = 1.61
# Time range: 2014-12-12 01:00:40 to 2015-02-03 01:01:22
# Attribute    pct   total     min     max     avg     95%  stddev  median
# ============ === ======= ======= ======= ======= ======= ======= =======
# Count         77     119
# Exec time     69    440s      1s      9s      4s      8s      2s      2s
# Lock time      0       0       0       0       0       0       0       0
# Rows sent     99 107.52M   1.19k   1.52M 925.21k   1.46M 565.37k 462.39k
# Rows examine  99 107.52M   1.19k   1.52M 925.21k   1.46M 565.37k 462.39k
# Query size     8   5.68k      46      54   48.89   51.63    1.51   49.17
# String:
# Hosts        localhost
# Users        root
# Query_time distribution
#   1us
#  10us
# 100us
#   1ms
#  10ms
# 100ms
#    1s  ================================================================
#  10s+

# Tables
#    SHOW TABLE STATUS FROM `t` LIKE 'stats_min'\G
#    SHOW CREATE TABLE `t`.`stats_min`\G
SELECT * FROM `stats_min`\G

# Converted for EXPLAIN
# EXPLAIN SELECT * FROM `stats_min`\G

Эти данные покажут детальное распределение ресурсов. Следует обратить внимание на Lock time, Rows sent, Rows examine. Чем больше эти значения, тем хуже.

Самое важное

Обязательно включайте лог медленных запросов на рабочих серверах. Используйте инструмент pt-query-audit для периодической проверки медленных запросов. Проводите оптимизацию запросов по тому порядку, в котором они встречаются в отчете.

Подпишитесь на Хайлоад с помощью Google аккаунта
или закройте эту хрень