Программное окружение MySQL: Maatkit. Часть 2

Программное окружение MySQL: Maatkit. Часть 2

× Версия для печати

Продолжение, смотрите оглавление этого цикла статей на этой странице. Это вторая часть из цикла статей «Программное окружение MySQL», которая полностью посвящена теме Мониторинг сервера MySQL с помощью мощнейших сервисных Perl-утилит Maatkit.

Maatkit MySQL утилита скрипт

mk-tcp-model

Рассмотрев набор для мониторинга проблематичных SQL-запросов, переходим к группе сервисных инструментов, предназначенных для мониторинга самого сервера MySQL.

Низкоуровневая утилита mk-tcp-model фиксирует хронологию всех запросов-ответов к/от MySQL в TCP-потоке, позволяя оценить производительность системы, а также проводить моделирование проблем расширяемости исследуемого сервера данных. Например, она позволяет увидеть запросы клиентов, которые не были доставлены в MySQL (в самом простом случае это случается, когда ядро ОС «теряет» TCP/IP-пакеты находясь под нагрузкой). mk-tcp-model позволяет достаточно глубоко изучать особенности поведения сервера и его сетевого окружения.

Как пример приведем её вывод с опцией —start-end , в котором можно оценить «чистое время реакции сервера» на конкретный запрос с учетом фрагментации пакетов:


I I    I ..................... O    O

  |<---->|<---response time----->|<-->|

  ts0    ts                      end  end1

По гистограмме выше видно, что запрос физически прибыл в трех входных пакетах (буквы I), тогда как ответ был выслан в двух исходящих (буквы O), при этом время ответа сервера засекается от момента поступления маркера EOL полностью собранного запроса (по-умолчанию, это интервал от ts до end, хотя точки замера можно произвольно менять). Используя этот тип мониторинга, зачастую, тюнинг сетевой подсистемы ОС позволяет добиться заметного сокращения времени отклика на нагруженном сервере MySQL.

Пример сбора и обработки данных

В качестве дополнительного развернутого примера, рассмотрим полный цикл «готовки» аналитических данных с помощью этой утилиты, с целью их последующего изучения.

1. Самостоятельно собираем исходные данные с помощью tcpdump:

tcpdump -s 384 -i any -nnq -tttt \
      'tcp port 3306 and (((ip[2:2] - ((ip[0]&0xf)<<2))
     - ((tcp[12]&0xf0)>>2)) != 0)' \
  > /path/to/tcp-file.txt

Здесь мы выгружаем заголовки пакетов направляющиеся на MySQL-порт 3306 (игнорируя пакеты без смысловой нагрузки, такие как ack-only ).

В результате, получаем в tcp-file.txt строчки вида:

2011-09-25 10:47:18.810932 IP 10.220.146.79.35805 > 10.119.42.41.3306: tcp 83
2011-09-25 10:47:18.811021 IP 10.119.42.41.3306 > 10.220.146.79.35805: tcp 64
2011-09-25 10:47:18.811545 IP 10.250.95.31.45400 > 10.119.42.41.3306: tcp 82

2. После этого сортируем все запросы по времени их прибытия:

pt-tcp-model /path/to/tcp-file.txt > requests.txt

Получаем матрицы вида:

# start             end                elapsed  host:port 
= ================= =================  ======== =================== 
0 1304606837.810932 1304606837.811021  0.000089 10.220.146.79:35805 
1 1304606837.811545 1304606837.811778  0.000233 10.250.95.31:45400 
2 1304606837.811669 1304606837.811971  0.000302 10.243.78.239:45612 
3 1304606837.811893 1304606837.812073  0.000180 10.222.110.47:44024 
4 1304606837.813067 1304606837.813312  0.000245 10.220.146.79:35805

В общем виде эти записи будут иметь формат:

<id> <start_time> <end_time> <elapsed_time> <host_IP:port>

3. Для перехода к фазе анализа, предлагаю перевести эти данные в визуальную форму.

Для этого сортируем всё и нарезаем результат с 5-секундными интервалами:

sort -n -k1,1 requests.txt > sorted.txt
pt-tcp-model --type=requests --run-time=5 sorted.txt > sliced.txt

4. И, наконец, приводим записи к пригодному виду для их последующего анализа с помощью Aspersa’s usl tool (или аналогичного инструмента по вашему выбору):

for f in sliced.txt; do
   tail -n +2 "$f" | head -n -1 | awk '{print $2, $3, $7/$4}'
done > usl-input.txt

5. Используя вариации вышеописанных способов обработки исходных данных совместно с usl tool, получаем различные графики (для примера смотрите графики приведенные ниже), разносторонне иллюстрирующие поведение сервера под нагрузкой. После их совмещения часто ясно видны закономерности и узкие места MySQL и системы в целом.

Maatkit MySQL утилита скрипт

Отмечу, что наряду с tcpdump, для получения исходных данных иногда более выгодно использовать похожую утилиту — tcprstat (инструмент сбора статистики из “сырого” TCP/IP).

Всякая мониторинговая мелочь

Следующие утилиты из этого раздела:

mk-loadavg — резидентно следит за параметрами работы сервера и запускает заранее указанные скрипты, если текущая нагрузка сервера БД превышает ранее заданную;
mk-error-log — парсит лог-файлы MySQL, после чего выделяет все новые записи (или только ранее заданные администратором типы сообщений, например, выделяя все ошибки по уровню их критичности).

Здесь mk-error-log позволяет с помощью регулярных выражений задавать маски для выделения нужных сообщений (и выполнять их группировки в различные категории, если это нужно для текущей задачи). Это делает возможным её использование для оперативного мониторинга любых типов записей в лог-файлах MySQL.

Ниже приводится пример вывода простейшей статистики после обработки лога с 7 контролируемыми типами записей общего характера:

Count Level   Message                                           
  ===== ======= ==================================================
      5 info    mysqld started                                    
      4 info    mysqld version info                               
      3 info    InnoDB: Started                                   
      2 info    mysqld ended                                      
      1 unknown Number of processes running now: 0                
      1 error   [ERROR] /usr/sbin/mysqld: unknown variable 'ssl-ke
      1 error   [ERROR] Failed to initialize the master info struc

Для ускорения своей работы, mk-error-log позволяет настроить парсинг лог-файла по мере его роста, стартуя с места последнего сгенерированного отчета, в этом случае текущий счетчик состояния смещения в лог-файле можно узнать так:


mk-error-log –resume[br][br]

 

file:/var/log/mysql/mysqld.err 

  inode:12345

  pos:67890

  size:987100

Следующая утилита, mk-config-diff , — сравнивает конфигурационные файлы и текущие серверные переменные разных MySQL-серверов, что очень удобно для наглядного сравнительного изучения настроек целого парка из подобных серверов.

Вот простейший пример выдачи найденных отличий на двух рассмотренных компьютерах:

2 config differences:
  Variable                  my.master.cnf   my.slave.cnf
  ========================= =============== ===============
  datadir                   /tmp/12345/data /tmp/12346/data
  port                      12345           12346

Кстати говоря, для анализа переменных у конкретного сервера больше подходит команда mk-variable-advisor , считывающая текущие настройки MySQL (данные для этого берутся из разных источников, таких, как выдача команд SHOW VARIABLES, SHOW STATUS, SHOW SLAVE STATUS и так далее), после чего отчитывается о возможных проблемах или коллизиях в настройках.

Что очень удобно, утилита позволяет составлять свои собственные правила для подобного автоматического тестирования серверов по заданным критериям.

Начало этой серии статей здесь. Следующую часть (продолжение) — читайте вот тут.