Итак, у нас есть сервер, который, по-видимому, имеет случайные пики дискового ввода-вывода, достигающие 99.x% в случайные моменты времени и без какой-либо очевидной причины, оставаясь высоким некоторое время, а затем снова падая. Раньше это не было проблемой, но в последнее время дисковый ввод-вывод оставался на уровне 99% в течение длительных периодов времени, в некоторых случаях до 16 часов.
Сервер — это выделенный сервер с 4 ядрами ЦП и 4 ГБ ОЗУ. Он работает под управлением Ubuntu Server 14.04.2, percona-server 5.6 и больше ничего серьезного. Он отслеживается на предмет простоя, и у нас есть экран, постоянно показывающий ЦП/ОЗУ/дисковый ввод-вывод для серверов, с которыми мы работаем. Сервер также регулярно обновляется и обслуживается.
Этот сервер является третьим в цепочке реплик и используется в качестве отказоустойчивой машины. Поток данных 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 «show full processlist» совершенно неинтересна при высоком уровне дискового ввода-вывода, она просто показывает, что подчиненный узел считывает данные с главного.
Некоторые выходные данные инструментов, очевидно, довольно длинные, поэтому я дам ссылки на pastebin, а скопировать-вставить выходные данные iotop мне не удалось, поэтому вместо этого я предоставил снимок экрана.
иотоп
pt-diskstats:http://pastebin.com/ZYdSkCsL
Когда объем ввода-вывода на диске высок, «vmstat 2» показывает нам, что записываемые данные в основном происходят из-за «bo» (buffer out), что коррелирует с журналированием диска (сбросом буферов/ОЗУ на диск).
«lsof -p mysql-pid» (список открытых файлов процесса) показывает нам, что файлы, в которые ведется запись, в основном являются файлами .MYI и .MYD в каталоге /var/lib/mysql, а также файлами master.info, relay-bin и relay-log. Даже без указания процесса 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 ссылки к этому посту, поскольку я новый пользователь :(
РЕДАКТИРОВАТЬМы связались с нашим хостинг-провайдером по поводу этой проблемы, и они были настолько любезны, что заменили жесткие диски на SSD того же размера. Мы перестроили RAID на эти SSD, но, к сожалению, проблема осталась.
решение1
Какую версию сервера MySQL вы используете? После 5.5 вы можете использовать performance_schema для получения статистики в реальном времени из базы данных. Я бы начал запрашивать
table_io_waits_summary_by_table
table_io_waits_summary_by_table
table_lock_waits_summary_by_table
чтобы увидеть, что именно происходит.
Другим решением было бы проверить использование пула буферов. Возможно, есть холодные страницы, которые необходимо переместить в память?
решение2
Лучший способ атаковать его — это посмотреть наhttp://www.brendangregg.com/linuxperf.htmlи следуйте совету Брендана.
В частности, вам нужен его инструмент iosnoop, который скажет вам, кто чаще всего получает доступ к хранилищу. Но вы окажете себе большую услугу, если прочтете его, чтобы узнать его мыслительный процесс и методологии, поскольку это принесет вам большую пользу в долгосрочной перспективе.