Как провести анализ нагрузки на дисковые подсистемы?

Question

[abbaerro]

Имеется зоопарк серверов на win, linux выполняющие разные функции (Сервер БД, Серер RDP, Маршрутизатор, телефония и т.д.).
Имеется система мониторинга Zabbix.

Вопрос в том как правильно анализировать нагрузку на дисковые подсистемы серверов (с логированием в zabbix)?
Цель своевременно понять, что ресурсов сервера для задачи не хватает и затык в дисковой (для CPU есть утилизация и средняя нагрузка, для оперативной памяти — свободная/занятая).
А вот с дисковой все сложно(

Comments

[abbaerro]

Интересует именно параметр для оценки того что дисковая перегружена (т.е. например не успевает за потоком запросов), а не то какая нагрузка…

Answer 1

[lnx]

для linux-машин могу предложить такой вариант.

Comments

[abbaerro]

Сейчас примерно это и используем, но ни один из этих параметров не показывает перегрузку. Т.е. не показывает что дисковая перегружена и не успевает. Все они показывают нагрузку(

[lnx]

зная максимальную производительность дисковой системы, можно оценить нагрузку + vmstat колонка wa -> триггер.

[abbaerro]

Я опять таки извиняюсь, но что есть максимальная производительность дисковой?
Я не силен в оценке показателей, но насколько я знаю — количество максимальных иопсов, равно как и количество максимальных мегабитов сильно зависит от блоков/размеров, а также параллельных операций.
Поэтому нельзя запустить бенчмарк, увидеть что raid 10 из sas выдает 300 мегабит на запись и 500 иопсов и сказать что в реальной ситуации сервер будет упираться в эти данные.
Опять таки я не силен в этой науке, но как я понял — хорошим для таких случаев показателем является параметр средней длины очереди ожидания.
Т.е. на дисковую приходит 1000 операций, из них в среднем 1-10 операций висят в очереди, т.е. не успевают быстро обработаться.
Значит дисковая не поспевает за запросами к ней…
И хотелось бы его читать забиксом, но если есть более подходящий показатель, то можно и его.

Кстати iowait (wa) — тоже сильно зависит от задачи, т.е. если работа идет одним потоком и основная задача этого потока чтение/запись, то он будет зашкаливать, а на деле перегруженности не будет, просто будет долгий расчет.

[lnx]

Ясно.
Ну а в чем проблема считывания iostat -x zabbix-агентом?

[lnx]

вот готовое решение.

[abbaerro]

Если я не ошибаюсь, то все способы основанные на iostat делают следующее:
Запускают iostat -x 1 2 (запросить инфу 2 раза с периодичностью 1 секунда) и по второму выводу анализируют.
Такой механизм на мой взгляд крайне не оптимальный (((.

Посему и пробую найти более оптимальный вариант…

За ссылочку спасибо)
Посмотрю может подойдет…

[lnx]

iostat первый раз выдаёт данные с момента запуска системы, а второй раз — с момнта предыдущего показа данных.
iostat -x 1 2 даст показатели за последнюю секунду.

[abbaerro]

Я это и имел ввиду…

Кстати товарищ по ссылке так и пишет (насчет моих опасений):

Из-за этих вещей возникает одна проблема, это время выполнения UserParameter. По-умолчанию в настройках сервера и агента стоят timeout=3 секунды. С таким скриптом необходимо увеличить время исполнения (повысив timeout), или добавить исполнение скрипта в cron. Будьте осторожны, увеличение timeout может также увеличить и общую нагрузку на zabbix-сервер!

[lnx]

не вижу поводов для опасений. там же товарищ пишет и про cron.
Вы же не собираетесь снимать показатели каждые три секунды?

[sch1z0phr3n1a]

Я тот товарищ с блога, который вы обсуждаете. Вообще, дисковая активность, в общем случае, имеет необычный характер нагрузки. Если вы просто включите iostat -x 1 100, и просто будете делать свои вещи, вы будете удивлены тому, как на самом деле загружены диски. В некоторые секунды они загружены полностью, а в некоторые простаивают. Именно поэтому я и собирал информацию с интервалом дискретности самого заббикса. Вообщем, снимайте с обычной для вас дискретностью заббикса (15 секунд, или сколько у вас там). Но используйте среднее значение за эти 15 секунд. iostat -x 1 2 выдает информацию, не отражающую реальность на самом деле. Как повезет с секундой. Может диск будет свободен, а может нагружен, и в заббиксе будет пила. Лучше потерять некоторую точность в предоставлении информации, но понимать, что на самом деле происходит на сервере. Если за 15 сек диск будет нагружен на 100%, заббикс не пропустит, не волнуйтесь=)

[sch1z0phr3n1a]

Ну и да, кстати. Если у вас зоопарк приличный, а мощностей самого заббикс сервера не много, то не советую использовать синхронное решение с увеличенным timeout. Воркеры заббикса будут простаивать. Лучше оформите скрипт в кроне (можете взять мою метрику выполнения, и просто добавить её в крон), а метрику, которая вызывает коллекцию данных, выключите. Так воркеры не будут простаивать=) Если есть еще вопросы — пишите, у меня есть опыт=)

[lnx]

Описание zabbix-agent system.cpu.load[<cpu>,<mode>]. В дефолтном темплейте для linux есть триггер «Disk I/O is overloaded», который срабатывает, если iowait переваливает за 20.

[abbaerro]

to sch1z0phr3n1a:
тут просто логика работы такого скрипта даже в варианте с кроном — на мой взгляд несколько не «правильная» (не оптимальная).
На мой взгляд лучше было бы сделать так:
1. Работает какой-то скрипт (демон) или что-то в этом духе, который запускает «iostat -x n» и вывод записывает в файл.
2. Работает какой-то ротатор, который этот файл очищает от старых данных (чтобы файл не разрастался).
3. Каждые n секунд zabbix запрашивает данные из этого файла.

[abbaerro]

Но для этого нужно хорошее знание программирование на bash или другом языке где можно реализовать, которых у меня к сожалению нет(

[abbaerro]

to lnx:
iowait как я писал выше — плохой показатель, т.к. он не показывает что нагрузка на дисковую больше чем ее производительность.
Она показывает сколько процессорного времени уходит на ожидание ввода/вывода.
Т.е. например если в 22:00 запускается скрипт котрый делает бекап, то в этот момент iowait будет зашкаливать, хотя это не означает что система перегружена (т.к. в это время никто не работает).
Или кто-то в монопольном режиме запускает сложный запрос и т.д…

Помимо этого сам iowait сильно привязан к производительности cpu.
пруф

Опять таки все это имхо… Но на мой взгляд iowait не подходит…

[lnx]

Ну, удачи.

[abbaerro]

Спасибо)

[sch1z0phr3n1a]

to abbaerro:
>1. Работает какой-то скрипт (демон) или что-то в этом духе, который запускает «iostat -x n» и вывод записывает в файл.
>2. Работает какой-то ротатор, который этот файл очищает от старых данных (чтобы файл не разрастался).
>3. Каждые n секунд zabbix запрашивает данные из этого файла.
Дык сейчас скрипт работает, и перетирает файл. Это и есть ротация, только с периодом указанной дискретности. Зачем добавлять еще одну сущность? Когда приходит zabbix, он всегда получает инфу за последние 15 секунд. Зачем хранить остальные? Они ведь и так будут в zabbix.

[abbaerro]

В вашем скрипте если я не ошибаюсь — дело идет так:
1. забикс каждые n секунд запрашивает данные.
2. после запроса скрипт запускает iostat и ждет еще 15 секунд пока будут данные.
3. После получения данных они скидываются в файл и скрипт их анализирует и выдает забиксу.

Соответственно получается промежуток времени (между запросами забикса) данные которого не будут попадать в отчет.
Дополнительно забикс ждет n времени пока выполнится запрос…

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

Если я не прав, то пожалуйста поправьте.
Я не силен в скриптах(((

[sch1z0phr3n1a]

Я специально разделил сущности. Есть скрипт iostat_collect.sh, есть iostat_parse.sh. Первый скрипт вызывается с одной периодичностью через метрику nomanlab.iostat.collect, и кладет в файл данные за заданный период. Все остальные метрики, обращаются к этому файлу со своими периодами через второй скрипт iostat_parse.sh. Это как раз и было сделано для того, чтобы можно было просто добавить первый скрипт в крон, отключить метрику nomanlab.iostat.collect, и ровно так же собирать данные. Причем, скрипт собирает данные за период, а дальше просто перезаписывает файл. Фактически, два скрипта работают асинхронно. А синхронно, как описано в шагах 1-2-3

[abbaerro]

Я правильно понимаю, что:
1. вызов метрики iostat.collect ждет пока выполнится скрипт, т.е. забикс ждет пока выполнится скрипт (в зависимости от параметра в скрипте)?
2. между вызовами iostat есть пробелы (т.е. периоды когда данные не собираются)?
3. вызовы самих метрик должны происходить с той же периодичностью что и collect?
4. в варианте с cron — минимальное время 1 минута (т.к. крон чаще запускаться не может)?

[sch1z0phr3n1a]

1. Да.
2. Скорее нет. Вы задаете общий период N секунд. Дальше iostat снимает данные каждую секунду в течении заданного периода N секунд (за вычетом 1 секунды, т.к. первый вывод iostat дает информацию за весь uptime). Дальше кладет данные за N-1 секунд в файл. Кладем, неагрегированные данные, хотя можно и агрегировать на самом деле.
3. На самом деле не обязательно. Период коллекции можно делать либо больше, либо меньше периода забора в zabbix. Делать период сбора коллекции больше, чем период забора в zabbix не имеет смысла, т.к. в zabbix будут просто подряд идти дублирующиеся значения. Смысла в них никакого, а база будет засираться ненужными данными. Если делать период коллекции меньше чем, период забора, то здесь нужно понимать, что тогда по этой метрике будет информация за время последнго цикла коллекции. Т.е., допустим коллекция раз в 15 сек. Забор 1 раз в минуту. Тогда, забор метрики будет за последние 15 сек. в течении прошлой минуты.

Ок, а зачем это вообще, и имеет ли смысл? На самом деле у нас метрик оч. много. На сайте описаны. У каждой может быть свой период сбора. Тогда какой выбрать для коллекции? Ну вот поэтому и оставил этот параметр для задания вручную.
4. Цикл на баше + sleep:)

[abbaerro]

В общем примерно понял.
Попробуем этот вариант реализовать.
А дальше посмотрим.

Спасибо.)

Answer 2

[EvilMan]

В Linux в статистике использования процессора смотрите значение iowait. Так же окажутся полезными утилиты vmstat, iostat и iotop.

Comments

[abbaerro]

iowait не показывает раздел/hdd на который идет нагрузка… и субъективно мне кажется не показатель…

По аналогии с советами которые видел для windows — основной показатель это
Avg. Disk Queue Length
Avg. Disk Read Queue Length
Avg. Disk Write Queue Length

Единственный подходящий аналог avgqu в iostat -x..., но я не представляю как эффективно снимать данные из iostat, ведь он работает в потоковом режиме.
Есть ли аналоги в vmstat или iotop? Так чтобы можно было полноценно снимать с помощью zabbix.
Тут больше вопрос какой параметр в них лучше отражает состояние дисковой (что в данный момент она работает на пике)?

Answer 3

[vsespb]

collectd, rrdtool habrahabr.ru/post/93205/

Comments

[abbaerro]

Извиняюсь, но это немного не в тему.
Вопрос не в том какую систему мониторинга выбрать, а как эти показатели получать (в частности получать в zabbix).

[abbaerro]

Но по логике подходит плагин disk для collectd…
Хотя сомневаюсь что среднее время ответа — показатель…
Т.к. может раз в час приходить запрос данных который выполняется минут 30 и по этим показателям, это будет означать перегрузку дисковой хотя таковой не является…

[vsespb]

Прошу прощения, действительно, когда читал вопрос показалось что zabbix не обязательный но желательный, поэтому предложил очень распространнённый набор для мониторинга ресурсов в тч диска (который к zabbix не относится), намекая что с него нужно начинать копать.

Answer 4

[Александр Демченко]

Я опять таки извиняюсь, но что есть максимальная производительность дисковой?
Я не силен в оценке показателей, но насколько я знаю — количество максимальных иопсов, равно как и количество максимальных мегабитов сильно зависит от блоков/размеров, а также параллельных операций.
Поэтому нельзя запустить бенчмарк, увидеть что raid 10 из sas выдает 300 мегабит на запись и 500 иопсов и сказать что в реальной ситуации сервер будет упираться в эти данные.
...

Здесь смотрели habrahabr.ru/post/154235/?

Comments

[abbaerro]

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

[Александр Демченко]

А как вы хотели, чтобы какой-то софт вам написал, что загрузка диска XX%? Так не бывает. Тут, как говорится, нужен не количественный, а качественный анализ. Максимальные иопсы действительно зависят от различных факторов. Поэтому Amarao и говорит в своем посте, что для анализа максимальной производительности необходимо брать worst-case (рандомное чтение-запись маленькими блоками в несколько потоков, без кэширования). Потом результаты, полученные в таком тесте можно рассматривать как теоретический потолок иопсов в вашей системе. Далее вы мониторите иопсы, которые генерирует ваше приложение и уже на основании сравнения этого числа с теоретическим максимумом делаете выводы о степени загруженности дисковой подсистемы в процентах.