Нагрузка на диски в Linux

Для измерения текущей нагрузки на диски (что происходит, кто куда копирует и прочее) в Linux можно использовать iotop (и здесь же lsof) и iostat. А для тестирования возможностей дисковой системы fio. Несмотря на то, что первое, о чем можно подумать в плане попугаев — это IOPS или же Мб/сек за чтение или запись, обратите внимание на время ожидания. Примерно как если бы вы стояли в очереди в кассу: вас обслужили бы за 2 минуты, но очередь может быть минут на 30. И со стороны наблюдателя ваш процесс обслуживания будет «висеть». Именно так могут ощущать себя клиенты сервера, если время ожидания будет намного превышать время выполнения конкретной задачи. Поэтому определение длинной очереди и задержек часто бывает более важным, чем знать, что ваш диск «вау, может писать 400 Мбит/с». Нагрузка на диск может оказаться в 4000 Мбит/с в течение длительных периодов времени и все это время клиенты сервера будут недовольны.

Я здесь пишу свой опыт, со своим видением и трактовкой. Пожалуйста, учитывайте это.

IOTOP

Посмотреть, какие процессы в настоящее время создают нагрузку на диск удобно смотреть командой iotop:

Здесь видно, что в данный момент mc что-то пишет (а в это время в другом окне я в самом деле копировал кучу файлов на usb-диск в Midnight Commander (он же mc).

Понять, что коипрует mc в данный момент можно узнать командой:

IOSTAT

Пример вывода iostat на незагруженной в данный момент старенькой системе из двух SATA HDD в soft raid 1 (зеркало) mdadm:

Команда выглядела так:

-x — расширенная статистика

-t — выводить время для каждой порции замеров

-m — результаты в Мбайт

5 — интервал замеров 5 секунд.

Если нужны не история, а динамика процесса, попробуйте так:

watch iostat -x -t -m 1 2

В этом выводе r/s и w/s это отправленные к устройству запросы на выполнение (IOPS, которые хотелось бы, чтобы устройство выполнило).

await — время, включающее ожидание выполнения запроса (как если бы вы встали в очередь в кассу и ждали бы, пока вас обслужат).

svctm — время, реально затраченное на выполнение запроса (время «на самой кассе»).

Для обычных SATA дисков нагрузка IOPS где-то до 100-130 вполне выполнимая. В момент проведения замеров запрошенная нагрузка была 40 IOPS, поэтому запрос практически в очереди и не стоял, его обслужили почти сразу (на «кассе» никого не было). Поэтому await практически равен svctm.

Другое дело, когда нагрузка на диск вырастает:

%iowait — простой процессора (время в процентах) от или процессоров, в то время пока обрабатывались запросы. Т.е. в среднем процессор отдыхал почти 50% времени.

%user — загруженность процессора пользовательскими приложениями. По этому параметру видно, например, что в данный период процессор был почти не занят. Это важно, т.к. может помочь отсечь подозрения в тормозах из-за процессора.

Замер сделан во время переноса большого количества писем из одной папки IMAP в другую. Особо обратите внимание на await и svctm. Налицо длинная очередь (отношение await к svctm). Дисковая система (или чипсет, или медленный контроллер SATA, или. ) не справляется с запрошенной нагрузкой (w/s).. Для пользователей в этот момент все выглядело просто — сервер тупит или даже завис.

Заранее проверить производительность дисков можно с помощью fio. Также можно примерно оценить на одной машине производительность дисков и понимать, какой уровень «в среднем по больнице» вы можете ожидать. Это, конечно же, не правильно, но оценить все же поможет. Глубже анализировать результаты, а, главное, методики тестов мне пока трудно.

# yum install fio

# apt-get install fio

В общем виде запуск выглядит так:

Файл your.cfg (название произвольное) может быть примерно таким (пример рабочего конфига для теста на чтение):

Буферизацию не используем (buffered=0), чтение не последовательное (rw=randread).

Во время выполнения этого теста (а выполняться тест может доооолго, надоест — Ctrl+C, результаты все равно будут) можно запустить iostat и посмотреть, что происходит:

Обратите внимание на отношение await к svctm: await/svctm = 32,11..11, т.е. можно считать 32. Это и есть iodepth из конфига your.cfg. Теперь проще понять смысл iodepth — мы указываем, насколько хотим в тесте имитировать длинную очередь заданий.

Я не стал ждать два дня, Ctrl+C и вот результат:

Получили 109 iops, что в принципе нормально, диск обычный, SATA.

Источник

Linux мониторинг дисковой подсистемы

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

Мониторинг дисков Linux сервера

Чаще всего применяются консольные утилиты vmstat, top, iotop, iostat и т.п. вывод некоторых из них — в частности, vmstat удобно парсится и и используется в bash скриптах.

vmstat

В выводе для отслеживания состояния дисков значение имеет блок io (характеризует операции ввода-вывода — их количество и затратность для системы )

bi — blocks in — сколько блоков записали в дисковую систему

bo — blocks out — сколько считали

top

Нажатие D покажет список процессов создающих самую большую нагрузку на диск

iotop

Интерес представляют параметры о количестве процессов записи на диск и чтения с диска

Total DISK READ
Total DISK WRITE

Total — показывает пропускную способность между ядром ОС и системой ввода-вывода

Actual DISK READ
Actual DISK WRITE

Actual — показывает как система ввода-вывода обращается к железу

ionice:
—idle — процесс может использовать диск только если он простаивает и другими процессами не используется
—be — best effort (классы 0-7) — средний приоритет
—rt — real time — наивысший приоритет (классы 0-7, 7-й будет означать максимальный приоритет)

В некоторых случаях приоритет потребления диска для процессов требуется понизить, делается это как раз при помощи ionice

iostat входит в пакет sysstat — если в системе его нет, пакет можно установить при помощи apt-get

Большое количество полезной информации выведет вызов команды с ключом -x

Утилита SAR обладает широким функционалом и применяется, среди прочего, и для мониторинга дисков

sar является частью пакета sysstat. Чтобы запустить 2 теста параметров с интервалом в 5 секунд нужно выполнить sar 5 2

Используя ключ -b можно получить информацию о подсистеме ввода-вывода и использовании буферов

Linux 4.4.0-97-generic (admin-Satellite-C660) 28.10.2017 _i686_ (4 CPU)

14:54:02 tps rtps wtps bread/s bwrtn/s
14:54:07 3,80 0,00 3,80 0,00 307,20
14:54:12 0,40 0,00 0,40 0,00 12,80
Average: 2,10 0,00 2,10 0,00 160,00

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

• %busy (процент занятости),
• avque (средня длина очереди),
• r+w/s (число операций чтения и записи в секунду),
• blks/s (число переданных блоков в секунду),
• avwait (среднее время ожидания)
• avserv (среднее время обслуживания).

Большие значения %busy и avque будут говорить о существовании проблем с дисковой подсистемой.

С опцией -d будет выводиться информация по системным устройствам, -p (pretty) сделает вывод более читабельным

Linux 4.4.0-97-generic (admin-Satellite-C660) 28.10.2017 _i686_ (4 CPU)

14:55:26 DEV tps rd_sec/s wr_sec/s avgrq-sz avgqu-sz await svctm %util
14:55:31 sda 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00

14:55:31 DEV tps rd_sec/s wr_sec/s avgrq-sz avgqu-sz await svctm %util
14:55:36 sda 2,80 0,00 238,40 85,14 0,01 2,29 2,29 0,64

Average: DEV tps rd_sec/s wr_sec/s avgrq-sz avgqu-sz await svctm %util
Average: sda 1,40 0,00 119,20 85,14 0,00 2,29 2,29 0,32

Скрипт, осуществляющий мониторинг дисков Linux сервера

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

Скрипт будет контролировать только два параметра, это простейшая реализация. Однако добавив некоторый функционал и дополнительные параметры скрипт можно использовать для построения собственной системы мониторинга.

Будем парсить вывод vmstat, понадобятся значения bi и bo, которые показывают сколько операций ввода-вывода выполняется дисковой подсистемой.

procs ————memory———- —swap— ——io—- -system— ——cpu——
r b swpd free buff cache si so bi bo in cs us sy id wa st
0 1 832180 189268 67288 649176 1 18 34 38 158 778 8 2 88 2 0

Оставим в выводе только интересующие нас колонки

bi bo
34 38

При помощи tail вырежем последнюю строку со значениями

43 45

Далее приведены строки скрипта, который будет использоваться для мониторинга

Значение первого параметра будем записывать в файл bytes_in.txt

vmstat | awk ‘‘ | tail -1 | cut -f 1 -d ‘ ‘ > bytes_in.txt

Значение второго таким же образом в bytes_out.txt

vmstat | awk ‘‘ | tail -1 | cut -f 2 -d ‘ ‘ > bytes_out.txt

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

if [ `cat /home/admin/bytes_in.txt` -gt 90 ]; then echo ‘Value of bytes_in is greater then 90. Take a look’ | mail -s ‘ WARNING’ admin@example.com; fi

if [ `cat /home/admin/bytes_out.txt` -gt 90 ]; then echo ‘Value of bytes_out is greater then 90. Take a look’ | mail -s ‘WARNING’ admin@example.com; fi

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

Последние 2 можно выполнять с небольшой задержкой, которая реализуется через sleep

Получившиеся пять строк нужно добавить в CRON, если задание будет выполняться раз в минуту — администратор всегда будет в курсе возникающих проблем с вводом-выводом. Таким же образом можно контролировать значение других параметров. Можно включать в письмо актуальное значение на которое среагировал мониторинг. Нужно ли это следует решать каждый раз индивидуально.

Источник

Zabbix + Iostat: мониторинг дисковой подсистемы

Zabbix + Iostat: мониторинг дисковой подсистемы.

Зачем?
Дисковая подсистема одна из важных подсистем сервера и от уровня нагрузки на дисковую подсистему зачастую зависит очень многое, например скорость отдачи контента или то как быстро будет отвечать база данных. Это в большей степени относится к почтовым или файловым серверам, серверам БД. Вобщем, показатели дисковой производительности отслеживать нужно. На основании графиков производительности дисковой подсистемы мы можем принять решение о необходимости наращивания мощностей задолго до того как петух клюнет. Да и вобще полезно поглядывать от релиза к релизу как работа разработчиков сказывается на уровне нагрузки.

Под катом, о мониторинге и о том как настроить.

Зависимости:
Мониторинг реализован через zabbix агента и две утилиты: awk и iostat (пакет sysstat). Если awk идет в дистрибутивах по умолчанию, то iostat требуется установить с пакетом sysstat (тут отдельное спасибо Sebastien Godard и сотоварищи).

Известные ограничения:
Для мониторинга нужен sysstat начиная с версии 9.1.2, т.к. там есть очень важное изменение: «Added r_await and w_await fields to iostat’s extended statistics». Так что следует быть внимательным, в некоторых дистрибутивах, например в CentOS немного «стабильная» и менее фичастая версия sysstat.
Если же отталкиваться от версии zabbix (2.0 или 2.2) то тут вопрос не принципиален, работает на обоих версиях. На 1.8 не заработает т.к. используется Low level discovery.

Возможности (чисто субъективно, по мере убывания полезности):

• Low level discovery (далее просто LLD) для автоматического обнаружения блочных устройств на наблюдаемом узле;
• утилизация блочного устройства в % — удобная метрика для отслеживания общей нагрузки на устройстве;
• latency или отзывчивость — доступна как общая отзывчивость, так и отзывчивость на операциях чтения/записи;
• величина очереди (в запросах) и средний размер запроса (в секторах) — позволяет оценить характер нагрузки и степень загруженности устройства;
• текущая скорость чтения/записи на устройство в человекопонятных килобайтах;
• количество запросов чтения/записи (в секунду) объединенных при постановке в очередь на выполнение;
• iops — величина операций чтения/записи в секунду;
• усредненное время обслуживания запросов (svctm). Вообще она deprecated, разработчики обещают ее давно спилить, но все никак руки не доходят.

Вобщем как видно, здесь доступны все те метрики которые есть в iostat (кто незнаком с этой утилитой настоятельно рекомендую заглянуть в man iostat).

Доступные графики:
Графики рисуются per-device, LLD обнаруживает устройства которые попадают под регулярное выражение «(xvd|sd|hd|vd)[a-z]», так что если ваши диски имеют другие имена, можно легко внести соответствующие изменения. Такая регулярка сделана чтобы обнаруживать устройства которые будут родительскими по отношению к прочим разделам, LVM томам, MDRAID массивам и т.п. Вобщем чтобы не собирать лишнего. Немного отвлеклись, итак список графиков:

• Disk await — отзывчивость устройства (r_await, w_await);
• Disk merges — операции слияния в очереди (rrqm/s, wrqm/s);
• Disk queue — состояние очереди (avgrq-sz, avgqu-sz);
• Disk read and write — текущие значения чтения/записи на устройство (rkB/s, wkB/s);
• Disk utilization — утилизация диска и значение IOPS (%util, r/s, w/s) — позволяет неплохо отслеживать скачки в утилизации и чем, чтением или записью они были вызваны.

Аналоги и отличия:
В заббиксе есть коробочные варианты для похожего мониторинга, это ключи vfs.dev.read и vfs.dev.write. Они хороши и прекрасно работают, но менее информативны чем iostat. Например в iostat есть такие метрики как latency и utilization.
Также есть аналогичный шаблон от Michael Noman на мой взгляд отличие только одно, она заточена на старые версии iostat, ну и + небольшие синтаксические изменения.

Где взять:
Итак, мониторинг состоит из файла конфигурации для агента, двух скриптов для сбора/получения данных и шаблон для веб-интерфейса. Все это доступно в репозитории на Github, поэтому любым доступным способом (git clone, wget, curl, etc. ) скачиваем их на машины которые хотим замониторить и переходим к следующему пункту.

Как настроить:

• iostat.conf — содержимое этого файла следует поместить в файл конфигурации zabbix агента, либо положить в каталог конфигурации который указан в Include опции основной конфигурации агента. Вобщем зависит от политики партии. Я использую второй вариант, для кастомных конфигов у меня отдельная директория.
• scripts/iostat-collect.sh и scripts/iostat-parse.sh — эта два рабочих скрипта следует скопировать в /usr/libexec/zabbix-extensions/scripts/. Тут также можно использовать удобное вам размещение, однако в таком случае не забудьте поправить пути в параметрах определенных в iostat.conf. Не забудьте проверить что они исполняемы (mode=755).

Теперь все готово, запускаем агента и переходим на сервер мониторинга и выполняем команду (не забываем подменить agent_ip):

Таким образом, проверяем с сервера мониторинга что iostat.conf подгрузился и отдает информацию, заодно смотрим что LLD работает. В качестве ответа вернется JSON с именами обнаруженных устройств. Если ответа не пришло, значит что-то сделали не так.

Также есть такой момент, что zabbix server не дожидается выполнения некоторых item’ов со стороны агентов (iostat.collect). Для этого следует увеличить значения Timeout.

Как настроить в web интейрфейс:
Теперь остался шаблон iostat-disk-utilization-template.xml. Через веб интерфейс импортируем его в раздел шаблонов и назначем на наш хост. Тут все просто. Теперь остается ждать примерно один час, такое время установлено в LLD правиле (тоже настраивается). Или можно поглядывать в Latest Data наблюдаемого хоста, в раздел Iostat. Как только там появились значения, можно перейти в раздел графиков и понаблюдать за первыми данными.

И напоследок тройка скринов графиков c локалхоста))):
Непосредственно данные в Latest Data:

Графики отзывчивости (Latency):

График утилизации и IOPS:

Вот и собственно и все, спасибо за внимание.
Ну и по традиции, пользуясь случаем передаю привет Федорову Сергею (Алексеевичу) 🙂

Источник