База знаний

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

iostat -x -t -o JSON 10 60 > "iostat-1.json"

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

Во 2м раунде выключите "боевую" нагрузку и включите измерения:

iostat -x -t -o JSON 10 60 > "iostat-2.json"

и несколько раз в течении 10 минут работы iostat включите тестовую нагрузку с помощью fio на 1-2 минуты:

fio --rate_iops=700,300, --bs=4k --rw=randrw --percentage_random=50 --rwmixread=70 --rwmixwrite=30 --direct=1 --iodepth=256 --time_based --group_reporting --name=iops-test-job --numjobs=1 --filename=runfio.sh.test --size=1GB --ioengine=libaio --runtime=60 --eta-newline=10

Параметр --rate_iops=700,300, указывается в формате --rate_iops=[read],[write],[trim] и означает "дать нагрузку 700 iops на чтение, 300 - на запись, значение trim оставить по умолчанию". Числа выбираются исходя из указанного в Cloud Director'е общего лимита iops на конкретный диск и распределения нагрузки 70% на чтение / 30% на запись. В случае тестового стенда общий лимит равен 1000 iops, поэтому нагрузка распределяется как 700/300.

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

Оба теста подтверждают работоспособность диска на 1000 IO-операций, но в 1м случае, без --rate_iops=W,R, в замерах мы получим throttling latency, а во 2м - реальные значения.

Для проверки latency можно использовать отдельную утилиту ioping:

# установка
$ sudo apt-get install ioping

# проверка
$ ioping -c 9 /tmp/
4 KiB <<< /tmp/ (ext4 /dev/sda5): request=1 time=309.1 us (warmup)
4 KiB <<< /tmp/ (ext4 /dev/sda5): request=2 time=717.3 us
4 KiB <<< /tmp/ (ext4 /dev/sda5): request=3 time=583.4 us
4 KiB <<< /tmp/ (ext4 /dev/sda5): request=4 time=430.2 us
4 KiB <<< /tmp/ (ext4 /dev/sda5): request=5 time=405.8 us
4 KiB <<< /tmp/ (ext4 /dev/sda5): request=6 time=387.4 us
4 KiB <<< /tmp/ (ext4 /dev/sda5): request=7 time=382.1 us (fast)
4 KiB <<< /tmp/ (ext4 /dev/sda5): request=8 time=811.6 us (slow)
4 KiB <<< /tmp/ (ext4 /dev/sda5): request=9 time=706.9 us

--- /tmp/ (ext4 /dev/sda5) ioping statistics ---
8 requests completed in 4.42 ms, 32 KiB read, 1.81 k iops, 7.06 MiB/s
generated 9 requests in 8.00 s, 36 KiB, 1 iops, 4.50 KiB/s
min/avg/max/mdev = 382.1 us / 553.1 us / 811.6 us / 162.7 us

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

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

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