Как измерить производительность MySQL Query с mysqlslap

Мы начнем с использования функции mysqlslap auto-generate-sql. Когда мы используем автоматически сгенерированный SQL, mysqlslap создаст отдельную временную базу данных - метко названную mysqlslap. В этой базе данных будет простая таблица с одним целым числом и одним столбцом типа varchar, заполненным примерами данных. Это может быть быстрый и простой способ проверить общую производительность сервера базы данных.

Мы начинаем с тестирования одного клиентского соединения, выполняя одну итерацию автоматически сгенерированного SQL:

Вывод должен выглядеть так:

mysqlslap сообщает несколько сравнительных статистических данных, как показано в выходных данных. Он сообщает среднее, минимальное и максимальное количество секунд, необходимое для выполнения запроса. Мы также видим, что число клиентских подключений, использованных для этого нагрузочного теста, было одним.

Теперь попробуйте 50 одновременных подключений, и автоматически сгенерированный запрос будет выполнен 10 раз:

Эта команда означает, что каждое из пятидесяти смоделированных клиентских подключений будет выдавать один и тот же тестовый запрос одновременно, и этот тест будет повторяться десять раз.

Вывод показывает нам заметную разницу с увеличенной нагрузкой:

Обратите внимание, что поле теперь показывает значение 50. Среднее количество запросов на одного клиента равно нулю.

Автоматически сгенерированный SQL создает простую таблицу с двумя полями. В большинстве производственных сред структура таблиц будет намного больше этой. Мы можем поручить mysqlslap эмулировать это, добавив дополнительные поля в тестовую таблицу. Для этого мы можем использовать два новых параметра: + - number-char-cols + и + - number-int-cols +. Эти параметры указывают количество типов столбцов varchar и int, добавляемых в тестовую таблицу.

В следующем примере мы тестируем автоматически сгенерированный SQL-запрос, который запускается для таблицы с 5 числовыми столбцами и 20 столбцами типов символов. Мы также моделируем 50 клиентских подключений и хотим, чтобы тест повторился 100 раз:

Это должно занять немного больше времени. Пока тест выполняется, мы можем переключиться на другое окно терминала, где у нас запущен сеанс MySQL, и посмотреть, что происходит. Обратите внимание, что если вы будете ждать слишком долго, тест будет завершен, и вы не сможете увидеть тестовую базу данных.

Из подсказки MySQL:

Обратите внимание на базу данных:

Вы можете проверить таблицу в тестовой базе данных, если хотите; это называется * t1 *.

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

Вернитесь к сеансу терминала MySQL. Мы видим, что mysqlslap удалил свою одноразовую базу данных. В приглашении MySQL:

Автоматически сгенерированный SQL хорош, если вы оцениваете физические ресурсы сервера. Это полезно, когда вы хотите определить уровень нагрузки, которую может принять данная система.

Однако, если вы хотите устранить неполадки производительности для конкретного приложения, зависящего от базы данных, вам нужно протестировать реальные запросы на реальных данных. Эти запросы могут поступать с вашего веб-сервера или сервера приложений.

Сейчас мы предполагаем, что вы знаете конкретный запрос, который хотите протестировать. В следующем разделе мы покажем вам способ поиска запросов, которые выполняются на вашем сервере.

Мы начнем с внутренних запросов. Вы можете дать встроенный запрос к mysqlslap с помощью опции. В операторах SQL не должно быть разрывов строк, и они должны быть разделены точками с запятой (;). Запросы также должны быть заключены в двойные кавычки.

В следующем фрагменте кода мы выполняем простой запрос к таблице. Таблица deptemp содержит более трехсот тысяч записей. Обратите внимание, как мы указали базу данных с помощью опции:

Это займет некоторое время, чтобы бежать. Вы должны получить эталонный тест производительности через минуту или две:

(Примечание. Если этот запрос зависает более чем на десять минут или не выдает никаких результатов, попробуйте повторить его с меньшим числом для и / или или попробуйте на большем сервере.)

Далее мы будем использовать несколько операторов SQL в параметре. В следующем примере мы завершаем каждый запрос точкой с запятой. mysqlslap знает, что мы используем несколько отдельных команд SQL, потому что мы указали параметр:

В этом тесте используется одинаковое количество соединений и одинаковое количество итераций. Тем не менее, производительность была несколько медленнее для нескольких операторов SELECT (в среднем 23,8 секунды против 18,486 секунд):

Производственные операторы SQL могут быть сложными. Проще добавить сложный оператор SQL в скрипт, чем набирать его для тестов. Итак, мы можем дать команду mysqlslap прочитать запрос из файла скрипта.

Чтобы проиллюстрировать это, давайте создадим файл сценария из команд SQL. Мы можем использовать фрагмент кода ниже, чтобы создать такой файл:

Файл теперь содержит все пять операторов SELECT.

Поскольку этот скрипт имеет несколько запросов, мы можем ввести новую концепцию тестирования. mysqlslap может parallelize запросы. Мы можем сделать это, указав количество запросов, которые должен выполнить каждый тестовый клиент. mysqlslap делает это с опцией. Таким образом, если у нас будет 50 подключений и 1000 запросов, каждый клиент выполнит примерно 20 запросов каждое.

Наконец, мы также можем использовать переключатель, который даст нам представление об используемых вычислительных ресурсах.

В следующем фрагменте кода мы просим mysqlslap использовать файл сценария, который мы только что создали. Мы также указываем параметр. Процесс будет повторен дважды, и мы хотим отладить информацию в выводе:

После завершения этой команды мы можем увидеть некоторые интересные результаты:

Здесь среднее количество секунд для выполнения всех запросов в нашем экземпляре MySQL составляет 217 секунд, почти 4 минуты. Хотя это, безусловно, зависело от объема ОЗУ и ЦП, доступных для нашей виртуальной машины, это также было связано с большим количеством запросов от умеренного числа клиентских подключений, повторяющихся дважды.

Мы видим большое количество нефизических ошибок страниц. Сбои страниц происходят, когда данные не могут быть найдены в памяти, и система должна пойти и извлечь их из файла подкачки на диске. Выходные данные также показывают информацию, связанную с процессором. В этом случае мы видим большое количество переключений контекста.

До сих пор в наших примерах мы выполняли запросы к исходной базе данных сотрудников. Это то, что администраторы БД определенно не захотят, чтобы вы делали. И тому есть веская причина. Вы не хотите добавлять загрузку своей производственной базы данных и не хотите запускать тестовые запросы, которые могут удалять, обновлять или вставлять данные в ваши производственные таблицы.

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

Что еще более важно, мы покажем вам, как записывать запросы в реальном времени из производственной базы данных и добавлять их в сценарий тестирования. То есть вы будете получать запросы из производственной базы данных, но запускать тесты для тестовой базы данных.

Основные шаги заключаются в следующем, и вы можете использовать их для любого теста mysqlslap:

Для начала давайте создадим резервную копию базы данных сотрудников. Мы создадим отдельный каталог для его резервного копирования:

Создайте резервную копию и переместите ее в новый каталог:

Перейдите на свой тестовый сервер MySQL. Создайте базу данных:

На этом этапе, если вы используете отдельный сервер для тестирования, вы должны скопировать файл на него. Из сеанса основного терминала импортируйте данные резервной копии в базу данных:

На вашем * производственном сервере баз данных MySQL * включите общий журнал запросов MySQL и укажите для него имя файла. Общий журнал запросов фиксирует действия по подключению, отключению и запросу для экземпляра базы данных MySQL.

Теперь запустите запросы, которые вы хотите проверить на рабочем сервере MySQL. В этом примере мы запустим запрос из командной строки. Однако вы можете захотеть генерировать запросы из вашего приложения, а не запускать их напрямую. Если у вас медленный процесс или страница веб-сайта, которую вы хотите протестировать, вам следует запустить этот процесс или получить доступ к этой веб-странице прямо сейчас. Например, если вы запускаете корзину покупок, вы можете завершить процесс оформления заказа сейчас, что должно вызвать все соответствующие запросы на сервере базы данных.

Этот запрос мы будем запускать на рабочем сервере MySQL. Сначала используйте правильную базу данных:

Теперь запустите запрос:

Ожидаемый результат:

Мы отключим общее ведение журнала, когда запрос завершится:

Обратите внимание, что если вы оставите вход в систему, запросы будут продолжать добавляться в журнал, что может усложнить тестирование. Поэтому обязательно отключите журнал сразу после завершения теста. Давайте проверим, что файл журнала был создан в каталоге:

Давайте скопируем этот файл в наш тестовый каталог MySQL. Если вы используете отдельный сервер для тестирования, скопируйте его на этот сервер.

В этом файле журнала должно быть немало данных. В этом примере запрос, который мы хотим, должен быть ближе к концу. Проверьте последнюю часть файла:

Ожидаемый результат:

Этот журнал показывает команды SQL и их временные метки. SQL-оператор в конце файла - это то, что нас интересует. Она должна быть точно такой же, как команда, которую мы выполняли в производственной базе данных, поскольку именно там мы ее захватили.

В этом примере мы уже знали запрос. Но в производственной среде этот метод может быть очень полезен для поиска запросов, о которых вы не обязательно знаете, которые выполняются на вашем сервере.

Обратите внимание, что если вы запустили или запустили разные запросы во время регистрации, этот файл будет выглядеть совершенно иначе. В реальном сценарии этот файл может быть заполнен сотнями записей из разных соединений. Ваша цель - найти запрос или запросы, которые вызывают узкое место. Вы можете начать с составления списка каждой строки, содержащей текст. Тогда у вас будет список, какие именно запросы выполнялись в вашей базе данных во время теста.

Для каждого запроса, который вы хотите проверить, скопируйте его в файл, который заканчивается расширением + .sql +.

Например:

Содержимое должно быть MySQL-запросом, который вы хотите протестировать, без разрывов строк и без точки с запятой в конце:

Затем убедитесь, что результаты запроса не кэшируются. Вернитесь к вашей * тестовой сессии MySQL *. Запустите следующую команду:

Теперь пришло время запустить утилиту mysqlslap с файлом скрипта. Убедитесь, что вы используете правильное имя файла сценария в параметре. Мы будем использовать только десять одновременных подключений и повторим тест дважды. Запустите это с вашего * тестового сервера *:

Результат теста в нашей системе выглядит следующим образом:

Итак, как мы можем улучшить этот тест?

Вам понадобится определенное знакомство с запросами MySQL, чтобы оценить, что делает запрос.

Оглядываясь назад на запрос, мы видим, что он выполняет несколько объединений в нескольких таблицах. Запрос показывает историю заданий сотрудников и при этом он объединяет разные таблицы по полю. Он также использует поле для присоединения, но так как имеется всего несколько записей отдела, мы проигнорируем это. Поскольку в базе данных много записей, логично предположить, что создание индексов на поле может улучшить запрос.

Немного потренировавшись, обнаружив запросы, которые облагают налогом сервер (это та часть, с которой помогает mysqlslap!), Вы сможете оценивать запросы на основе ваших знаний MySQL и вашей базы данных.

Затем вы можете попытаться улучшить свою базу данных или запросы, которые к ней выполняются.

В нашем случае добавим индексы, которые мы упоминали выше. Мы создадим три индекса по. Один индекс будет создан для поля в таблице, другой индекс будет создан для поля в таблице, а последний будет создан для поля в таблице.

Давайте перейдем к нашему тестовому сеансу MySQL и выполним следующие команды:

Возвращаясь к нашему главному окну терминала на тестовом сервере, если мы выполним mysqlslap с теми же параметрами, мы увидим разницу в тесте:

Мы видим, что наблюдается немедленное улучшение среднего, минимального и максимального времени выполнения запроса. Вместо средних 68 секунд запрос теперь выполняется за 55 секунд. Это улучшение на 13 секунд для той же нагрузки.

Поскольку это изменение базы данных дало хороший результат в тестовой среде, теперь вы можете рассмотреть возможность его развертывания на своем производственном сервере баз данных, хотя имейте в виду, что изменения базы данных обычно имеют компромиссы в своих преимуществах и недостатках.

Вы можете повторить процесс тестирования команд и улучшений со всеми запросами, которые вы почерпнули из своего журнала.

mysqlslap - это простой и легкий инструмент, который прост в использовании и изначально интегрируется с ядром базы данных MySQL. Он доступен для всех выпусков MySQL начиная с версии 5.1.4.

В этом уроке мы увидели, как использовать mysqlslap с его различными опциями, и поигрались с образцом базы данных. Вы можете скачать другие примеры баз данных с сайта MySQL и попрактиковаться с ними тоже. Как мы уже упоминали ранее, * не запускайте тесты на сервере производственной базы данных. *

В последнем случае использования в этом руководстве использовался только один запрос. Хотя мы несколько улучшили производительность этого запроса, добавив дополнительные индексы ко всем трем таблицам, в реальной жизни этот процесс может быть не таким простым. Добавление дополнительных индексов может иногда снижать производительность системы, и администраторам баз данных часто приходится сопоставлять преимущества добавления дополнительного индекса с затратами на производительность, которые он может понести.

Сценарии тестирования в реальной жизни более сложны, но это должно дать вам инструменты для начала тестирования и повышения производительности вашей базы данных.