У нас есть сервер 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, отсюда и разница в скорости. Это просто из любопытства, но я хотел бы знать, правильно ли это.

Еще раз всем спасибо за помощь.

Я мог бы летать вслепую на этом, но здесь это идет ...

В своем вопросе и комментариях вы указали следующее:

Версия MySQL на обоих серверах одинакова, даже файлы конфигурации одинаковы (единственное отличие - путь к данным и тот факт, что рабочий сервер не регистрирует ничего, кроме ошибок)

Да, БД одинаковы (на самом деле дамп рабочей БД в тестовую БД).

Аналогичные результаты: 2.31Gb стабильно

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

Есть несколько вещей, которые могут отличаться

ВАШ ПРОЦЕССОР

Я посмотрел на Intel Core 2 Quad Q9400 @ 2.66 ГГц (TEST) и Intel Xeon E5530 @ 2.40 ГГц (PROD) и обнаружил разницу.

• CPU для TEST имеет 4 потока
• CPU для PROD имеет 8 потоков

Вы думаете, что PROD должен быть быстрее.

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

Внутренняя частота микропроцессоров обычно основана на частоте передней боковой шины. Для расчета внутренней частоты ЦПУ умножает частоту шины на определенное число, которое называется умножителем тактовой частоты. Важно отметить, что для расчета процессор использует фактическую частоту шины, а не эффективную частоту шины. Чтобы определить фактическую фактическую частоту шины для процессоров, которые используют шины с двойной скоростью передачи данных (AMD Athlon и Duron) и шины с четырьмя скоростями передачи данных (все микропроцессоры Intel, начиная с Pentium 4), эффективную скорость шины следует разделить на 2 для AMD или 4 для Intel.

Исходя из этого, внутренняя скорость шины для AMD (TEST) как минимум в 2 раза больше, чем для Intel (PROD).

ВАША ИНДЕКСНАЯ СТАТИСТИКА

Поскольку вы загрузили TEST с теми же данными, одна вещь могла быть упущена. Я думаю о статистике индекса. Для TEST статистика индекса будет довольно новой. Для PROD это может быть устаревшим, если в индексированных таблицах было много INSERT, UPDATE и DELETE.

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

Я запускаю ANALYZE TABLE для всех таблиц PROD и TEST, а затем пытаюсь сравнить производительность.