Назад | Перейти на главную страницу

Проблемы с производительностью MySQL после обновления оборудования и перехода на виртуальную машину

Недавно мы запустили некоторые обновления (безопасности) на наших серверах и перезагрузили машины. Наш сервер разработки больше не подключался к сети из-за проблемы с графическим процессором (встроенным в CPU). Мы заменили (и модернизировали) оборудование на этой машине, а также преобразовали изначально чистую машину в виртуальную машину (KVM), чтобы мы могли обновить ее с CentOS5 -> CentOS6 позже.

Однако сама машина НЕ была переустановлена, все данные были защищены и скопированы 1: 1 в качестве нового образа, который (новая) виртуальная машина могла использовать для загрузки.

Проблема, с которой мы столкнулись, - это производительность MySQL. Похоже, это в основном связано с действительно простыми операторами CREATE TABLE. Мы не можем определить, связана ли эта проблема с обновлением MySQL до версии 5.5.50 или переходом на виртуальную машину.

Эта проблема:

mysql-slow-querylog

# Time: 160610 13:55:50
# User@Host: unittest[unittest] @ localhost [127.0.0.1]
# Query_time: 7.954247  Lock_time: 0.000049 Rows_sent: 0  Rows_examined: 0
use unittest_api_575aaabd9e502;
SET timestamp=1465559750;
-- --------------------------------------------------------

--
-- Table structure for table `customer`
--

CREATE TABLE IF NOT EXISTS `customer` (
  `customer_id` int(11) unsigned NOT NULL AUTO_INCREMENT,
  `name` varchar(255) NOT NULL,
  `crm_id` varchar(255) DEFAULT NULL,
  PRIMARY KEY (`customer_id`)
) ENGINE=InnoDB  DEFAULT CHARSET=latin1 AUTO_INCREMENT=25 ;

(наш набор unittest создает структуру БД, и это таблица, которая создается)

Вы заметите, что создание этой таблицы заняло почти 8 секунд! (Наш тестовый пакет теперь занимает 2 минуты вместо 30 секунд)

Я также выполнил этот запрос с профилированием:

DROP TABLE IF EXISTS `customer`;

set profiling =1;

CREATE TABLE IF NOT EXISTS `customer` (
    `customer_id` int(11) unsigned NOT NULL AUTO_INCREMENT,
    `name` varchar(255) NOT NULL,
    `crm_id` varchar(255) DEFAULT NULL,
    PRIMARY KEY (`customer_id`)
) ENGINE=InnoDB  DEFAULT CHARSET=latin1 AUTO_INCREMENT=25;

set profiling =0;

show profile all for query 1;

И вот результат: Результаты различаются, но я вижу много высоких (> 1 секунды) значений), на мой взгляд, это никогда не должно занимать больше одной секунды на сервере с небольшой нагрузкой.

Я попытался внести некоторые изменения в my.conf, но мне пока не удалось повысить производительность. Я загрузил наши my.cnf для справки.

Некоторые подробности о сервере:

Хост:

ВМ:

Не могу поверить, что это только с голого металла => ВМ. Может ли кто-нибудь указать нам правильное направление? Если потребуется дополнительная информация, дайте мне знать.

Дополнительная информация:

Вы не указали тип кэша виртуального диска, поэтому libvirt предполагает наиболее безопасную схему кеширования: directsync, что означает, что все записи немедленно синхронизируются с физическим диском.

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

Сделайте следующее:

  • выключи свою машину
  • открыть его конфигурацию через virt-manager
  • Выбрать virtio disk 1 и на правой панели щелкните advanced, затем performance options
  • установить тип кеша на writeback
  • наконец, перезапустите виртуальную машину.

Теперь виртуальная машина должна быть намного быстрее. Однако, поскольку вы используете довольно старую ОС (CentOS 5.x), убедитесь, что в гостевой ОС включены барьеры записи. Для этого вы должны смонтировать гостевую файловую систему с barrier=1 опция монтирования (например: передача через /etc/fstab).

Для получения дополнительной информации о кешировании и барьерах, взгляни сюда