MySQL 5.1 против MySQL 5.5 (в 5,1 раза быстрее)

Я недавно установил MySQL 5.1 на CentOS 6.2 и получил прирост производительности по сравнению с MySQL 4.1, который мы используем. Поэтому я обновляю MySQL 5.1 до MySQL 5.5, чтобы увидеть, был ли еще выигрыш, но на самом деле он работал вдвое медленнее, чем установка MySQL 5.1.

Тест, который я провел, был на столе с 2.3M записями с примечаниями блоба.

5,1: 57,5899 с

5,5: 96,3821 с

Что действительно интересно, если я вытащу 100000 записей, то 5,5 бьет 5,1, но после этого все, что в результате получается нагрузкой 5,5, как в пиках; ускоряется и замедляется по мере загрузки, отсюда и дополнительные секунды.

Есть мысли, почему это так? Тот же my.cnf для 5.1 и 5.5

[mysqld]
datadir=/var/lib/mysql
socket=/var/lib/mysql/mysql.sock
user=mysql
# Disabling symbolic-links is recommended to prevent assorted security risks
symbolic-links=0
bind-address = xxx.xxx.xxx.xxx

#This option makes InnoDB to store each created table into its own .ibd file.
innodb_file_per_table=1
max_allowed_packet=900M

[mysqld_safe]
log-error=/var/log/mysqld.log
pid-file=/var/run/mysqld/mysqld.pid

2 ответа

Решение

В некоторых случаях MySQL 5.1 может превзойти MySQL 5.5 при определенных обстоятельствах.

Percona провела конкурс среди множества выпусков MySQL

  • MySQL 4.1
  • MySQL 5.0
  • MySQL 5.1 (со встроенным InnoDB)
  • MySQL 5.1 с плагином InnoDB
  • MySQL 5.5
  • MySQL 5.6

Все тесты были выполнены с ненастроенным MySQL (Другими словами, my.cnf не был сделан). Результаты, достижения?

  • MySQL 4.1 работает лучше всего с однопоточным InnoDB
  • MySQL 5.1 с подключаемым модулем InnoDB масштабируется на несколько ядер лучше, чем встроенный InnoDB 5.1, 5.5 и 5.6

Если вы хотите, чтобы более новые версии MySQL работали лучше, вы должны настроить его. Фактически, я описал в DBA StackExchange идею выполнения MySQL Bakeoff.

Что я имею в виду мелодию для этого?

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

Подумайте о следующем:

  • Мусор на входе, мусор на выходе
  • Ты получаешь то, за что платишь
  • Два слова: должная осмотрительность

Итог: MySQL 5.5 и Percona Server должны быть настроены для желаемых улучшений производительности.

Имейте это в виду

Что такое Ламборджини?

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

Я бы предложил использовать инструмент pt-stalk из Percona Toolkit для сбора набора диагностических данных с сервера, когда происходит один из всплесков медлительности, и то же самое, когда он работает быстрее. Там почти наверняка должно быть достаточно информации, чтобы понять, что происходит. Если вам неудобно ставить диагноз, у любого компетентного поставщика поддержки MySQL не должно возникнуть проблем, если вы скачаете образцы из pt-stalk и отправите их заново.

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

Другие вопросы по тегам