 |  | |
| IT сфера | ||
 |  |
| | |
ОБ АВТОРЕ
- Наши орбиты. Корень - Новости - Введение - Резюме IT - Контакты |
||
| |
| | |
МАТЕРИАЛЫ
- Разработка - Статьи - Ссылки |
||
| |
| ||||||||||||
| ||||||||||||
|
Авторская площадка "Наши орбиты" состоит из ряда тематических подразделов, являющихся моими лабораторными дневниками, содержащими записи за разное, иногда продолжительно отличающееся, время. Эти материалы призваны рассказать о прошедшем опыте, они никого ни к чему не призывают и совершенно не обязательно могут быть применимы кем-то ещё. Это только лишь истории о прошлом Сбор статистики и анализ загрузки системы - эта тема зачастую не стоит на первом месте, и это обосновано массой решений, где возможностей UNIX серверов на современном, не таком уж и слабом, железе хватает за глаза без какого либо тюнинга системы. Поэтому зачастую администратор приходит к необходимости решения задач анализа статистики загрузки спустя какое то время Зачем может потребоваться такая аналитика ? Должна быть причина, и, обычно, это не праздное любопытство администратора. Жалобы пользователей на медленную работу или недоступность сервисов, обоснование необходимости модернизации аппаратной части перед руководством, анализ потребностей при переработке IT инфраструктуры (например с модным сейчас использованием виртуализации), запросы служб технической поддержки сторонних производителей - малая часть побуждающих к проведению аналитики загрузки системы причин Эта статья не претендует на исчерпывающую подачу материала, но опирается на реальный практический опыт автора, и призвана дать базовый материал, на основании которого заинтересованные лица смогут определить свои дальнейшие шаги | ||||||||||||
| ||||||||||||
|
UNIX предлагает несколько мощных утилит, позволяющих получить разнообразные данные о загрузке компонентов системы. На основе использования данных утилит возможно организовать сбор соответствующей статистики для проведения дальнейшей детальной аналитики Одной из комплексных команд анализа является vmstat, запускаемой обычно с параметрами период_в_секундах и количество_повторов плюс модификаторы. Может работать в штатном режиме (без модификаторов), в режиме наблюдения за дисковой активностью (при достаточной версии ядра Linux), и в других режимах. Например vmstat 1 10 соберет и отобразит системную статистику за 10 последовательно идущих 1 - секундных интервала Пример вывода: procs -----------memory---------- ---swap-- -----io---- --system-- ----cpu---- r b swpd free buff cache si so bi bo in cs us sy id wa 1 0 651496 10704 54500 189868 0 0 15 5 12 0 5 1 94 1 1 0 651496 10704 54500 189868 0 0 0 0 1005 768 45 55 0 0 1 0 651496 10704 54500 189868 0 0 0 0 1005 724 46 54 0 0 1 0 651496 10704 54500 189868 0 0 0 0 1005 778 50 50 0 0 1 0 651496 10704 54500 189868 0 0 0 12 1011 713 47 53 0 0 1 0 651496 10704 54508 189868 0 0 0 44 1012 755 48 52 0 0 1 0 651496 10704 54508 189868 0 0 0 0 1015 783 46 54 0 0 1 0 651496 10704 54508 189868 0 0 0 0 1016 740 46 54 0 0 1 0 651496 10704 54508 189868 0 0 0 0 1010 760 48 52 0 0 1 0 651496 10704 54508 189868 0 0 0 0 1007 721 47 53 0 0 Вывод отражает множество величин, в том числе использование процессора - в первом столбце (procs r) количество процессов в очереди за процессор, а также утилизацию процессора в группе "----cpu----", последовательно показывая процент утилизации пользовательскими процессами, системными, простой в ожидании ввода вывода и наконец процент незанятости процессора Также отражаются данные по утилизации памяти, отраженные в первую очередь столбцом free группы "-----------memory----------", а также столбцом swpd, отражающим объем используемого swap пространства. Отличные от 0 величины явно говорят о нехватке оперативной памяти Другие величины представлены группами "---swap--" "-----io----", отражающими активность и объем операций ввода/вывода для раздела подкачки и поблочный ввод/вывод дисковых накопителей соответственно, а группа "--system--" отражает количество прерываний и смен контекста При запуске с модификаторами -d или -p partition_name vmstat отображает статистику вводы вывода дисковых накопителей - в общем, посекторном и комплексном разрезах для чтения и записи каждого накопителя либо каждой партиции каждого накопителя, а также отражает время операций - и может использоваться в комплексном анализе Более информативно дисковый ввод/вывод отражает команда iostat (может и не поставляться с вашим дистрибутивом, для Linux обычно входит в пакет sar, о котором позднее). Данная команда также принимает аргументами интервал сбора статистики и количество итераций, а также модификаторы режима работы. Она может отображать данные утилизации процессора, но наиболее информативным является режим по умолчанию, отражающим статистику загрузки дисковых накопителей. Модификатор -x позволяет получить расширенную статистику в различных разрезах, а -p ALL позволяет отслеживать каждый раздел накопителя отдельно (параметры приведены для Linux, для Solaris есть некоторые отличия). Например команда "iostat -d -x 1 2" выдаст расширенную статистику утилизации дисковых накопителей. Статистика представляется отдельно для чтения и записи в посекторном, и покилобайтном разрезах, а также отражается количество отдельных и слитых обращений к устройству, усредненный размер обращений, время ожидания и обработки запросов, а также выводится процент утилизации устройства Пример вывода: Устройств: rrqm/s wrqm/s r/s w/s rsec/s wsec/s rkB/s wkB/s avgrq-sz avgqu-sz await svctm %util hda 0,13 12,93 1,86 4,78 27,30 141,74 13,65 70,87 25,44 0,18 27,05 1,61 1,07 sda 0,00 0,02 0,06 0,00 0,45 0,22 0,22 0,11 11,32 0,00 14,22 3,25 0,02 --- hda 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 sda 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 А при запуске команды в варианте "iostat -d -p ALL 1 2" можно получить статистику утилизации отдельных разделов накопителей, измеренной в блоках (согласно документации эквивалентно сектору в ядрах 2.4 и выше, обычно 1 sec = 512byte) Пример вывода: Устройство: tps Блок_чт/сек Блок_зап/сек Блок_чт Блок_зап hda 6,64 27,30 141,72 71603760 371766686 hda1 0,00 0,00 0,00 3116 1238 hda2 10,87 15,71 77,50 41212130 203286592 hda3 0,11 0,31 0,61 815116 1587440 hda5 8,52 10,62 62,63 27858762 164300048 hda6 0,20 0,65 0,99 1711932 2591368 sda 0,06 0,45 0,22 1170516 587912 sda1 0,08 0,45 0,22 1170340 587912 --- hda 2,00 0,00 160,00 0 160 hda2 20,00 0,00 160,00 0 160 Комплексный сбор статистики позволяет организовать пакет sar, штатно входящий в поставку Solaris, а также некоторые дистрибутивы Linux. Как вариант, можно скачать исходные тексты и скомпилировать под свою ОС (кстати sar пользуется виртуальной ФС /proc). Sar также принимает параметры интервала и количества итераций с множественными модификаторами, позволяющими собирать разнообразную статистику, в т.ч. по утилизации процессоров, памяти, дисковых накопителей и сетевой подсистемы. Другой удобной возможностью является накопление статистики в двоичном файле с последующей выборкой в требуемых разрезах, что позволяет достаточно просто организовать сбор статистики путем периодического запуска sar из планировщика с сохранением результатов в двоичном файле Примерам накопления статистической информации может служить команда "sar -o /tmp/stats.log -A 1 1", добавление которой в планировщик позволит собирать статистику с выбранной частотой. Для получения данных собранной статистики из двоичного файла необходимо при вызове sar указать, откуда брать данные модификатором -f имя_файла. Также есть возможность указать начальное и конечное время суммарной выборки. Например, для получения данных по дисковой активности из файла собранной статистики с отбрасыванием пустых значений можно дать команду "sar -f /var/log/sa/sa11 /tmp/stats.log -d -s 12:32:00 -e 12:42:00 | grep -v "0,00 0,00 0,00" 12:32:01 DEV tps rd_sec/s wr_sec/s 12:33:01 dev3-0 4,13 0,53 47,53 12:34:00 dev3-0 3,93 0,67 46,71 12:35:01 dev3-0 6,66 1,05 75,39 12:36:01 dev3-0 9,44 38,83 97,55 12:37:01 dev3-0 14,40 492,59 64,56 12:38:00 dev3-0 5,45 1,75 68,79 12:38:33 dev3-0 3,94 0,49 49,97 12:39:00 dev3-0 5,63 0,88 74,24 12:40:01 dev3-0 7,37 14,20 99,00 12:41:01 dev3-0 23,45 16,13 329,68 12:42:00 dev3-0 4,44 0,68 56,03 Среднее: dev3-0 8,85 63,06 99,15 Данные по утилизации процессора могут быть получены командой "sar -f sa11 -P ALL -s 12:32:00 -e 12:42:00" 12:32:01 CPU %user %nice %system %iowait %idle 12:33:01 all 46,47 0,00 53,53 0,00 0,00 12:34:00 all 46,96 0,00 53,04 0,00 0,00 12:35:01 all 46,88 0,00 53,12 0,00 0,00 12:36:01 all 46,59 0,03 53,33 0,05 0,00 12:37:01 all 47,29 0,00 52,71 0,00 0,00 12:38:00 all 46,59 0,00 53,41 0,00 0,00 12:38:33 all 46,33 0,00 53,67 0,00 0,00 12:39:00 all 47,02 0,00 52,98 0,00 0,00 12:40:01 all 48,89 0,00 51,11 0,00 0,00 12:41:01 all 46,89 0,07 53,04 0,00 0,00 12:42:00 all 47,34 0,00 52,66 0,00 0,00 Среднее: all 47,02 0,01 52,96 0,01 0,00 Данные по утилизации памяти и разделов подкачки могут быть получены командой "sar -f sa11 -r -s 12:32:00 -e 12:42:00". Здесь, однако, есть тонкость, касающаяся сбора статистики по использованию памяти на Sollaris. Дело в том, что в поставляемой с ОС Solaris версией пакета sar вывод данных о свободной памяти производится в страницах памяти, а не килобайтах, что может ввести в заблуждение. Для перерасчета в килобайты необходимо умножить полученное количество свободных страниц на размер одной страницы памяти. размер страницы памяти в ОС Solaris можно вывести с помощью команды ОС pagesize, которая отражает размер страницы в байтах (обычный размер страницы - 8Кб). Пример вывода данных по утилизации памяти: 12:32:01 kbmemfree kbmemused %memused kbbuffers kbcached kbswpfree kbswpused %swpused kbswpcad 12:33:01 12452 1015064 98,79 53172 165692 1380196 660048 32,35 128948 12:34:00 12132 1015384 98,82 53280 165764 1380196 660048 32,35 128948 12:35:01 11160 1016356 98,91 53488 165832 1380196 660048 32,35 128964 12:36:01 9748 1017768 99,05 54136 166560 1380196 660048 32,35 128964 12:37:01 2588 1024928 99,75 66860 164056 1380196 660048 32,35 128324 12:38:00 2288 1025228 99,78 67060 164140 1380196 660048 32,35 128324 12:38:33 2228 1025288 99,78 67100 164180 1380196 660048 32,35 128324 12:39:00 3556 1023960 99,65 66820 163500 1380196 660048 32,35 128204 12:40:01 2816 1024700 99,73 66092 164008 1380196 660048 32,35 128076 12:41:01 10580 1016936 98,97 64224 161624 1380196 660048 32,35 127924 12:42:00 10212 1017304 99,01 64476 161716 1380196 660048 32,35 127924 Среднее: 7251 1020265 99,29 61519 164279 1380196 660048 32,35 128448 Данные по утилизации сетевых интерфейсов могут быть получены командой "sar -f sa11 -n DEV -s 12:32:00 -e 12:42:00", причем существую также возможности по выводу дополнительной информации по работе сетевых интерфейсов (такой, как количество зафиксированных коллизий, отброшенных пакетов и т.д. Более детальную информацию по этим возможностям можно найти в документации по пакету sar) 12:38:00 IFACE rxpck/s txpck/s rxbyt/s txbyt/s rxcmp/s txcmp/s rxmcst/s 12:38:33 lo 0,21 0,21 11,10 11,10 0,00 0,00 0,00 12:38:33 eth0 0,82 0,12 69,59 8,49 0,00 0,00 0,00 12:38:33 eth1 21,47 12,10 6806,73 897,88 0,00 0,00 0,00 12:39:00 lo 0,58 0,58 39,75 39,75 0,00 0,00 0,00 12:39:00 eth0 1,17 0,22 95,65 13,74 0,00 0,00 0,00 12:39:00 eth1 16,70 10,23 2805,59 770,73 0,00 0,00 0,00 12:40:01 lo 0,66 0,66 41,94 41,94 0,00 0,00 0,00 12:40:01 eth0 0,41 0,10 32,27 6,24 0,00 0,00 0,00 12:40:01 eth1 16,79 10,09 2826,56 727,36 0,00 0,00 0,00 12:41:01 lo 6,01 6,01 2578,39 2578,39 0,00 0,00 0,00 12:41:01 eth0 0,43 0,21 31,94 13,52 0,00 0,00 0,00 12:41:01 eth1 18,46 11,50 4020,22 852,43 0,00 0,00 0,00 12:42:00 lo 0,39 0,39 24,54 24,54 0,00 0,00 0,00 12:42:00 eth0 0,49 0,14 35,46 7,63 0,00 0,00 0,00 12:42:00 eth1 19,29 12,79 5302,95 935,49 0,00 0,00 0,00 Среднее: lo 2,36 2,36 883,39 883,39 0,00 0,00 0,00 Среднее: eth0 0,61 0,16 48,53 10,21 0,00 0,00 0,00 Среднее: eth1 18,18 10,95 3946,81 806,74 0,00 0,00 0,00 Показанными примерами возможности sar не ограничиваются. Например, использование модификаторов -H -t позволяет изменить формат вывода утилиты для последующего эффективного распарсивания и добавления в СУБД, а множественные модификаторы предоставляют различные данные о работе системы, например скорость переключения контекста, статистику очередей ввода вывода, скорость создания новых процессов (в секунду) и т.п. Утилитой, отражающей загрузку системы в реальном времени, является top (её аналог в Solaris - prstat). Top может быть настроена в некоторых пределах под конкретные нужды пользователя (интервал обновления, сортировки, отображаемые столбцы и т.д.). Еще одна довольно простая команда - free - позволяет получить данные об утилизации памяти и swap области, в т.ч. вести наблюдение за повторяющиеся интервалы. Также удобными утилитами являются netstat, позволяющий получить информацию по открытым сетевым сессиям и fuser, отображающая использующие указанный файл или сокет процессы. Команда ps позволяет отобразить данные конкретных процессов, в т.ч. время старта, время работы, используемую память, приоритет и т.п. В целом описанный набор утиилт с теми или иными уточнениями работает на Linux, SUN Solarus и FreeBSD, и вполне себе может рабоать и на других UNIX системах. Т.к. задача обзора - показать утилиты для общего анализа загрузки системы, обзор не включает специфические механизмы получения детальной статистики (сетевые мониторы, средства отладки и профилирования приложений, управления приоритетом задач и т.п. Что то могло просто не попасть в обзор, но для получения результата - сбора статистики о загрузке основных подсистем UNIX системы - описанного должно хватить | ||||||||||||
| ||||||||||||
|
Анализируется утилизация основных компонент системы с учётом взаимного влияния - CPU, RAM, пэйджинг (своп, раздел подкачки), I/O (подсистема ввода/вывода)
Большая часть параметров собирается штатным коллектором статистик UNIX - sar и может быть уложена в базу для последующего агрегирования и анализа с помощью моего авторского инструмента СтатОС БЕССТ, который, как и все мои авторские инструменты, максимально использует предоставляемые штатными утилитами возможности, дополняя их авторскими расширениями, востребованными в процессе работы Для исследования CPU важно выверить размер очереди за процессор, который не должен превышать текущего количества ядер. В случае постоянного существенного превышения можно говорить о нехватке вычислительной мощности текущих CPU или же количества CPU в зависимости от характера прикладной нагрузки. Кроме того время простоя CPU, фактически показывающая запас вычислительной мощности, должно соответствовать определяемым требованиями к системе показателям. На мой взгляд в общем случае величина простоя должна составлять не менее 20 процентов для нагруженных систем. Конечно это общее правило, которое должно корректироваться текущей практической ситуацией Высокий показатель утилизации CPU системными процессами при невысоком показателе утилизации пользовательскими процессами говорит о неоптимальной архитектуре. В частности автору приходилось сталкиваться со случаем, когда неоптимально написанное приложение проводило избыточное частое сканирование файловой структуры с большим количеством вложенных друг в друга каталогов и файлов, что обуславливало системную нагрузку около 60 процентов при 10 процентах пользовательской нагрузки. Общее правило говорит, что системная нагрузка должна быть незначительной, а основная часть нагрузки CPU должна приходиться на пользовательские процессы Также большое время CPU, потраченное на ожидания ввода/вывода, говорит об утилизации дисковой подсистемы и требует дальнейшего анализа статистик утилизации дисковой подсистемы (подсистемы ввода/вывода, I/O) Вместе с тем при фиксации большой нагрузки на CPU причина может крыться как в нехватке физической памяти, когда ресурсы CPU используются на дополнительные операции, обеспечивающие пэйджинг (активное использование свопа/раздела подкачки), и потому факт достаточности/недостаточности памяти должен быть учтён дополнительно и по возможности исключён Анализ использования памяти должен учитывать несколько базовых постулатов. Менеджеры памяти UNIX устроены таким образом, что приложению отдаётся виртуальная память, состоящая из управляемых менеджером физической памяти и разделов подкачки. Приложение в общем случае получает виртуальныю память, и не может без дополнительных телодвижений со стороны администратора использовать только физическую память или только разделы подкачки. Операционные системы семейства UNIX стараются забрать под себя всю физическую память, поэтому часто бессмысленно смотреть на показатель количества свободной памяти на нагруженной системе, ибо физическая память, не занятая системными и пользовательскими процессами и буферами файловой системы, отдаётся под динамический кеш файловой системы. Это общее правило, из которого возможны исключения, например в случае, когда прикладная нагрузка не порождает динамичной работы с файловой системой. Ещё одним важным моментом является факт - менеджер памяти UNIX в общем случае использует небольшую часть раздела подкачки всегда, даже когда хватает физической памяти, выгружая туда давно неиспользуемые страницы физической памяти. Этот момент управляется как конкретной реализацией менеджера памяти, так и настройками ядра и особенностями конкретной ОС семейства UNIX, но очень часто можно видеть использование небольшой части раздела подкачки даже тогда, когда есть свободная физическая память Поэтому при анализе утилизации памяти необходимо обратить внимание на сигналоьный показатель объёма свободной физической памяти и раздела подкачки, после чего посмотреть на показатели объёма памяти, отдаваемой под кеш файловой системы, а также на показатели скорости обмена с разделом подкачки. Если скорость обмена с разделом подкачки низкая или нулевая, даже при фиксации использования какой то части раздела подкачки, то можно говорить о том, что физической памяти хватает. Если же скорость пэйджинга (обмена страницами с разделом подкачки) высока, то можно говорить о том, что физической памяти не хватает и нужно предпринимать какие либо действия. В частности если большая часть физической памяти отдаётся под кэш файловой системы, это может быть связано с неоптимальной конфигурацией файловых систем под ту или иную прикладную нагрузку. Например в случае использования файловых систем UNIX для хранения данных БД Oracle необходимо отключать кеширование таких разделов (в AIX это поция монтирования cio, в Linux прямой опции нет, но можно попробовать выставить флаги монтирования noatime, снижающих системную нагрузку на файловые системы). Более детальный анализ утилизации памяти возможен не во всех операционных системах. В частности Linux позволяет просмотреть разделяемые сегменты, тогда как AIX показывает всё содержимое памяти в различных разрезах. Аналогов в Linux автор не нашёл Подсистема ввода/вывода или же (в общем случае) дисковая подсистема анализируется на общем горизонте с помощью показателей сквозной утилизации (busy), времени обслуживания и очереди запросов на ввод/вывод. Важно понимать, что показатель busy означает разное в различных ОС. В частности для Linux этот показатель аналогичен времени CPU на ввод/вывод и приближение к 100 процентам говорит о проблемах в аппаратной конфигурации, тогда как в Solaris (8 и 9) и AIX показатель отражает утилизацию шины и даже при 100% загрузке не означает каких либо проблем. Хм, по крайней мере так было лет 6 назад :) Если я ошибаюсь, буду благодарен за поправку. В любом случае необходимо смотреть также на рост очереди запросов и среднее время обслуживания запроса. Принято считать, что сервистайм выше 100 - 150 миллисекунд для дискового массива является показателем нехватки его производительности на текущей прикладной нагрузке, а рост очереди является дополнительным сигнальным показателем нехватки производительности В то же время дополнительная утилизация дисковой подсистемы может быть вызвана нехваткой физической памяти и активным пэйджингом. Такую ситуацию по возможности необходимо исключать, т.к. постоянная нехватка физической памяти вводит аппаратную конфигурацию во внештатный режим работы. Также важно, что современные ОС позволяют получить инфорамцию об утилизации дисковой подсистемы в разрезе по процессам, в частности для Linux такую информацию отражает утилита atop | ||||||||||||
| ||||||||||||
|
В общем случае задача проведения аналитики сводится к постановке, обуславливающей выбор методов сбора статистики, разработке технологии анализа, обеспечивающей получение искомого результата, собственно сбору статистических данных, их агрегированию и обработке, и выдаче заключения В общем случае оптимальным можно считать решение, проводящее сбор требуемой статистической информации на основе описаных выше утилит с последующим парсингом и укладыванием этих данных в базу. Довольно заманчиво воспользоваться для этого только данными sar, но это не всегда может быть удобным. Например, в iostat довольно удобно отображается процент утилизации дисковых накопителей, определенные выборки по занятости сетевых сокетов получаются из netstat и т.п. Хотя для дежурного сбора статистики на серверах в целях текущего мониторинга sar вполне себе подходит, но и там он не дает полной информации. Например заполненность файловых систем и дескрипторов sar не отображает (для этого правильнее использовать утилиту df) Таким образом реализация механизма сбора статистики должна являться комплексом периодически запускаемых с определенными параметрами утилит, программных модулей для обработки (распарсивания) получаемых данных и укладки их в таблицы БД, и, возможно, модули проведения анализа и построения отчетов. Методы практической реализации здесь разнообразны и зависят от квалификации и багажа наработок каждого конкретного администратора Что касается технологии проведения анализа, то здесь важно принять во внимание зависимости подсистем друг от друга, чтобы не получить некорректных результатов анализа. Например высокая утилизация дисковых накопителей на фоне активного использования раздела подкачки и малых величин свободной оперативной памяти говорят не о необходимости модернизации дисковой подсистемы, но о необходимости расширения объема оперативной памяти. Другим примером может служить постоянная очередь за процессор на фоне большого количества пользовательских сессий, которое не обязательно говорит о необходимости модернизации процессоров - в зависимости от используемых приложений более правильным может оказаться внедрение многопроцессорной конфигурации. Впрочем, если используются ресурсоемкие прикладные решения, многопроцессорная конфигурация может не решить проблемы, и оптимальным будет именно апгрэйд процессоров на более мощные Правильный выбор интервалов, за которые производится сбор статистики, также требует планирования. Если множество короткоживущих процессов - нормальный режим работы системы, то задание большого интервала может оказаться таким же бессмысленным, как измерение средней температуры по больнице. В то же время слишком малые интервалы приводят к необходимости их постоянной обработки, увеличивают объем собираемой ститистики и могут увеличивать нагрузку на систему Таким образом, проведение анализа загруженности - задача, которая должна решаться с учетом потребностей каждого конкретного случая. Обзор же на этом завершен (C) Белонин С.С., январь 2005 г. (даты последующих модификаций не фиксируются)
|