Posts tagged ‘sysstat’

Оптимизация производительности. Часть 2. Инструменты.

bitoniau: Иногда на динамику автомобиля влияют не двигатель, трансмиссия и прочие умные штуки, а сгоревшая лампочка индикации затянутого ручника
bash.org.ru

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

Для вас, как для админа-“доктора”, это как градусник и стетоскоп. С помощью замера тепературы и измерения пульса сложно поставить полный диагноз, но это может быть первым признаком того, что система “хворает”, и первой “зацепкой” в том, чтобы “раскрутить” ситуацию до деталей, и поставить точный и исчерпывающий диагноз, уже с помощью более глубоких и обширных диагностических средств.

Начните со статьи в этом блоге, а также детально просмотрите описание sysstat во встроенной документации, в частности в Data ONTAP Command Reference vol1 (должна быть в комплектной документации вашей системы).

С помощью вывода sysstat вы сможете “вчерне” оценить происходящее на системе, а также понять причины какого-то странного поведения. Например, высокая загрузка дисковой подсистемы по вводу-выводу, при отсутствии входного трафика с хостов, может говорить о идущем процессе дискового “скраббинга”, высокая нагрузка на CPU при этом – о возможно идущей активной фазе процесса дедупликации данных. Маленькая величина Cache Hit – о неэффективности использования кэша системы. Короткий Cache Age – о нехватке объемов кэша, вынуждающего постоянно его опустошать для новых данных. Характер сброса Consistency Points – о характере и объемах записываемых на систему данных.

Однако это, повторюсь, только черновые, общие признаки.

К более детальным диагностическим средствам следует отнести выводы команд statit и stats. Последняя является одним из самых детальных и подробных средств, к сожалению довольно слабо документированных и с визуально очень тяжело читаемым человеком выводом, ориентированным скорее на работу собственного техсаппорта NetApp, чем анализа силами конечного юзера. Для облегчения  использования вывода stats я уже публиковал в этом блоге неплохой набор скриптов на Perl, которые осуществляют разбор и вывод данных команды stats в “человекочитаемом” виде.

Но сперва подробнее рассмотрим, что мы можем извлечь с помощью sysstats и statit.

Допустим, мы наблюдаем вот такую картину на выводе sysstat: sysstat_out1.txt (поставьте моноширинный шрифт для просмотрщика данного файла, отключите переносы строки и расширьте окно, чтобы вся длинная строка вывода влезла).

Что вас должно насторожить?

Мы видим мультипротокольную систему (FAS3140A с двумя полками дисков SATA, обслуживающая roaming profiles (от 130 до 700MB размером) примерно 3000 (до 600 одновременно работающих) пользователей под Windows XP), загруженную, главным образом, чтениями  по CIFS (до полутора тысяч операций в секунду). Обратите внимание на сравнительно невысокую загрузку CPU и сравнительно высокий уровень Cache Hit (попадания запросов не на диск, а читающихся из кэша), но при этом странное поведение CP Time/CP ty, и, что самое важное, почти полную, около 90% загрузку дисковой подсистемы. Подозрительно при этом выглядят объемы операций, как видите, в основном это чтения, и при этом не превышающие 2500-4000 килобайт в секунду. При этом на той же системе периодически проскакивающие записи могут быть и до 20 мегабайт в секунду, то есть дело явно не в слабости дисковой части. Что-то не дает дискам “разогнаться”. Ограничивает производительностьявно не процессор или память, а именно непонятная, объективно ничем не вызванная перегрузка дисковой подсистемы, ограничившая трафик на уровне 4Mb/s с всей группы дисков.

Давайте посмотрим детальнее на картину на уровне физических дисков на выводе команды statit: statit-out1.txt

Мы видим, что aggregate наш состоит из двух RAID-групп -  rg0 и rg1, в кофигурации RAID-DP 11d+2p. Диски 0c.16, 1b.17 и 0c.29, 0c.33 – диски parity. Остальные – Data.

Что тут мы видим странного. Во-первых обратите внимание на величину использования дисков 0с.25, 26 и 28, по сравнению с остальными дисками data (для дисков parity действуют другие правила, на них пока не смотрите). При средней нагрузке по дискам группы в 35%, на этих дисках загрузка почти вдвое выше, около 75%. Также высока и величина latency, она почти втрое-вчетверо выше на этих дисках, достигая 60-70 миллисекунд, против 14-17 для остальных. В нормально же работающем aggregate нагрузка должна равномерно распределяться по всем дискам aggregate.

По видимому “больное место” мы обнаружили. Проблема – в этих трех дисках, именно их аномальное поведение и перегрузка, скорее всего, и является причиной проблем. Причин возникновения такого hotspot-а может быть несколько. Например это может быть неоптимальное расширение aggregate увеличением размеров RAID-групп, о чем я как-то уже писал, при этом наиболее активные данные могут оказаться на немногих добавленных дисках, и впоследствии, при обращении к этим данным, перегрузить их, либо это признак аппаратной неисправности, как диска, так и дискового интерфейса (например большое количество ошибок на FC-интерфейсе ухудшают его показатели по latency из-за retransmission).

Итак, в соответствии с Top5, мы действительно нашли наш bottleneck в перегрузке какого-то отдельного диска (в данном случае сразу трех их), тормозящего всю подсистему.

Часто самые простые и “неромантичные” причины проблем являются и самыми частыми. Прежде чем вы начнете тюнинговать двигатель, подвеску и городить систему впрыска закиси азота, проверьте, не ездите ли вы с затянутым ручником :)

UPD: Когда этот пост уже был написан, пришло письмо с ответом на мой вопрос “чем же история закончилась?” от автора и администратора рассмотренной системы. В двух словах: Да, действительно, проблема была в этих трех дисках, они подняли кейс в поддержке, диски были заменены, и все заработало так, как должно было работать.

Средства мониторинга производительности: sysstat

Команда консоли sysstat похожа на vmstat и iostat свернутые в одну команду. Она сообщает данные производительности систем хранения, такие как CPU utilization, размеры дискового трафика, объемы ввода-вывода, как сетевого, так и по FC, а также трафик передачи данных на ленту, если она используется. При запуске без опций, sysstat печатает новую строку каждые 15 секунд, с базовым набором информации. Вы можете прервать вывод нажав control-C (^c) или установить при запуске определенный интервал работы (-c count ) для автоматической остановки через заданное время.
Список ключей команды:

-f статистика FCP
-i статистика iSCSI
-b расширенная статистика SAN (’blocks’)
-u расширенная статистика загрузки системы (’utilization’)
-x расширенный (’extended’) формат вывода. Включает в себя все доступные поля вывода.

Обратите внимание, что вывод производится в формате шире чем 80 символов, и предназначен скорее для “off-line” анализа, чем для непосредственного чтения с экрана.

-m отображает статистику по загрузке CPU на многопроцессорных системах. Применимо только на многопроцессорных системах, не работает на однопроцессорных.

Описания некоторых колонок вывода команды sysstat.

Cache age : возраст в минутах старейшего read-only блока в кэше. Значение в этой колонке показывает, насколько быстро операции чтения проходят через память системы; когда система читает очень большие файлы, значение buffer cache age будет низким. Кроме этого, если чтение преимущественно случайное, то cache age также будет низок. Если вы столкнулись с проблемой низкой производительности на чтении, то значение этого поля сможет помочь определить что вам нужно больше кэша, или нужно проанализировать работу приложения, чтобы снизить уровень “случайности” его запросов.

Cache hit : Величина в процентах для WAFL cache hit rate. Показывает, в скольки процентах читаемых с WAFL блоков они оказывались при этом уже в кэше. Прочерк в этой колонке, означает, что в измеряемый период данные не читались.

CP Ty : Тип (’type’) Consistency Point (CP). Показывает, что было причиной создания CP в рассматриваемом интервале. Тип CP может быть:

- не было CP в заданный интервал (не было записей на диск в указанный период времени)

(число) число CP, созданных в заданном интервале

B : Back to back CPs (CP generated CP) (система настолько загружена, что она начинает писать новую CP сразу за окончанием записи предыдущей)

b : задержанные back to back CPs (CP generated CP) (условия, вызвавшие состояние back to back стали хуже)

F : CP вызван заполнением NVLog (половина nvram log была заполнена, и он был сброшен на диск)

H : CP вызван high water mark (редко встречается. Система полностью заполнила одну половину nvram logs, и решила сбросить данные на диск).

L : CP вызван low water mark

S : CP вызван операцией создания snapshot

T : CP вызван таймером (каждые 10 секунд система хранения сбрасывает данные кэша на диск (flush))

U : CP вызван сбросом данных на диск (flush)

: продолжение CP с предыдущего интервала (означает, что CP все еще создается, например во время 1-секундного интервала)

Символ, следующий далее, показывает проходящую фазу создания CP на момент окончания интервала замера. Если CP завершился полностью во время интервала измерения, то второй символ будет пустой. Фазы могут быть следующие:

0 Инициализация
n обработка обычных файлов
s обработка специальных файлов
f сброс измененных данных на диск
v сброс измененного суперблока на диск

Большинство перечисленных выше значений можно увидеть только в случае предельно малых интервалов замеров, или на сильно загруженных системах, так как сброс CP происходит очень быстро. Обычно в поле CP ty вы будете видеть ‘T’, штатный сброс Consistency Point по таймеру.

Давайте разберем пример.

sysstat.txt (для более удобного вида отключите в нотепаде word wrap и расширьте окно)

Что мы можем сказать о данной системе?
Это малозагруженная, практичеси находящаяся в покое система (параметры CPU, Disk Usage и Total), использующая CIFS и FCP (небольшие ненулевые значения показывают фоновые операции по этим протоколам). Большиство операций в этой покоящейся системе совершается в виде чтения содержимого кэша (значение Cache hit). Кэш практически пуст, на что указывает монотонное возрастание значения Cache age, данные лежат, и ничто их не вытесняет. Consistency Points создаются исключительно сбросом по таймеру, что нормальное поведение для незагруженной системы.
Довольно высокие значения Disk read write при малой загрузке CPU, практически нулевом сетевом траффике и операциях ввода-вывода по блочным протоколам указывает на работу процесса Disk Scrubbing, фонового процесса контроля целостности данных и дисков, при котором система перечитывает и перезаписывает данные на дисках, возможно также что работает дедупликация, хотя она обычно дает повыше чем 1-3% загрузку, также, возможно, это признак работы дефрагментации WAFL (wafl reallocate).

Так выглядит типичный вывод sysstat малонагруженной типовой системы NetApp FAS.

А вот так выглядит система под рабочей нагрузкой: sysstat3.txt

Как видите, уже заметно нагружен процессор (это FAS6070, поэтому запас еще весьма существеннен ;), около 20%. Так как система используется как SAN, то весь трафик идет по колонке FCP. Несмотря на заметную нагрузку, ниже приведенный отчет по utilization показывает производительность около 15000 IOPS, и около 23 MB/s чтения с дисков ( и 70-90MB/s по интерфейсам FC), это не перегрузило систему. Большой объем кэша на чтение позволяет 90% операций читаться из кэша, а не с дисков.
Возраст самого старого блока в кэше составляет примерно 10-12 минут, то есть кэш еще далек от заполнения.
Здесь уже периодически проскакивают символы, показывающие фазу сброса CP, и само время записи CP увеличилось, так как вырос объем записи, хотя он и составляет всего около 1/10 от объемов чтения.

Таким образом, используя даже штатные средства контроля и анализа системы, имеющиеся в административной консоли, можно увидеть много интересного.

Оригинал тут:

http://unixfoo.blogspot.com/2007/11/netapp-performance-monitoring-sysstat_16.html

А вообще это, за исключением моего разбора примера вывода, практически перевод манов к команде из встроенного хелпа.

20/0.140

Данный блог не спонсируется, не аффилирован, и не санкционирован компанией NetApp, Inc. Излагаемая в этом блоге точка зрения выражает мнение исключительно его автора и может не совпадать с позицией NetApp, Inc.

This content is not endorsed, sponsored or affiliated with NetApp, Inc. The views expressed in this blog are solely those of the author and do not represent the views of NetApp, Inc.