Как предсказать переломные моменты MySQL?

Question

Я работаю над большим веб-приложением, которое использует базу данных MySQL 5.0 с таблицами InnoDB. Дважды за последние пару месяцев мы сталкивались со следующим сценарием:

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

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

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

Вопрос № 1: Как мы можем прогнозировать такие переломные моменты или вообще их избегать?

Одна вещь, которую мы не делаем с какой-либо регулярностью, это запуск OPTIMIZE TABLE или ANALYZE TABLE. Нам было трудно найти хорошее эмпирическое правило о том, как часто (если вообще когда-либо) вручную делать эти вещи. (Поскольку эти команды блокируют таблицы, мы не хотим запускать их без разбора.) Звучат ли эти сценарии как результат неоптимизированных таблиц?

Вопрос № 2: Должны ли мы вручную запускать OPTIMIZE или ANALYZE? Если да, то как часто?

Подробнее о приложении: пример использования базы данных составляет около 95% операций чтения, 5% операций записи; база данных выполняет около 300 запросов в секунду; таблица, используемая в медленных запросах, была одинаковой в обоих случаях и содержит сотни тысяч записей.

Answer 1

MySQL Performance Blog - фантастический ресурс. А именно, этот пост охватывает основы правильной настройки специфичных для InnoDB параметров.

Я также обнаружил, что PDF-версия Справочного руководства MySQL очень важна. Глава 7 посвящена общей оптимизации , а - раздел 7.5 - оптимизации для конкретного сервера, с которыми вы можете играть.

Судя по звуку вашего сервера, кэш запросов может иметь для вас значение IMMENSE.

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

Может быть, стоит потратить время на репликацию с несколькими хозяевами, что позволит вам полностью заблокировать один сервер и запустить OPTIMIZE / ANALYZE, не снижая при этом производительность (поскольку 95% ваших запросов считываются, другой сервер может управлять пишет просто отлично).

Раздел 12.5.2.5 подробно описывает OPTIMIZE TABLE, а 12.5.2.1 подробно описывает ANALYZE TABLE.

Обновление для ваших правок / выделений:

Вопрос № 2 легко ответить. Из справочного руководства:

ОПТИМИЗАЦИЯ:

OPTIMIZE TABLE следует использовать, если вы удалили большую часть таблицы или если вы внесли много изменений в таблицу со строками переменной длины. [...] Вы можете использовать OPTIMIZE TABLE, чтобы освободить неиспользуемое пространство и дефрагментировать таблицу данных.

И АНАЛИЗ:

ANALYZE TABLE анализирует и сохраняет распределение ключей для таблицы. [...] MySQL использует распределение хранимых ключей, чтобы определить порядок, в котором таблицы должны объединяться, когда вы выполняете соединение с чем-то, кроме константы. Кроме того, распределение ключей может использоваться при принятии решения о том, какие индексы использовать для конкретной таблицы в запросе.

OPTIMIZE хорошо работать, когда у вас есть свободное время. MySQL хорошо оптимизирует работу с удаленными строками, но если вы идете и удаляете 20 ГБ данных из таблицы, то может быть хорошей идеей для запуска этого. Это определенно не требуется для хорошей производительности в большинстве случаев.

АНАЛИЗ гораздо важнее. Как уже отмечалось, наличие необходимых табличных данных, доступных для MySQL (предоставляемых с ANALYZE), очень важно, когда речь идет о любом запросе . Это то, что должно выполняться на общей основе.

Вопрос № 1 - немного больше трюка. Я бы очень внимательно следил за сервером, когда это происходит, а именно за дисковым вводом / выводом Держу пари, что ваш сервер перегружает ваш кеш подкачки или (InnoDB). В любом случае это может быть запрос, настройка или загрузка. Неоптимизированные таблицы могут быть причиной этого. Как уже упоминалось, запуск ANALYZE может значительно повысить производительность и, вероятно, тоже поможет.

Answer 2

Я не нашел хорошего способа предсказания «переломных моментов» MySQL, но столкнулся с некоторыми из них.

Сказав это, я обнаружил, что переломные моменты связаны с размером стола. Но не просто размер таблицы, а то, насколько велика «область интересов» для запроса. Например, в таблице, содержащей более 3 миллионов строк и около 40 столбцов, около трех четвертей целых чисел, большинство запросов, которые легко выбирают часть из них на основе индексов, выполняются быстро. Однако, когда одно значение в запросе по одному индексированному столбцу означает, что две трети строк теперь «интересны», запрос теперь примерно в 5 раз медленнее, чем обычно. Урок: попытайтесь расположить данные так, чтобы такое сканирование не требовалось.

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

Точно так же я видел, что запросы отчетов выполнялись в разумные сроки (~ 45 секунд), если период составляет две недели, но занимают полчаса, если период увеличивается до четырех недель.

Answer 3

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

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

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

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

Если есть некоторые запросы, которые «работают и перестают работать» (но «используют и индексируют»), то, скорее всего, запрос был не очень хорош в первую очередь (низкая мощность в индексе; неэффективное соединение; ..) и первое правило тщательной оценки запроса при его добавлении будет применяться.

Для вопроса № 2 - В InnoDB «таблица анализа» в основном бесплатна, поэтому, если у вас плохая производительность соединения, запускать ее не повредит. Если баланс клавиш в таблице сильно не изменится, это вряд ли поможет. Это почти всегда сводится к плохим запросам. «таблица оптимизации» перестраивает таблицу InnoDB; по моему опыту, довольно редко это помогает достаточно, чтобы стоить хлопот с тем, чтобы таблица была недоступна в течение продолжительного времени (или делала отказоустойчивый мастер-мастер во время его работы).

Answer 4

Используйте медленный журнал запросов , который поможет вам сузить запросы, которые вы хотите оптимизировать.

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