Увеличение производительности AIX 5L: Часть 2. Мониторинг центрального процессора

Мониторинг центрального процессора при помощи инструментов lparstat, vmstat, sar, procmon и nmon

В этой статье описываются инструменты AIX® для мониторинга центрального процессора и объясняется, в каких ситуациях нужно использовать определенные инструменты. В статье 1этой серии цикла рассматривает методики настройки и важность предварительных процедур (например, создание контрольных точек) для настройки производительности центрального процессора. В ней также кратко рассмотрены некоторые инструментальные средства для настройки производительности, рассмотрена архитектура процессоров POWER, и показано, как эволюция процессора POWER повлияла на общее увеличение производительности линейки серверов System p™.

Кен Милберг, UNIX-консультант Future Tech, составитель технической документации и эксперт по сайту, Future Tech

Кен Милберг занимает должности Technical Writer и Site Expert на сайте techtarget.com и предоставляет техническую информацию и поддержку по Linux на searchopensource.com. Он также является автором и техническим редактором IBM Systems Magazine, Open Edition. Кен обладает степенью бакалавра компьютерных и информационных наук и степенью магистра по менеджменту технологий Университета штата Мэрилэнд. Он является основателем и лидером группы пользователей POWER-AIX Лонг-Айленда. В течение многих лет он работал как в крупных, так и небольших организациях и занимал различные должности от директора по информационным технологиям до главного разработчика AIX. Сейчас он работает в Future Tech, бизнес-партнере IBM в Лонг-Айленде. Кен обладает званиями PMI certified Project Management Professional (PMP), IBM Certified Advanced Technical Expert (CATE, IBM System p5 2006), и Solaris Certified Network Administrator (SCNA). Вы можете связаться с ним по адресу kmilberg@gmail.com.



16.11.2007

Об этой серии статей

Эти три статьи посвящены производительности центрального процессора и осуществлении его мониторинга. Первая статья предоставляет информацию о том, как эффективно осуществлять мониторинг центрального процессора, рассматривает техники настройки производительности, и объясняет, как эти изменения могут повлиять на производительность - увеличить ее или уменьшить. Если в первой статье рассмотрены несколько команд, то во второй основной акцент сделан на практические аспекты мониторинга центрального процессора и анализ тенденций и результатов. Третья статья сфокусирована на проактивном управлении потоками и других способах настроить центральный процессор на максимальную производительность. Также, в этом цикле статей я рассмотрю примеры оптимальной настройки и мониторинга производительности центрального процессора.

Введение

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

Одна из главных задач администратора AIX - это настройка обслуживаемых им систем. Настройка не может быть выполнена без предварительного мониторинга системы и анализа результатов этого мониторинга. Это необходимо как для выявления долгосрочных тенденций, так и для оперативного решения проблемы. Хотя есть специализированные инструменты, которые используются только для анализа работы центрального процессора, в зависимости от обстоятельств можно использовать инструментальные средства, которые осуществляют поиск всех возможных узких мест системы. Центральный процессор является быстродействующим компонентом системы. Если проблема возникла в центральном процессоре, то она отразится и на производительности всей системы в целом. Стоит особо отметить, что в AIX 5.3 были усовершенствованы команды для получения точных статистических данных об общих разделах, создаваемых при помощи технологии Advanced Power Virtualization: mpstat, sar, topas, и vmstat. Более того, следующие трассировочные инструментальные средства были также обновлены: curt, filemon, netpmon, pprof, и splat.

Основные инструменты UNIX для мониторинга центрального процессора

В этом разделе рассказывается об общих для всех UNIX-систем инструментах (от Solaris и до AIX). Хотя некоторые параметры разнятся от дистрибутива к дистрибутиву, большинство флагов работает одинаково во всех UNIX-системах. Они могут помочь собрать информацию "на лету", но я не рекомендую использовать их для долгосрочного сбора данных и их анализа.

Давайте начнем с vmstat. vmstat возвращает информацию о процессах, памяти, разбиениях на страницы, блокировках ввода/вывода, и активности центрального процессора. Хотя эта утилита изначально предназначена для виртуальной памяти (vm от vmstat), оказалось, что запуск vmstat на хосте - это кратчайший путь определить, что случилось с сервером AIX.

Использование vmstat

Итак, один из пользователей начал жаловаться, что система сильно тормозит, и надо быстро проанализировать ее состояние, чтобы определить возможное узкое место. В таком случае лучше всего начать с vmstat. Изучите пример 1 для того, чтобы увидеть результат работы vmstat.

Пример1. Выполнение vmstat
# vmstat 1

System configuration: lcpu=2 mem=3920MB

kthr    memory                page              faults          cpu
-----  -----------    ------------------------ ------------  -----------
r  b    avm   fre    re  pi  po  fr   sr  cy  in   sy  cs   us sy id wa
0  0  229367 332745   0   0   0   0    0   0   3  198  69    0  0 99  0
0  0  229367 332745   0   0   0   0    0   0   3   33  66    0  0 99  0
0  0  229367 332745   0   0   0   0    0   0   2   33  68    0  0 99  0
0  0  229367 332745   0   0   0   0    0   0  80  306 100    0  1 97  1
0  0  229367 332745   0   0   0   0    0   0   1   20  68    0  0 99  0
0  0  229367 332745   0   0   0   0    0   0   2   36  64    0  0 99  0
0  0  229367 332745   0   0   0   0    0   0   2   33  66    0  0 99  0
0  0  229367 332745   0   0   0   0    0   0   2   21  66    0  0 99  0
0  0  229367 332745   0   0   0   0    0   0   1  237  64    0  0 99  0
0  0  229367 332745   0   0   0   0    0   0   2   19  66    0  0 99  0
0  0  229367 332745   0   0   0   0    0   0   6   37  76    0  0 99  0

Ниже представлены пояснения для самых важных полей:

  • r -- Среднее число выполняемых ядром потоков за временной интервал, который Вы выбрали.
  • b -- Среднее число потоков, которые ждут своей очереди на выполнение в виртуальной памяти в течение заданного Вами промежутка времени. r всегда должен быть выше чем b; если нет, то в обычном случае это означает то, что слабым местом, давшим сбой, является центральный процессор.
  • fre -- размер свободной памяти. Не волнуйтесь, если он окажется маленьким короткий. Главное - определить, происходит ли разбиение этой небольшой свободной памяти на страницы.
  • pi -- Страницы, подкачанные в физическую память из виртуальной.
  • po -- Страницы, откачанные из физической памяти в виртуальную.
  • CPU сегменты:
    • us
    • sy
    • id
    • wa

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

  • us -- время пользователя
  • sy -- системное время
  • id -- время простоя
  • wa --ожидание ввода/вывода

Очевидно, что у этой системы нет проблем. Как это можно определить? Давайте взглянем на наиболее важные поля для анализа выводимой информации vmstat. Здесь нет информации о числе физических процессоров или проценте использования мощности системы, потому что не использовались микроразделы. Если запустить эту утилиту в среде с микроразделами, то появятся эти дополнительные поля, поскольку vmstat был улучшен для работы в виртуальной среде и среде микро-разбиения.

Если все записи в столбцах us и sys больше 80-ти процентов, скорее всего узкое место возникло в процессоре. Если значения в этих столбцах под 100 процентов, то система еле дышит. Если числа невелики, но значения в столбце wa (ожидание ввода/вывода) высоки (обычно больше чем 30), это может означать проблемы с подсистемой ввода/вывода, что может повлечь недостаточную нагрузку на центральный процессор. Если больше времени потрачено в sy нежели чем в us, это означает что ваша система тратит меньше времени на расчеты, чем на обработку данных, поступивших от ядра. Такая ситуация также нежелательна.

В то время как команда vmstat чаще применяется для диагностики подсистемы памяти, я считаю, что использование этой команды - быстрейший и точнейший путь определить узкое место в системе.

Так почему же пользователь жалуется на низкую производительность системы? Потому что ему казалось, что система работает слишком медленно для поставленной задачи. Я смог установить истинную причину проблемы только когда тщательно проверил систему и обнаружил, что она работает правильно. Тогда я просто посоветовал этому пользователю перезагрузить компьютер и система снова начала работать нормально. Очевидно, что какой-то процесс был нестабильным на клиентском компьютере.

На следующий день я получил еще одну жалобу и снова начал работу с vmstat (см пример 2).

Пример 2. Работа с vmstat
# vmstat 1
System configuration: lcpu=2 mem=3920MB

kthr    memory              page              faults        cpu
----- ----------- ------------------------ ------------  -----------
r  b   avm   fre   re  pi  po  fr   sr  cy  in  sy  cs   us sy id wa
9  0  4200  2746   0   0   0   0    0   0   3  198  69   70 30  0  0     0
4  7  4200  2746   0   0   0   0    0   0   3   33  66   67 31  2  0     0
2  6  4200  2746   0   0   0   0    0   0   2   33  68   65 34  1  0     0
3  9  4200  2746   0   0   0   0    0   0  80  306 100   80 20  0  1     0
2  7  4200  2746   0   0   0   0    0   0   1   20  68   80 20  0  0     0

Что означают эти данные?

Очевидно, что система ограничена по возможностям центрального процессора. В нашем случае не происходит разбиения памяти на страницы, и не возникают проблемы с вводом/выводом, зато присутствует большое множество потоков и не хватает циклов процессора, чтобы их выполнить. Для того, чтобы сделать эти выводы, потребовалось всего 5 секунд. При использовании других инструментов уйдет гораздо больше времени.

Использование sar

Следующий инструмент - sar (полное название System Activity Reporting). Эта утилита используется в UNIX на протяжении многих лет. Она записывает в стандартный поток вывода совокупную активность одного из компонентов системы, который задается флагом. Например, следующая команда использует флаг -u для вывода статистики использования центрального процессора. Как и с vmstat, если используются общие разделы в виртуальной среде, она (команда) возвращает две дополнительные колонки информации; physc и entc, которые определяют число физических процессоров, используемых разделами вместе с процентной статистикой их используемой емкости.

Я выполнил эту команду (см пример 3), когда не было пользователей, работающих с системой. За исключением нескольких процессов, я не ожидал увидеть такой бурной активности в системе.

Пример 3.Выполнение sar, на системе, с которой не работают пользователи
# sar -u 1 5 (or sar 1 5)

AIX test01 3 5     03/18/07

System configuration: lcpu=2


17:36:53    %usr    %sys    %wio   %idle   physc
17:36:54       0       0       0     100    2.00
17:36:55       1       0       0     99     2.00
17:36:56       0       0       0     100    2.00
17:36:57       0       0       0     100    2.00
17:36:58       0       0       0     100    2.00

Average        0       0       0     100    2.00

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

Колонки, выведенные выше, аналогичны колонкам, присутствующим в выводе vmstat. Следующая таблица коррелирует результаты работы sar и vmstat (см Таблица 1).

Таблица 1. sar выводит поле и соответствующее ему поле из vmstat
sarvmstat
%usrus
%syssy
%wiowa
%idleid

Одной из причин, по которой я предпочитаю использовать vmstat вместо sar, следующая: он одновременно предоставляет информацию об использовании центрального процессора и предоставляет любую информацию об использовании памяти и подсистем ввода/вывода. При использовании sar необходимо выполнять различные команды, чтобы получать и собрать такой комплект информации, какой предлагает vmstat. Одно из преимуществ sar - это возможность собирать ежедневно информацию и составлять из нее отчеты (без необходимости вручную писать скрипты). Sar делает это при помощи процесса, называемого System Activity Data Collector, который является внутренним компонентом команды sar. Когда он запущен (обычно с помощью cron, потому что в разделе AIX по умолчанию он отключен), то периодически собирает данные в двоичном формате.

Специальные инструменты AIX для мониторинга центрального процессора

Теперь обсудим утилиты, разработанные специально для AIX, и обеспечивающие мониторинг системы с разделами. Они очень полезны, особенно когда Вы используете возможности виртуализации POWER (Advanced POWER Virtualization), такие как совместное использование процессоров и микроразделы.

Использование lparstat

Когда пользователь впервые сообщает о падении производительности, нужно использовать утилиту lparstat. Цель утилиты lparstat - это предоставить информацию о логических разделах (LPAR) и другие статистические данные, относящиеся к ним. В AIX 5L 5.3, команда lparstat отображает статистические данные о многих осуществленных вызовах гипервизора POWER. Команда lparstat сравнительно новая и используется обычно при работе с разделами на уровне процессора.

Я использовал флаг -h, как показано в примере 4, потому что также хотел получить статистику о гипервизоре POWER.

Пример 4. Применение флага -h для команды lparstat
# lparstat -h 1 5

System configuration: type=Dedicated mode=Capped smt=On lcpu=4 mem=3920

%user  %sys  %wait  %idle  %hypv hcalls
-----  ----  -----  -----  ----- ------
  0.0   0.7    0.0   99.3   44.4 5933918
  0.4   0.3    0.0   99.3   44.9 5898086
  0.0   0.1    0.0   99.9   45.1 5930473
  0.0   0.1    0.0   99.9   44.6 5931287
  0.0   0.1    0.0   99.9   44.6 5931274

Как видно, вывод этой команды идентичен выводу команды sar. Отметим, что для разделов под управлением AIX 5.2 или AIX 5.3 в выделенной или общей среде с ограничениями (capped) информация об общей загрузке центрального процессора также основана на значениях user, sys, wait, and idle. В разделах под AIX 5.3, работающих в неограниченном режиме (uncapped), нагрузка будет представлена в процентном соотношении от общей мощности системы.

mpstat

Другая команда, которую я использую часто это mpstat (см Пример 5), которая является частью набора файлов bos.acct. Это инструментальное средство создано специально для AIX 5.3 (в отличии от lparstat) и отображает общую производительность для всех логических центральных процессоров в вашей система с разделами. При запуске утилиты mpstat, появляются два раздела статистических данных. Первый раздел отображает системную конфигурацию всякий раз, когда запускается эта утилита или происходит изменение в системной конфигурации. Второй раздел показывает статистику использования системы, которая выводится через промежутки времени, заданные пользователем.

Пример 5. Выполнение mpstat
 # mpstat 1 1
System configuration: lcpu=2 ent=2.0

cpu min maj mpc int cs ics rq mig lpa sysc           us sy wa id  pc  %ec   lcs
0    0   0   0  164 83 40   0 1   100  17             0  0 0 100 0.17 8.3   113
1    0   0   0  102  1  1   1 0   100 3830453 66 34   0  0 0 100  .83 41.6

Я люблю команду mpstat, потому что оно возвращает назад собранную ею информацию в очень понятном формате. Вы можете увидеть даже использование одновременной однопоточности (SMT) при помощи опции -s. Недостаток в обоих инструментальных средствах lparstat и mpstat в том, что они требуют написания скриптов для получения отформатированной информации и графики. Хотя большинство администраторов любят писать скрипты, никому не хочется заново изобретать велосипед. Если уже есть утилиты для анализа исторических данных, написание своих собственных не доставляет удовольствия.

Инструменты с графическим интерфейсом GUI

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

procmon

Начнем с procmon (см рисунок 1). Эта утилита (появившаяся в AIX 5.3) не только предоставляет обширную статистику производительности, но также позволяет воздействовать на работающие в данный момент процессы. Она позволяет администратору либо убить, либо изменить приоритет работающего процесса "на лету". Вы также можете экспортировать данные, предоставляемые procmon, в файл, что делает эту утилиту отличным средством сбора статистических данных для долгосрочного анализа. procmon обычно запускается в качестве плагина к пакету программ для работы с производительностью (performance workbench), который запускается командой perfwb (in /usr/bin) (и является частью набора файлов bos.perf.gtools.perfwb).

Рисунок 1. Информация, выводимая procmon
Информация, выводимая procmon

Мне нравится в procmon то, что он позволяет выполнять действия на "живых" процессах, что может увеличить производительность системы. Хотя у него есть свои ограничения, я настоятельно рекомендую скачать и использовать это инструментальное средство, что, как я заметил, большинство администраторов делают без особой охоты.

topas

Другой очень удобный инструмент - это topas. Откровенно говоря, я никогда не любил topas (часть набора файлов bos.perf.tools), хотя он и был существенно улучшен в AIX. 5.3. До этих изменений он не мог собирать исторические данные, и он был не приспособлен для работы с разделами. Эти недостатки были исправлены, и теперь он позволяет собирать данные о производительности нескольких разделов. Таким образом, это позволило topas более легко управлять производительностью и сделало его удобным инструментом для планирования. Дисплей topas (см рисунок 2) очень похож на дисплеи top и monitor (используемые в других вариантах на UNIX). topas - это утилита, которая отображает все типы информации в виде текста в окне GUI. По умолчанию он отображает имя хоста, периодичность обновления и различные данные о центральном процессоре, памяти и подсистеме ввода/вывода.

Рисунок 2. Информация, выводимая topas
Информация, выводимая topas

В новой версии topas также включен запуск topas на Виртуальном сервере ввода/вывода (VIO Server), для чего используется команда:

# topas -cecdisp

А на логическом разделе LPAR для запуска topas используется команда:

topas -C

Для мониторинга производительности, который был реализован в 5.3 TL 4, topas используем демон-процесс с именем xmwlm, который автоматически запускается из файла inittab. В TL_5 операционной системы AIX 5.3 этот файл хранит данные за семь дней (по умолчанию) и записывает почти все данные, предоставляемые topas, которые интерактивно отображаются, исключая информацию о процессах и информацию о Workload Manager (WLM). Используйте команду topasout для создания текстовых отчетов. Хотя в topas исправлены многие недостатки, множество администраторов могут предпочесть другую утилиту -- nmon, к примеру.

nmon

Наиболее удобна для мониторинга производительности всех компонентов системы утилита nmon (официально она не поддерживается IBM ). Данные, которые Вы можете получить из nmon (см. рисунок 3) можно вывести как на экран, так и в отчет - при помощи cron. Как сказал создатель этого инструментального средства, Нигель Гриффитс (Nigel Griffiths), "Зачем использовать пять или шесть утилит когда одна, свободно распространяемая, может решить все Ваши задачи?"

Рисунок 3. Пример данных, выводимых nmon
Образец данных, выводимых nmon

Важно отметить что в отличие уже рассмотренных инструментов nmon также доступен для использования в Linux®, и способен существенно упростить поиски причин падения производительности системы POWER с Linux. Большинство администраторов привлекает в nmon не только очень удобный пользовательский интерфейс (рисунок 3 - администратор может "на лету" вызвать этот интерфейс), но также возможность собирать данные в тестовые файлы или графики, которые nmon выводит в формате .csv (крупноформатная таблица) (см рисунок 4). Сразу после запуска nmon можно получить красивые таблицы Excel, которые можно направить начальнику или другим командам технических специалистов для дальнейшего анализа.

Давайте рассмотрим простой пример. Сначала создадим при помощи nmon файл, запустим его и пусть он выполняет сбор данных каждые тридцать секунд 180 раз (т.е. сбор данных будет происходить в течение полутора часов):

# nmon -f -t -r test2 -s 30 -c 180

Когда утилита завершит сбор данных, отсортируем файл, как показано в примере 6.

Пример 6. Сортировка файла
# sort -A testsystem_yymmd_hhmm.nmon > testsystem_yymmdd.hhmm.csv

Когда сортировка закончится, передадим файл .csv по FTP на рабочую станцию, и запустим анализатор таблиц, встроенный в nmon (убедитесь, что вы разрешили макросы), а затем нажмем на analyze nmon data (см рисунок 4).

Рисунок 4. График, выводимый анализатором nmon
График, выводимый анализатором nmon

Анализатор nmon (nmon analyzer) - это прекрасный инструмент, созданный Стивеном Аткинсом (Stephen Atkins), который представляет данные (о центральном процессоре, памяти, сети или подсистеме ввода/вывода) из таблиц Excel в виде графиков. Возможно, его единственный недостаток - неспособность собирать статистические данные с большого числа логических разделов (LPAR) одновременно, поскольку это не база данных. И в этом случае поможет рекомендуемая Гриффитсом утилита Ganglia (см. Дополнительные материалы для ссылки), поскольку она может интегрироваться с анализатором nmon.

Резюме

Во 2-й части этого цикла статей рассмотрено множество инструментов и утилит, которые можно использовать для сбора и анализа информации о производительности серверов System p, работающих под управлением операционной системы AIX. Некоторые из этих утилит были доступны и в первых релизах ОС UNIX. Многие из них разработаны специально для AIX, а некоторые официально не поддерживаются IBM, но большинство системных администраторов стараются использовать все инструменты. Независимо от того, какому инструменту отдает предпочтение администратор, необходимо использовать один из них для мгновенного отображения показателей производительности, и второй инструмент сбора данных для анализа тенденций, и на основании этого анализа проводить настройку производительности и планирование использования ресурсов. Некоторые инструменты могут справиться с обеими задачами (например, nmon), но большинство из них подходят только для одной. Рекомендую попробовать поработать с этими утилитами и выбрать ту, которая лучше всего подходит для решения ваших задач, и в то же время будет полезна для обычных пользователей, которые не умеют читать бесконечные потоки данных, выводимые vmstat.

Ресурсы

Научиться

Получить продукты и технологии

  • IBM trial software: программное обеспечение для разработчиков, загружаемое со страницы сообщества developerWorks.(EN)

Обсудить

Комментарии

developerWorks: Войти

Обязательные поля отмечены звездочкой (*).


Нужен IBM ID?
Забыли Ваш IBM ID?


Забыли Ваш пароль?
Изменить пароль

Нажимая Отправить, Вы принимаете Условия использования developerWorks.

 


Профиль создается, когда вы первый раз заходите в developerWorks. Информация в вашем профиле (имя, страна / регион, название компании) отображается для всех пользователей и будет сопровождать любой опубликованный вами контент пока вы специально не укажите скрыть название вашей компании. Вы можете обновить ваш IBM аккаунт в любое время.

Вся введенная информация защищена.

Выберите имя, которое будет отображаться на экране



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

Отображаемое имя должно иметь длину от 3 символов до 31 символа. Ваше Имя в системе должно быть уникальным. В качестве имени по соображениям приватности нельзя использовать контактный e-mail.

Обязательные поля отмечены звездочкой (*).

(Отображаемое имя должно иметь длину от 3 символов до 31 символа.)

Нажимая Отправить, Вы принимаете Условия использования developerWorks.

 


Вся введенная информация защищена.


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=40
Zone=AIX и UNIX
ArticleID=269974
ArticleTitle=Увеличение производительности AIX 5L: Часть 2. Мониторинг центрального процессора
publish-date=11162007