Продолжение, смотрите оглавление этого цикла статей на этой странице. Это вторая часть из цикла статей «Программное окружение MySQL», которая полностью посвящена теме Мониторинг сервера MySQL с помощью мощнейших сервисных Perl-утилит Maatkit.
Рассмотрев набор для мониторинга проблематичных 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 и системы в целом.
Отмечу, что наряду с tcpdump, для получения исходных данных иногда более выгодно использовать похожую утилиту — tcprstat (инструмент сбора статистики из “сырого” TCP/IP).
Следующие утилиты из этого раздела:
Здесь 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
и так далее), после чего отчитывается о возможных проблемах или коллизиях в настройках.
Что очень удобно, утилита позволяет составлять свои собственные правила для подобного автоматического тестирования серверов по заданным критериям.
~
Начало этой серии статей здесь. Следующую часть (продолжение) — читайте вот тут.