MySQL высокая активность диска даже при отсутствии запущенных запросов - PullRequest
Новая
       22

MySQL высокая активность диска даже при отсутствии запущенных запросов

0 голосов
/ 28 мая 2020

Попытка устранить проблему с таинственным узким местом io диска, вызванным MySQL.

Я использую следующие команды для проверки скорости чтения / записи диска: 

#write
dd if=/dev/zero of=/tmp/writetest bs=1M count=1024 conv=fdatasync,notrunc

#read
echo 3 > /proc/sys/vm/drop_caches; dd if=/tmp/writetest of=/dev/null bs=1M count=1024

Я перезагрузил компьютер, отключил cron, чтобы ни один из моих обычных процессов не выполнял запросы, убил веб-сервер, который обычно работает, и убил mysqld.

Когда я запускаю тест чтения без запущенного mysqld, я получаю 1073741824 bytes (1.1 GB) copied, 2.19439 s, 489 MB/s. Постоянно около 450-500 МБ / с.

Когда я запускаю резервную копию службы mysql, а затем снова запускаю тест чтения, я получаю 1073741824 bytes (1.1 GB) copied, 135.657 s, 7.9 MB/s. Постоянно около 5 МБ / с.

Запуск show full processlist в mysql не показывает никаких запросов (и я все равно отключил все, что выполняло бы запросы). На вкладке состояния сервера MySQLWorkbench я вижу, что чтение InnoDB колеблется от 30 до 200 операций чтения в секунду и от 3 до 15 операций записи в секунду, даже если запросы не выполняются. mysqld набирает скорость чтения с диска 1 МБ в секунду, когда запросы не выполняются. Это кажется большим, учитывая, что запросы не выполняются, но в то же время этого недостаточно, чтобы моя команда dd занимала так много времени ... Единственное, что выполняет disk io, - это jbd2/sda3-8.

Не уверен, связано ли это, но если я попытаюсь убить сервер mysql с помощью service mysql stop, он скажет: «Попытка остановить MySQL истекло время», и процесс mysqld продолжит работу, но я не могу дольше подключаться к БД. Я должен использовать kill -9, чтобы убить процесс mysqld и перезапустить сервер.

Все это кажется неожиданным. Этот сервер месяцами выполнял тяжелый анализ журналов, вставки и выборки большого объема, пока в прошлые выходные мы не увидели узкое место io диска.

Как я могу узнать, почему MySQL так много читает с диска когда по сути простаивает?

Ответы [ 2 ]

1 голос
/ 30 мая 2020

Вы обновляли / удаляли / вставляли большое количество строк? Если это так, примите во внимание эти «задержки» при записи на диск:

  • Блок, содержащий данные, не записывается обратно на диск немедленно.
  • То же самое для UNIQUE ключей.
  • Обновления вторичных индексов go в «буфер изменений» Они складываются в блоки индекса, часто даже позже.
  • Обновления / удаления оставляют «список истории», который необходимо очистить после завершения транзакции.

Эти вещи обрабатываются фоновыми задачами, которые не отображаются в PROCESSLIST. Они могут быть видны в процессе (ах) mysqld, в основном как операции ввода-вывода. (ЦП, наверное, минимальный.)

Был ли ROLLBACK? Транзакции - это «optimisti c». Таким образом, ROLLBACK должен проделать большую работу, чтобы «отменить» то, что оптимистично уже было зафиксировано.

Если вы резко завершите работу mysqld (или выключите питание), то ROLLBACK произойдет после перезапуска.

SSD не имеют времени «поиска». Жесткие диски должны перемещать головки чтения / записи на переменную величину; это требует времени. Если ваш dd работает на одном конце диска, а mysqld работает на другом конце, «поиск» добавляет к кажущемуся времени ввода-вывода.

0 голосов
/ 10 июня 2020

Это оказалось, как и многие проблемы с производительностью, многогранной проблемой.

По сути, проблема оказалась в ночной системе и резервных копиях БД, записываемых в отдельный RAID-массив HDD, работающем на следующий день, затем мастер отправляет FLU SH TABLES и заставляет mysql задания и репликацию ждать этого. Кроме того, это ненужный побочный процесс, копирующий по системе несколько гигабайт текстовых файлов несколько раз в день. Тонны переключения контекста, поскольку система пыталась скопировать данные для резервного копирования, одновременно выполняя mysql работу (репликация и другие задания).

В итоге я уменьшил количество таблиц, которые мы реплицировали (некоторые из них были ненужными) , уменьшая копирование текстовых файлов по системе, когда они не нужны, увеличивая память и io, выделенные для сервера mysql, оптимизируя резервное копирование mysql и резервное копирование системы, а также ограничивая задания cron, выполняющие процессы mysql, чтобы дать mysql резервные копии больше времени для завершения. При всем этом резервное копирование едва ли завершалось к 7 утра каждое утро, поэтому я решил, что нам нужно запускать резервное копирование mysql только по выходным, а не по ночам, что нормально, поскольку все это достаточно статистические данные c.

...