У меня есть экземпляр MySQL на двух выделенных серверах. Один для производства, другой для тестовой платформы.

2 сервера практически одинаковы, единственное отличие - контроллер RAID и виртуальный том (HD одинаковы). На производстве есть выделенный контроллер HW RAID и том RAID 10. С другой стороны, контроллер RAID выглядит как программный (Lenovo ThinkServer RAID 110i), а объем - RAID 5.

Мы заметили, что во время коммитов MySQL у нас высокий iowait:

while true; do date; ps auxf | awk '{if($8=="D") print $0;}'; sleep 1; done
root     26661  0.0  0.0      0     0 ?        D    Jun09   5:41  \_ [jbd2/dm-14-8]
root     26691  0.0  0.0      0     0 ?        D    Jun09   0:57  \_ [jbd2/dm-10-8]
Thu Jun 18 13:49:37 CEST 2015
root     26691  0.0  0.0      0     0 ?        D    Jun09   0:57  \_ [jbd2/dm-10-8]
Thu Jun 18 13:49:38 CEST 2015
root      1474  0.0  0.0      0     0 ?        D    Jun04   0:23  \_ [jbd2/dm-5-8]
root     26691  0.0  0.0      0     0 ?        D    Jun09   0:57  \_ [jbd2/dm-10-8]
Thu Jun 18 13:49:39 CEST 2015
Thu Jun 18 13:49:40 CEST 2015
root      1474  0.0  0.0      0     0 ?        D    Jun04   0:23  \_ [jbd2/dm-5-8]
root      1478  0.0  0.0      0     0 ?        D    Jun04   0:03  \_ [jbd2/dm-7-8]
root     26661  0.0  0.0      0     0 ?        D    Jun09   5:41  \_ [jbd2/dm-14-8]

DM-10-8 и DM-14-8 связаны с разделами базы данных.

procs -----------memory---------- ---swap-- -----io---- --system-- -----cpu-----
 r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa st
 1  3 240904 809656 572624 7114416    0    0    59  1681 2002 5141  3  1 67 30  0
 0  4 240880 809656 572632 7114604    0    0   139  2069 2090 4985  3  1 67 29  0
 1  2 240880 809284 572636 7114676    0    0    27  2159 2253 4247  2  1 72 25  0
 5  2 240880 809408 572656 7114820    0    0    27  2404 2254 5350  3  1 69 27  0

Я подозреваю, что контроллер рейда, как я могу быть уверен?

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

Исследование оборудования

Я понял, что для одного и того же приложения, но на двух разных наборах аппаратных средств, производительность сильно отличается, и вы хотели бы понять, почему. Поэтому я предлагаю сначала средство, чтобы помочь вам найти ответ на вопрос «почему».

Что касается производительности, я часто обращаюсь к карте производительности Linux, предоставленной Бренданом Греггом в своем блоге. Видно, что для низкого уровня (ближайшего к аппаратному обеспечению) подобный инструмент blktraceбыл бы идеальным.

Не зная этого инструмента, я искал вокруг и нашел эту интересную статью о blktrace от Marc Brooker. В основном это предполагает следующее: выполнение трассировки ввода / вывода с использованием blktrace; используя инструмент btt для извлечения информации из этой трассировки. Это было бы что-то вроде этого (для 30-секундной трассировки):

# blktrace -w 30 -d /dev/dm-10-8 -o dm-10-8
# blkparse -d blkmerged.out dm-10-8*
# btt -i blkmerged.out | less

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

Пример вывода ( dnf upgradeработает на виртуальной машине VirtualBox на моем занятом ноутбуке):

            ALL           MIN           AVG           MAX           N
--------------- ------------- ------------- ------------- -----------

...
D2C               0.000046515   0.045781696   3.940577359       11713
...

Он показывает разочаровывающее среднее значение 45 мс на ввод / вывод с 3,94 с в худшем случае !!

Чтобы узнать больше о том, как использовать blktrace для расследования, прочитайте статью Марка Брукера, очень поучительную.

Процесс jbd2 предназначен для журналирования ext4. Логично, что файловая система должна записывать в журнал во время коммитов mysql, это не должно быть поводом для каких-либо забот. На величину нагрузки, вызванной jbd, влияют параметры монтирования для разделов dm-10-8 и dm-14-8. Вероятно, желательно иметь очень осторожное ведение журнала в разделе базы данных, чтобы гарантировать, что ваша база данных не будет повреждена, если что-то произойдет, и ваш сервер случайно перезагрузится. Вы можете выбрать другие параметры монтирования журналирования в тестовой среде только для сравнения.