У нас есть сервер MySQL, установленный на двух разных машинах: тестовый сервер и рабочий сервер, оба окна, которые используются веб-приложением.
Проблема заключается в том, что при выполнении некоторых запросов существуют огромные различия в производительности между двумя компьютерами (рабочий сервер работает медленнее). Версия MySQL на обоих серверах одинакова, даже файлы конфигурации одинаковы (единственное отличие - путь к данным и тот факт, что рабочий сервер не регистрирует ничего, кроме ошибок). Разница в производительности, о которой я говорю, на 3 или 4 порядка больше (например, запрос на тестовом сервере выполняется за 0,2 с, тогда как на рабочем сервере выполняется за 84 с).
В оскорбительных запросах широко используются предложения с "WHERE [...] IN [...]", что, как я понимаю, обычно очень медленное и их следует заменить на JOIN. Однако используемая нами версия MySQL - 5.6.19, которая автоматически оптимизирует эти запросы, поэтому они быстро выполняются на сервере тестирования (и они находятся в той части программы, которую мы не можем изменить, поэтому мы не можем оптимизировать их вручную тем не мение).
Как я уже сказал, установка и настройка MySQL идентичны, поэтому я совершенно не понимаю, в чем проблема. С одной стороны, я подозреваю, что это должна быть какая-то проблема конфигурации, поскольку программа и БД одинаковы, с другой стороны, это не имеет смысла, так как конфигурация идентична.
Некоторые данные на серверах:
Тестирование сервера:
- Intel Core 2 Quad Q9400 с частотой 2,66 ГГц
- 8 ГБ ОЗУ
- Windows Server 2008 R2 Standard
Производственный сервер:
- Intel Xeon E5530 @ 2,40 ГГц
- 5 ГБ ОЗУ
- Windows Server 2012 R2 Standard
Редактировать: я забыл сказать одну важную вещь: выполняется больше запросов, которые используют «WHERE ... IN», кроме «оскорбительных». Они выполняются быстро на обеих машинах, что говорит о том, что они правильно оптимизируются MySQL. Тот факт, что некоторые запросы оптимизированы, а другие нет, является для меня загадкой, ЕСЛИ это настоящая проблема, в которой я не уверен.
Редактирование # 2: Вот файл конфигурации для обоих серверов: http://pastebin.ca/2834906
Правка № 3: Вот ОБЪЯСНЕНИЕ одного из медленных запросов: https://mariadb.org/ea/v36zj Объяснение EXPLAIN абсолютно одинаково как в тесте, так и в продуктах. Сам запрос находится здесь: http://pastebin.com/VXgBxXmt Он был отформатирован с помощью автоформатера, поэтому, возможно, не очень понятно. Как видите, довольно длинный и сложный. Он не генерируется вручную, они автоматически генерируются программным обеспечением, которое использует диалект стандартного SQL с некоторыми функциями.
Кроме того, дополнительная информация: мы временно исправили проблему, уменьшив данные на рабочем сервере и удалив большую часть старых данных в БД, которые не будут использоваться. Конечно, это не решение, поскольку нам нужны также старые данные, и это будет проблемой в будущем. БД не такая большая: полная БД составляет 1308 МБ, сокращенная версия, которая в настоящее время находится в производстве, составляет 332 МБ.
ОБНОВЛЕНИЕ: решено ??
Я думаю, что я решил проблему. Я еще не тестировал его, поскольку рабочий сервер фактически используется, но возможной проблемой был параметр "innodb_buffer_pool_size", который был установлен равным 182M. На самом деле, строка в файле конфигурации показывает: innodb_buffer_pool_size = 321, что является ошибкой, так как не имеет префикса unit, давая недопустимое значение (минимум 5242880 в соответствии с документами), затем помещая его в предыдущее значение , Это значение на тестовом сервере было установлено равным 321M.
Как я уже сказал, я не проверял это полностью. Что я сделал, так это уменьшил ценность тестирования и попробовал приложение. Все идет медленнее, и определенный запрос, который я разместил, выполняется за 3 минуты.
Я протестировал более разумное значение 3Gb, которое я не знаю, если это хорошая идея, поэтому, если у кого-то есть комментарии по поводу этого значения, я буду признателен.
Мои выводы, «вменяемая ценность» 3Gb и информация, которую я использовал для этого, получены из этих двух постов, особенно второго:
MySQL запрос, 2 одинаковых сервера, 2-минутная разница во времени выполнения
Насколько большим должен быть mysql innodb_buffer_pool_size?
Я опубликую «реальные» результаты, когда мы обновим значения на рабочем сервере.
Спасибо всем.
РЕШИТЬ
Итак, мы наконец проверили это в prod, и это была проблема, которую я прокомментировал ранее. Я поместил значение innodb_buffer_pool_size в 321M, что является значением, рекомендованным поставщиком SDK, который мы используем, хотя в соответствии с предыдущими ссылками оно должно быть около 3G для БД такого размера и использования.
У меня все еще есть сомнения: значение 321 было недопустимым (слишком маленьким), поэтому MySQL принял другое значение. Я подозреваю, что для этого потребовалось предыдущее действительное число, 321M в тесте и 182M в prod, отсюда и разница в скорости. Это просто из любопытства, но я хотел бы знать, правильно ли это.
Еще раз всем спасибо за помощь.