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

99% всплесков дискового ввода-вывода с Percona

Итак, у нас есть сервер, у которого, по-видимому, случаются случайные всплески дискового ввода-вывода, увеличивающиеся до 99.x% в случайное время и без очевидной причины, некоторое время оставаясь на высоком уровне, а затем снова снижаясь. Раньше это не было проблемой, но в последнее время дисковый ввод-вывод оставался на уровне 99% в течение длительных периодов времени, в некоторых случаях до 16 часов.

Сервер представляет собой выделенный сервер с 4 ядрами ЦП и 4 ГБ оперативной памяти. Он работает под управлением Ubuntu Server 14.04.2, работает percona-server 5.6 и больше ничего важного. Он отслеживается на предмет простоев, и у нас есть экран, на котором постоянно отображается CPU / RAM / Disk I / O для серверов, с которыми мы имеем дело. Сервер также регулярно обновляется и обслуживается.

Этот сервер является третьим в цепочке реплик и используется как резервная машина. Поток данных MySQL выглядит следующим образом.

Главный -> Главный / Подчиненный -> Сервер проблем

Все 3 машины имеют одинаковые характеристики и принадлежат одной компании. Проблемный сервер находится в другом центре обработки данных, чем первый и второй.

Инструмент «iotop» показывает нам, что дисковый ввод-вывод вызван процессом «jbd2 / sda7-8». Из того, что мы знаем, это обрабатывает журналирование файловой системы и сбрасывает данные на диск. Наш раздел sda7 - это / var, а раздел sda8 - / home. Ничего не следует читать / писать в / home на регулярной основе. Остановка службы mysql приводит к тому, что дисковый ввод-вывод немедленно возвращается к нормальному уровню, поэтому мы вполне уверены, что проблема связана с percona, и это будет соответствовать разделу / var, так как именно здесь наш MySQL каталог данных находится (/ var / lib / mysql).

Мы используем NewRelic для мониторинга всех наших серверов, и когда дисковый ввод-вывод резко увеличивается, мы не видим ничего, что могло бы его вызвать. Средняя нагрузка составляет ~ 2. Использование ЦП колеблется на уровне ~ 25%, что, по словам NewRelic, вызвано «ожиданием ввода-вывода», а не конкретным процессом.

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

Конфигурация MySQL - http://pastebin.com/5iev4eNa

Мы попробовали следующее, чтобы попытаться решить проблему:

Запустил mysqltuner.pl, чтобы убедиться, что что-то явно не так. Результаты выглядят очень похоже на результаты того же инструмента на других двух серверах баз данных и не сильно меняются между использованиями.
Использовал vmstat, iotop, iostat, pt-diskstats, fatrace, lsof, pt-stalk и, возможно, еще несколько, но ничего очевидного не выскочило.
Изменена переменная innodb_flush_log_at_trx_commit. Пробовали установить его на 0, 1 и 2, но, похоже, ничего не дало. Это должно было изменить то, как часто MySQL сбрасывает транзакции в файлы журналов.
Mysql 'показать полный список процессов' очень неинтересен, когда дисковый ввод-вывод высок, он просто показывает ведомое чтение от ведущего.

Некоторые выходные данные инструментов, очевидно, довольно длинные, поэтому я дам ссылки на pastebin, и мне не удалось скопировать-вставить выходные данные iotop, поэтому вместо этого я предоставил снимок экрана.

iotop

pt-diskstats: http://pastebin.com/ZYdSkCsL

Когда дисковый ввод-вывод высокий, «vmstat 2» показывает нам, что записываемые данные в основном связаны с «bo» (выход из буфера), который коррелирует с журналированием диска (сброс буферов / ОЗУ на диск)

http://pastebin.com/E3LWzwjj

«Lsof -p mysql-pid» (список открытых файлов процесса) показывает нам, что файлы, в которые выполняется запись, - это в основном файлы .MYI и .MYD в каталоге / var / lib / mysql, а также master.info и relay- bin и файлы журнала реле. Даже без указания процесса mysql (т.е. любой файл, записываемый на весь сервер), результат очень похож (в основном файлы MySQL, а не что-либо еще). Это подтверждает для меня, что это определенно вызвано Percona.

Когда дисковый ввод-вывод высокий, «seconds_behind_master» увеличивается. Я пока не уверен, в каком направлении они происходят. «Seconds_behind_master» также временно перескакивает с нормальных значений на произвольно большие значения, а затем сразу же возвращается в нормальное состояние, некоторые люди предположили, что это могло быть вызвано проблемами сети.

'показать статус ведомого' - http://pastebin.com/Wj0tFina

RAID-контроллер (3ware 8006) не имеет возможности кэширования; кто-то также предположил, что причиной проблемы может быть низкая производительность кеширования. Контроллер имеет такую же прошивку, версию, ревизию и т. Д., Что и карты на других серверах для того же клиента (хотя и веб-серверы), поэтому я совершенно уверен, что это не виноват. Я также выполнил проверки массива, который вернулся в норму. У нас также есть сценарий проверки RAID, который предупреждал бы нас о любых изменениях.

Скорость сети ужасна по сравнению со скоростью на втором сервере базы данных, поэтому я думаю, что, возможно, это проблема сети. Это также коррелирует с пиками пропускной способности непосредственно перед тем, как дисковый ввод-вывод становится высоким. Тем не менее, даже когда в сети происходит «всплеск», он не достигает большого объема трафика, а только относительно высокого по сравнению со средним значением.

Скорость сети (создается с помощью iPerf для экземпляра AWS)

Проблемный сервер - 0,0-11,3 с 2,25 МБ 1,67 Мбит / с Второй сервер - 0,0-10,0 с 438 МБ 366 Мбит / с

Помимо медленной, сеть вроде бы в порядке. Нет потери пакетов, но есть медленные переходы между серверами

Буду рад также предоставить вывод любых соответствующих команд, но я могу добавить только 2 ссылки на этот пост, поскольку я новый пользователь :(

РЕДАКТИРОВАТЬ Мы связались с нашим хостинг-провайдером по этому поводу, и они любезно поменяли жесткие диски на твердотельные накопители того же размера. Мы восстановили RAID на этих SSD, но, к сожалению, проблема не исчезла.

Лучший способ атаковать это - посмотреть на http://www.brendangregg.com/linuxperf.html и следуйте совету Брендана.

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

Какую версию сервера MySQL вы используете? После 5.5 вы можете использовать performance_schema для получения статистики в реальном времени из базы данных. Я бы начал запрашивать

 table_io_waits_summary_by_table
 table_io_waits_summary_by_table
 table_lock_waits_summary_by_table

чтобы точно увидеть, что происходит.

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