Высокие ожидания ввода-вывода – Как определить основную причину?

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

2 сервера практически одинаковы, единственное отличие – это RAID-контроллер и виртуальный том (HD одинаковы). На производстве имеется выделенный RAID-контроллер HW и том 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----- rb 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 

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

Мой ответ состоит из двух частей: исследование драйвера блока устройства; и оптимизация стоит посмотреть на ваш случай использования.

Исследование аппаратного обеспечения

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

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

Не зная этого инструмента, я искал его и нашел эту интересную статью о blktrace от Марка Брукера. В основном это предполагает следующее: выполнение трассировки ввода-вывода с использованием 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 на виртуальной виртуальной машине на моем занятом ноутбуке):

  ALL MIN AVG MAX N --------------- ------------- ------------- ------------- ----------- ... D2C 0.000046515 0.045781696 3.940577359 11713 ... 

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

Для получения дополнительных возможностей использовать blktrace для проведения этого исследования, прочитайте статью от Марка Брукера, очень поучительную.

Если вы хотите проверить одну общую оптимизацию

Тогда ответ от @ ludvik02 напомнил мне, что недавно появилась статья о небольшой общей оптимизации, которая может соответствовать некоторым тяжелым структурам ввода-вывода при использовании файловой системы ext * на вращающемся жестком диске. Итак, почему бы вам не попробовать попробовать вашу систему и посмотреть, как это может повлиять на вашу производительность?

В первой статье автор предложил корректировку для улучшения производительности innodb . В основном оптимизация заключалась в использовании data=journal с ext3 / 4 и дезактивации буфера двойной записи innodb. Удаление добавленной безопасности буфера двойной записи innodb было уравновешено добавленной безопасностью data=journal из файловой системы в соответствии с автором.

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

Посмотрите на обе статьи.

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