Анализ и диагностика производительности дисковой подсистемы

В статье мы рассмотрим один из случаев, с которым наши клиенты обращаются в техническую поддержку. Суть в следующем: на сервере крутится специфическое ПО, например, для обсчёта кубов данных, которое интенсивно работает с БД. В какой-то момент производительность ПО заметно снижается, под подозрение попадает дисковая подсистема сервера и клиент обращается в техподдержку Cloud4Y для соответствующей диагностики.

Проверка начинается с нашей - провайдера - стороны: инженеры анализируют общую нагрузку, в т.ч. на СХД и утилизацию указанной в тикете ВМ выделенных ей ресурсов. Когда становится понятно, что "снаружи" проблем нет - переходят к диагностике "изнутри" ВМ. Вот об этом далее и пойдёт речь.

Логика метода достаточно простая: провести пару раундов замеров, 1й под реальной рабочей нагрузкой, 2й - с и без тестовой нагрузки. Это позволит, во-первых, получить контрольные показатели iops при максимальной загрузке дисковой подсистемы тестами и на холостом ходе. А во-вторых, сравнить их с полученными рабочими метриками при реальной нагрузке.

С целью демонстрации метода диагностики был развёрнут тестовый стенд в виде виртуальной машины на базе Ubuntu 20.04 x64, 2 ядра CPU, 4 ГБ памяти, диск 30 ГБ с профилем vcd-type-med - ограничение в 1000 iops.


Стандартом индустрии для проверки iops в *nix системах является утилита iostat из пакета SYSSTAT, а нагрузочное тестирование выполняется с помощью утилиты fio - их необходимо установить:

sudo apt update
sudo apt install sysstat
sudo apt install fio

После установки проведите 1й раунд замеров при реальной нагрузке:

iostat -x -t -o JSON 10 30 > "iostat-<date_time>.json"

Параметры iostat означают провести 30 замеров с интервалом 10 секунд, вывод в json-формате направить в файл iostat-<date_time>.json. Количество и интервалы вы можете выставить на свое усмотрение - в одном реальном случае мы снимали замеры на протяжении суток с почасовой разбивкой. Что касается json-формата, то его намного проще обработать в дальнейшем программно, чем парсить псевдотабличный вывод утилиты regexp'ами, но его поддержка есть только в достаточно свежих версиях - 12.x - и если у вас очень старая гостевая ОС, напр., Ubuntu 16.04 или ниже, вероятнее всего придётся собрать пакет из исходников.

Во 2м раунде выключите "боевую" нагрузку и несколько раз прогоните цикл "холостая работа диска - работа под нагрузкой fio":

iostat -x -t -o JSON 10 30 > "iostat-<date_time>.json"
fio --filename=fio.test --size=1GB --direct=1 --rw=randrw --bs=4k --ioengine=libaio --iodepth=256 --runtime=560 --numjobs=4 --time_based --group_reporting --name=iops-test-job --eta-newline=1

Дополнительно советуем зафиксировать скриншотами показания top / htop, особенно для 1го раунда. Информация о LA - Load Average - может помочь при поиске возможных причин снижения производительности ПО. Также, для сложных случаев с несколькими дисками и LVM, командой lsblk -f можно наглядно посмотреть структуру своей дисковой подсистемы.

Готовые json-файлы замеров мы обработали - визуализировали - на Python в JupyterLab при помощи библиотек pandas и matplotlib. Вы можете воспользоваться нашим "велосипедом", либо написать свой - для вас мы подготовили архив с исходниками и примером обработки замеров в виде - ipynb - jupiter-блокнота и его html-версии.

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

Пример графиков тестового стенда. Тестовая нагрузка на графиках выглядит как два "верблюжьих горба" - по 500 iops на чтение и на запись. Графиков рабочей нагрузки по понятным причинам нет.

А ниже графики из реального случая диагностики по тикету клиента. Останавливать рабочий процесс, чтобы включить тестовую нагрузку, не понадобилось: на графиках хорошо видны пики в 40 iops на запись и 200 iops на чтение. Т.е. первоначальный диагноз вендора ПО - "не вывозит дисковая подсистема" - не нашёл подтверждения, диски практически не утилизированы, в редкие моменты действительно готовы "вывезти", а низкая производительность обусловлена совсем другой причиной.


Помните, выше мы советовали вам обратить внимание на показатель Load Average и сделать скриншоты утилиты top или htop?! Смысл этого показателя, в пересчёте на одно процессорное ядро, следующий:

  • la < 1 - у системы ещё есть свободные вычислительные ресурсы, очереди процессов на выполнение нет
  • la = 1 - ресурсов уже нет, очереди пока ещё нет
  • la > 1 - появилась очередь, в которой процессы ожидают освобождения ресурсов ЦПУ для своего исполнения

Хорошей практикой считается держать этот показатель в районе 0.7 - 0.8: с одной стороны ещё есть запас свободных ресурсов, с другой стороны - достаточно хорошая утилизация ЦПУ. В данном случае la = 80 / 32 = 2.5. Именно это и было причиной низкой производительности ПО: длина очереди ожидающих своего исполнения процессов в 1.5 раза превышала ту, что уже исполнялась на ЦПУ -> загрузка составила 250% -> ПО "тормозило".

  • iops, Python, JupiterLab, MatPlotLib, Pandas, SYSSTAT, FIO
  • 0 Пользователи нашли это полезным
Помог ли вам данный ответ?

Связанные статьи

Диагностика проблем со скоростью Интернет

Периодически у пользователей встречаются проблемы, когда скорость загрузки с какого-либо...

Как открыть тикет в техническую поддержку?

Создание тикетов является основным способом обращения в техническую поддержку Cloud4Y. Несмотря...

Базовый вопросник по производительности при подаче заявки в тикет-систему

Базовые вопросы и проблемы с производительностью. В случае, если вы замечаете какие-то проблемы...

Расширенный вопросник по производительности при подаче заявки в тикет-систему

Расширенные вопросы и проблемы с производительностью. В случае, если вы замечаете какие-то...

Cloud4Y RDP Connect to Terminal Mini-HowTo

Как подключится к рабочему терминальному серверу Компании Для работы в корпоративных системах...