Настройка AIX Workload Manager за 30 минут

В этой статье описывается менеджер нагрузки Workload Manager (WLM), включая его инсталляцию и использование. Автор подробно объясняет, как с помощью работающего в пассивном режиме WLM можно выяснить, насколько интенсивно загружают приложения центральные процессоры, память и дисковый ввод/вывод. Он также рассматривает использование WLM в активном режиме для оптимизации производительности приложения.

Найджел Гриффитс, технический специалист EMEA Linux on POWER, IBM

Найджел Гриффитс (Nigel Griffiths) – технический специалист-практик EMEA Linux on POWER и руководитель группы EMEA p5 Virtualization Technical Focus Group. Он специализируется на виртуализации, производительности, измерении и инструментальных средствах работы. Найджел является сертифицированным консультантом в области ИТ. С ним можно связаться по адресу электронной почты nag@uk.ibm.com.



14.10.2009

Что такое Workload Manager?

Workload Manager (WLM) - это бесплатная утилита для AIX 4.3.3 и AIX 5L, которая предоставляет статистические данные о производительности и позволяет управлять производительностью на уровне приложения. Каждый процесс AIX помещается в группу, называемую классом, основанную на файле с простыми правилами. Эти правила, в свою очередь, основаны на пользовательском идентификаторе, группе пользователя или названии файла приложения. Кроме того, процессы могут быть динамически прикреплены к классу.

WLM можно использовать для пассивного мониторинга; в таком случае WLM будет просто наблюдать за тем, как класс использует ресурсы (CPU, память, дисковый ввод/вывод). Это поможет понять, какие приложения используют компьютерные ресурсы. Можно использовать и активный контроль, при котором WLM будет проактивно изменять приоритеты класса задач и алгоритмы, контролирующие использование ресурсов (для этого в WLM предусмотрено четыре способа).

С точки зрения временных перспектив (краткосрочное, среднесрочное и долговременное наблюдение) существует много инструментальных средств, предназначенных для наблюдения за классами WLM. На рисунке 1 представлен снимок с экрана приложения WebSM - графического интерфейса для Workload Manager.

Рисунок 1. WebSM управляет Workload Manager
Рисунок 1. WebSM управляет Workload Manager

Когда нужен WLM?

  • Если на AIX выполняется несколько приложений и баз данных, а пользователи задают вопросы типа "Какое из приложений забрало себе основные ресурсы CPU, памяти или дискового ввода/вывода?"
  • Если необходимо ускорить время отклика сильно загруженной системы на запросы из сети (присвоить реакции на сетевой запрос более высокий приоритет, чем пакетной операции).
  • Если необходимо более интенсивно использовать сервер, но при этом не жертвовать производительностью.
  • Если необходимо взимать плату с отдельных департаментов в зависимости от использования ими сервера или реализовать модель оплаты "pay as you go".
  • Если имеется фоновая задача, которую нужно запустить, но есть опасения, что эта задача может затормозить выполнение остальных задач.
  • Для поиска приложения, слишком интенсивно использующего CPU.
  • При обновлении оборудования чтобы выяснить потребности интенсивно расходующего ресурсы приложения.

WLM может помочь ответить на эти вопросы и снова получить контроль над системой.

Предварительные требования

Сначала нужно выяснить, установлен ли на машине WLM. Он является стандартной встроенной утилитой ядра AIX, начиная с AIX 4.3.3 ML8 и до AIX 5.1:

  • AIX 4.3.3 с Maintenance Level 8 или более высоким уровнем. Эта версия WLM имеет несколько незначительных ограничений; для получения исчерпывающей информации стоит прочитать раздел Советы и замечания или соответствующий Redbook;
  • AIX 5.1 с 3-м или более высоким уровнем Maintenance Level;
  • AIX 5.2 с любым Maintenance Level.

Чтобы определить уровень AIX, используется команда oslevel.
Чтобы определить Maintenance Level, используется команда instfix -I | grep ML.

Как использовать WLM?

Существуют три способа выполнения задач системного администрирования в AIX (поскольку AIX - очень гибкая ОС), поэтому WLM также можно настраивать и использовать тремя способами. Способы эти следующие.

Команды WLM
Эти простые команды описаны далее в статье. Командная строка весьма популярна, поскольку многие системные администраторы используют telnet для доступа к AIX-серверам.
Smitty
Система простых оконных меню smitty, которую AIX использует последние десять лет, также очень популярна. При помощи этой системы можно упростить себе жизнь, снизив количество ошибок и быстро выполняя прочие операции. У smitty есть также менее популярная версия для X Windows - "smit."

Самый быстрый способ обратиться к WLM - smitty wlm. Из меню, приведенного ниже, можно получить доступ ко всем возможностям WLM.

             Workload Manager
  Work on alternate configurations
  Work on a set of Subclasses
  Show current focus (Configuration, Class Set)
  
  List all classes
  Add a class
  Change / Show Characteristics of a class
  Remove a Class
  Class assignment rules
  
  Start/Stop/Update WLM
  Assign/Unassign processes to a class/subclass
WebSM
Графическое инструментальное средство для управления AIX-системами очень простое в применении. Оно может использоваться на графических консолях pSeries, ПК, работающем под X windows, с VNC на любом компьютере, включая Windows PC или на удаленном оконном клиенте WebSM. WebSM - утилита будущего, но она пока редко используется, хотя могла бы сэкономить много времени. На рисунке 1 показан пример WebSM.

Все три перечисленных выше способа могут использоваться для управления WLM. В этой статье рассмотрены только команды WLM и smitty, поскольку они просты. Сам автор использует smitty.


The 10 step WLM process

Следующие 10 разделов объясняют, как начать пассивное наблюдение системы при помощи WLM, а затем, при необходимости, проактивно контролировать рабочие нагрузки.

  1. Классифицировать процессы.
  2. Создать классы.
  3. Создать файл с правилами.
  4. Запустить WLM в пассивном режиме.
  5. Убедиться, что классы работают так, как ожидалось.
  6. Выполнять мониторинг системы инструментами WLM.
  7. Определить, что выполняется на компьютере!
  8. Дополнительно: решить, как модифицировать использование ресурсов.
  9. Дополнительно: четыре способа активного контроля рабочей нагрузки.
  10. Вернуться к пункту 6.

Для описания этих шагов нужно больше времени, чем для их осуществления, так что не стоит пугаться размера статьи.


1. Классификация процессов

Сначала необходимо решить, на какие группы будут разбиваться приложения. В WLM эти группы называются классами. Имеется 27 суперклассов, и для начала рекомендуется использовать их. Но что, если 27 классов окажется недостаточно? Если нужно больше классов или некоторые классы нужно разбить, чтобы несколько людей могли управлять ими, то можно использовать подклассы. Максимально возможное число подклассов - 270, а на AIX 5.2 - несколько тысяч; но сначала лучше полностью разобраться в суперклассах. В этой статье не будут рассматриваться подклассы; информация по ним доступна в книге WLM Redbook.

Для каждого отдельного класса можно выполнять мониторинг и управление использованием ресурсов. 27 классов - более чем достаточно, поскольку для большинства компьютеров хватит от четырех до восьми классов. Например, может возникнуть потребность поместить каждый из следующих объектов в отдельный класс: каждую базу данных, каждый Web-сервер, каждый пакет безопасности, подсистему резервного копирования, пакетные задачи, передачу больших файлов через FTP, telnet-пользователей, администраторов и различные приложения. Для этого подготовлено несколько классов по умолчанию:

  • Shared - общая память не в другом классе;
  • System - программы, выполняемые пользователем root;
  • Default - все остальное.

Для классификации процессов существует несколько простых методов:

Идентификатор пользователя
Можно найти в файле /etc/passwd
Группа пользователя
Можно найти в файле /etc/group
Программа, которую выполняет процесс
В этом случае может использоваться только двоичный файл. Поэтому, если процесс запускается при помощи сценария, необходимо узнать фактическое имя программы, которую он запускает. В имени файла программы могут использоваться символы-шаблоны (*). Поэтому, если одно приложение имеет один каталог для всех своих двоичных файлов, все файлы в этом каталоге могут использоваться для определения класса.
Тэг приложения
У некоторых новых приложений установлен этот атрибут, который может использоваться при их классификации. К несчастью, тэги сейчас редко используются. Однако есть надежда, что в будущем теги будут использоваться чаще.

Упомянутые выше методы помогают классифицировать 95% процессов; сложные ситуации рассматриваются в разделе "Расширенная классификация". Следующая команда:

ps -e -o pid,tag,user,group,comm,args

может оказаться полезной, если нужно:

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

Расширенная классификация - только в случае крайней необходимости

Существуют и более сложные способы сгруппировать приложения. Использовать их можно в случае, если один пользователь запустил несколько копий одного и того же исполняемого файла для различных приложений. Например, такая ситуация может возникнуть при работе с DB2 и Oracle. Однако все еще можно попробовать использовать более простые методы. Стоит ответить на следующие вопросы:

  1. Можно ли скопировать двоичные файлы в другой каталог и запустить приложение из него?
  2. Можно ли просто выполнить приложения или базы данных из-под различных пользователей (просто изменив сценарий запуска)?

Если нет, то рассмотрим два следующих подхода.

  1. Если приложение или база данных запускается вручную или при помощи сценария во время загрузки, то этот сценарий можно поместить в соответствующий класс. У WLM есть особенность, называемая "наследование" (inheritance), которая может использоваться для получения гарантии того, что все процессы и подпроцессы, запускаемые этим сценарием, также будут отнесены к правильному классу. Сделать это можно путем добавления к тексту сценария следующей строки:
    wlmassign <classname> $$

    Если используется Oracle, идентификатор Oracle SID будет идеальным названием для класса. Например, если Oracle System ID (SID) = PROD123, выполните

    wlmassign PROD123 $$

    $$ означает идентификатор процесса (PID) текущей выполняемой оболочки. Если же у класса установлено свойство Inheritance=yes, эта оболочка и все процессы, которая она запустит, будут в классе PROD123.

  2. Рассмотрим другой способ. После запуска базы данных можно поместить ее процессы в соответствующий класс. Сделать это можно при помощи простого сценария и команды ps, используемой для нахождения процессов. Например, выполнить следующую команду:
    ps -u oracle -o pid,comm,args | grep 
        PROD123 | awk '{ print “wlmassign PROD123 “ $1 }' | ksh

    Недостаток заключается в том, что общая SGA-память будет не в классе PROD123, а в общем классе - shared.

После запуска WLM следует использовать wlmassign. Если были созданы новые процессы, команду следует регулярно выполнять (например, при помощи cron).

Например, рассмотрим DB2: много систем выполняют различные экземпляры базы данных из под учетных записей различных пользователей (db2inst1, db2inst2 и т.д.). Данная ситуация прекрасно подходит для WLM. Однако, если базы данных выполняются из-под одного пользовательского идентификатора (db2inst1) и необходимо наблюдать за ними по отдельности при помощи WLM, то лучше всего будет прочитать раздел DB2 в WLM Redbook. Существуют продвинутые способы использования инструментов и команд DB2 для определения процессов и динамического присвоения их классам при помощи wlmassign. Самое трудное - это сгруппировать приложения по классам. Остальные действия относительно несложные.

Примеры классов

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

RDBMSКлассифицируется домашним каталогом /database/bin/*
WebКлассифицируется двоичным файлом программы /usr/HTTPserver/bin/httpd
App2Классифицируется пользователем sally
App5Классифицируется пользователем fred. App5 - пакетное приложение.

2. Создание классов

Чтобы создать классы, используется команда mkclass, как показано ниже:

$ mkclass  -a inheritance=yes -a localshm=yes rdbms
$ mkclass  -a inheritance=yes -a localshm=yes web
$ mkclass  -a inheritance=yes -a localshm=yes app2
$ mkclass  -a inheritance=yes -a localshm=yes app5

Значения параметров inheritance и localshm классов установлены в yes. Параметр inheritance (наследование) означает, что когда процесс запускает подпроцесс, подпроцесс попадает в тот же класс. Это полезно при работе с приложениями, которые запускают много других процессов, например при создании процессом-обработчиком подключения к базе данных для пользователя. Параметр localshm означает, что любая область общей памяти, созданная процессом в классе, принадлежит классу. Это полезно для баз данных, которые обращаются к общей памяти, такой как буферный пул DB2 или Oracle SGA.

Чтобы создать классы при помощи smitty:

  • ввести команду smitty wlm
  • при помощи меню "Add Class" (добавить класс) ввести подробную информацию о классе (как в примере ниже) и нажать Return.
                General Characteristics of a class
      Class name                       [web]
      Description                      []
      Tier                             [0] 
      Resource Set
      Inheritance                      [Yes]	<change this to Yes
      . . .
      Localshm                         [Yes]	<change this to Yes

Отметим, что никакие другие атрибуты для этих классов не были установлены, что означает, что WLM не начнет контролировать процессы, расставлять приоритеты и т.д. Далее необходимо запустить WLM в пассивном режиме. При необходимости после изучения рабочей нагрузки можно установить для нее атрибуты share, tier, resource set (rset) и их ограничения, а затем запустить WLM в активном режиме.


3. Создание файла правил

Файл правил указывает WLM, какие процессы запускать в каких классах. Чтобы создать правила, необходимо отредактировать файл /etc/wlm/current/rules. Стандартный файл выглядит так:

 * class resvd user group application
System   -    root   -    -
Default  -    -      -    -

Необходимо отредактировать файл следующим образом:

* class resvd user group application
rdbms    -    -      -    /database/bin/*      -       -
web      -    -      -    /usr/HTTPserver/bin/httpd     -       -
app2     -    sally  -    -       -
app5     -    fred   -    -       -
System   -    root   -    -       -
Default  -    -      -    -       -

Все пользовательские классы должны быть расположены выше строк классов System и Default, поскольку при определении класса процесса файл с правилами интерпретируется сверху вниз. Это может оказаться очень важным. Если классы перекрываются, например, если приложение app2 и пользователь sally также запускают программы в /database/bin/*, то первое правило поместит их в класс rdbms. Если поместить правило класса класса app2 на верхнюю строчку, то данный эффект не будет достигнут. В рассматриваемом выше наборе классов порядок классов не важен (важно только то, чтобы эти классы располагались перед классами System и Default).

Чтобы добавить правила при помощи smitty:

  • ввести команду smitty wlm.
  • используя меню "Class assignment rules" (правила присвоения классов) и "Create a new Rule" (Создать новое правило), необходимо добавить информацию о правиле и нажать Return;
  • для правил, использующих имена приложений, используйте поле Application:
            Create a new Rule
    * Order of the rule            [1]
    * Class name                   web    <use F4 to display & select class
    * User                         [-]
    * Group                        [-]
      Application                  [/usr/HTTPServer/bin/httpd]
      Type                         [-]
      Tag                          [-]
  • поле User используется для правил, зависящих от идентификатора пользователя:
                Create a new Rule
    * Order of the rule            [1]
    * Class name                   app2   <use F4 to display & select class
    * User                         [sally]
    * Group                        [-]
      Application                  [-]
      Type                         [-]
      Tag                          [-]

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


4. Запуск WLM в пассивном режиме

Запуск WLM - простейшая часть работы. WLM работает в трех режимах:

Not running
WLM отключен.
Passive
WLM помещает все процессы в определенные классы и позволяет наблюдать за классами, не управляя их поведением.
Active
WLM проактивно контролирует классы в зависимости от значений атрибутов share, tier, rset и limit.

Существуют также опции "Active CPU Only mode" (режим только для активности CPU) и "With or Without Resource Set Control" (c/без управления набором ресурсов), но в данной статье они рассматриваться не будут.

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

Когда все будет готово, WLM можно будет запустить следующими командами:

ДействиеКомандаКомментарии
Запуск WLM - пассивный режимwlmcntrl -pДлительность этой команды - доли секунды.
Запуск WLM - активный режимwlmcntrl -aДлительность этой команды - доли секунды.
Остановить WLMwlmcntrl -oВыполняется мгновенно.
Обновить WLMwlmcntrl -uЗаставляет WLM пересмотреть атрибуты WLM, например, измененить share, tier, rset и ограничения из конфигурационных файлов.
Запросить текущее состояние WLMwlmcntrl -qРезультаты: Not Running, Passive, Active (отключено, пассивно, активно).
Проверить настройки WLMwlmcheckВыводит простой отчет.

Чтобы запустить WLM в пассивном режиме через smitty:

  • необходимо ввести команду smitty wlm
  • при помощи опций "Start/Stop/Update WLM" (Запустить/остановить/обновить WLM) и "Start Workload Manager" (Запустить менеджер рабочей нагрузки) установить параметры, как показано ниже, и нажать Return.
              Start Workload Manager
    Management mode                     passive  <use TAB to set to passive
    Enforce Resource Set bindings       No       <use TAB to set to No
    Start now, at next boot, or both?   Now

5. Проверка того, что классы работают как ожидалось

Необходимо:

  • проверить, попали ли процессы в корректные классы?
  • постараться удалить большинство процессов из классов System и Default, в которые процессы помещаются в случае, если для них не было задано никаких правил, и поместить эти процессы в другие классы.

Простой способ определить, какой процесс в каком классе находится, заключается в использовании показанной ниже команды. Эта команда выведет список всех процессов и классов:

ps -e -o class,pid,tag,user,group,comm,args | sort

Если процесс находится в неверном классе, необходимо проверить файл с правилами. Если в классах System и Default много процессов, стоит подумать о том, чтобы создать один-два дополнительных класса. Если изменить или добавить классы, то, чтобы они стали активными, необходимо остановить и перезапустить WLM.


6. Мониторинг системы при помощи инструментов WLM

Этот раздел описывает четыре распространенных инструмента WLM, которые можно использовать для мониторинга использования ресурсов классами WLM:

  • wlmstat - поставляется с AIX;
  • topas - поставляется с AIX;
  • Performance Toolbox - продукт IBM, который приобретается отдельно;
  • nmon - свободно распространяемый инструмент.

wlmstat

Это очень простой инструмент с интерфейсом командной строки. Как и у vmstat с iostat, у wlmstat есть параметры интервал и счетчик. Данная команда идеально подходит для быстрого обзора текущих классов и их действий. Поскольку данная команда постоянно выводит результаты вниз экрана, при длительном использовании она начинает надоедать. Вывод можно сохранить в файл для дальнейшего анализа, но его формат неудобен для анализа и обобщения.

$ wlmstat 3 99
         CLASS CPU MEM DKIO 
  Unclassified   0   3   0 
     Unmanaged   0   7   0 
       Default   0   0   0 
        Shared   0   0   0 
        System   0  15   0 
      database  50  41   0 
           web   8   4   0 
          app2   3   0   0 
          app5  16   5   0 
         TOTAL  77  65   0 
         CLASS CPU MEM DKIO 
  Unclassified   0   3   0 
     Unmanaged   0   7   0 
       Default   0   0   0 
        Shared   0   0   0 
        System   0  15   0 
      database  51  41   0 
           web   8   4   0 
          app2   3   0   0 
          app5  17   5   0 
         TOTAL  79  65   0

Команда wlmstat 3 99 через каждые три секунды покажет ресурсы, используемые классами, выполнит эти действия 99 раз, а затем остановится. Стоит отметить классы, называемые Unclassified (неклассифицированные) и Unmanaged (неуправляемые). Это специальные классы для ресурсов, которыми нельзя управлять; в дальнейшем они рассматриваться не будут, поскольку с ними ничего нельзя делать. Числа представляют процент использования CPU, памяти и дискового ввода/вывода. Столбец DKIO - это усредненный процент загрузки диска для всех дисков, используемых приложением. Значение DKIO может сбить с толку - это усредненное значение может скрыть то, что класс, допустим, неравномерно выполняет указанное число операций ввода/вывода на дисках. Поэтому для мониторинга загруженных дисков следует использовать другие инструменты.

Команда wlmstat может выводить больше информации, описанной в руководстве. Ниже приведена хорошая процедура запуска при использовании X Windows, ширина терминала которого 140 или более символов, так как в примере ниже выводятся параметры.

Если ширины используемого окна недостаточно для вывода результатов, можно использовать wlmstat -Svc для вывода статистики только по CPU (или -m для вывода статистики по использованию памяти, или -d для статистики по дисковому вводу/выводу), как показано ниже.

         CLASS tr i #pr CPU sha min smx hmx des  rap urap pri 
     Unmanaged  0 0   1   0  -1   0 100 100 100  100    0  10 
       Default  0 0  32   0  -1   0 100 100 100  100    0   0 
        Shared  0 0   0   0  -1   0 100 100 100  100    0   0 
        System  0 0  64   1  50   0 100 100  11  100    0   0 
      database  0 1  16  24 300   0 100 100  70  100    0   0 
           web  0 1   1   6  -1   0 100 100 100  100    0   0 
          app2  0 1   0   0  -1   0 100 100 100  100    0   0 
          app5  0 1   2  12  -1   0 100 100 100  100    0   0

topas

Команда topas выводит статистику производительности в неинтерактивное окно и обновляет его каждые две секунды. Для topas доступно множество опций и самых разнообразных статистических данных о производительности, поэтому стоит ознакомиться с ее руководством. Данная команда работает в любом окне терминала, X Windows, telnet-окне, пока переменная $TERM корректно задана, и постоянно обновляет выводимые данные. Сами выводимые данные представляются в удобном для восприятия формате. Ниже представлены две опции для отображения WLM-данных. Команда topas -w 27 даст следующие выходные данные:

Topas Monitor for host:    blue                 EVENTS/QUEUES  FILE/TTY
Tue Dec  9 13:21:41 2003   Interval:  2         Cswitch   411  Readch     1369
                                                Syscall  2225  Writech    3111
Kernel    0.3   |                            |  Reads      67  Rawin         0
User     85.5   |########################    |  Writes      8  Ttyout        0
Wait      0.0   |                            |  Forks       0  Igets         0
Idle     14.1   |####                        |  Execs       0  Namei        14
                                                Runqueue  3.0  Dirblk        0
Network  KBPS   I-Pack  O-Pack   KB-In  KB-Out  Waitqueue 0.0
en0       4.3     35.0     8.5     2.0     2.3
lo0       2.2      3.5     3.5     1.1     1.1  PAGING         MEMORY
                                                Faults      0  Real,MB    8191
Disk    Busy%     KBPS     TPS KB-Read KB-Writ  Steals      0  % Comp     16.6
hdisk0    1.0      6.0     1.0     0.0     6.0  PgspIn      0  % Noncomp  84.3
hdisk1    1.0      6.0     1.0     0.0     6.0  PgspOut     0  % Client   41.6
                                                PageIn      0
WLM-Class (Passive)    CPU%    Mem%  Disk-I/O%  PageOut     0  PAGING SPACE
database                 63      41         0   Sios        0  Size,MB    1024
app5                     12       5         0                  % Used      1.5
web                       8       0         0   NFS (calls/sec) % Free     98.4
app2                      2       0         0   ServerV2     0
System                    1      14         0   ClientV2     0   Press:
Shared                    0       0         0   ServerV3     0   "h" for help
Default                   0       1         0   ClientV3     0   "q" to quit
Unmanaged                 0      12         0
Unclassified              0      96         0

Если выполнить topas -W, то будут получены следующие результаты:

Topas Monitor for host:  this        Interval:   2    Tue Dec  9 05:00:16 2003
WLM-Class (Passive)           CPU%      Mem%     Disk-I/O%
app5                          18         5            0
app2                           5         0            0
web                           12         4            0
database                      63        41            0
System                         0        15            0
Shared                         0         0            0
Default                        0         0            0
Unmanaged                      0         7            0
Unclassified                   0         3            0

Чтобы остановить topas, используется клавиша q.

Performance Toolbox

Performance Toolbox - платный продукт IBM, может выполнять мониторинг сотен статистик производительности, выводить их графически и затем сохранять данные для дальнейшего анализа. Performance Toolbox - очень мощный инструмент, способный одновременно контролировать несколько компьютеров и выводить информацию в 3D-виде. Если на системе читателя этот продукт установлен, можно полагать, что он знаком с тем, как его надо настроить для мониторинга использования ресурсов на сервере (или серверах) в его центре обработки данных. При запущенном WLM доступно много других статистических WLM-данных. На рисунке 2 показано несколько панелей, в которых происходит установка параметров, и панелей с выходными данными.

Рисунок 2. Панели с установками и панели с выходным данными
Рисунок 2. Панели с установками и панели с выходным данными

Если сделать такую же статистическую выборку (потребляемые ресурсы CPU) для каждого из четырех классов и классов System и Default и построить для нее график, показывающий фигурную диаграмму (Area Graph) и последовательные данные (Stacked Data, каждая следующая порция данных поверх предыдущей), то после нескольких минут сбора данных график будет похож на график, показанный на рисунке 3.

Рисунок 3. Фигурная диаграмма
Рисунок 3. Фигурная диаграмма

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

nmon

Этот инструмент официально не поддерживается IBM. Загрузить его можно по ссылке из статьи nmon performance - free tool to analyze AIX performance. Также в поставке nmon содержится файл README, описывающий незначительные требования, необходимые для запуска nmon. Команда nmon позволяет простому окну, X Windows или telnet-сессии (с правильно настроенным значением $TERM) получать множество статистических данных о производительности AIX. Полученные данные можно записать в таблицу. Также есть специальная таблица Excel (nmon analyzer), способная считать данные из файла и автоматически вывести любые графики, отражающие производительность, или вставить эти данные в отчет по производительности. Результат работы nmon со статистическими данными, полученными из WLM, показан ниже.

nmon64 v9a               Hostname=blue  Refresh=1.0secs  13:16.56
Work Load Manager CPU MEM BIO  CPU MEM IO  CPU   MEM   BIO     Tier Inheritance
Class Name       |---Used----||--Desired-||----Shares-----|Proc's T I Localshm
Unclassified       0% 96%  0% 100  98 100    -1    -1    -1     1 0 0 0
Unmanaged          0% 12%  0% 100  99 100    -1    -1    -1     1 0 0 0
Default            0%  1%  0% 100  98 100    -1    -1    -1    33 0 0 0
Shared             0%  0%  0% 100 100 100    -1    -1    -1     0 0 0 0
System             0% 15%  0% 100  99 100    50    -1    -1    63 0 0 0
database          61% 42%  0% 100 100 100    -1    -1    -1   237 0 1 0
web                7%  0%  0% 100 100 100    -1    -1    -1   331 0 1 1
app2               2%  0%  0% 100 100 100    -1    -1    -1     9 0 1 1
app5              12%  5%  0% 100 100 100    -1    -1    -1   403 0 1 1

Команда nmon выводит: процент использования CPU, памяти, дискового ввода/вывода каждым классом; целевые значения, значения долей (share values), и количество процессов; флаги tier, Inheritance и Local Shared Memory. Если данные собирались в файл, nmon analyzer может построить их график в Excel, а для долгосрочного наблюдения построить графики, аналогичные рисунку 4 (например, более 24 снимков данных).

Рисунок 4. Долгосрочный график
Рисунок 4. Долгосрочный график

7. Узнать, что выполняется на компьютере

Какой бы инструмент ни использовался, теперь более точно известно, какие ресурсы занимает каждое приложение. Бегло взглянув на данные, предоставляемые всеми четырьмя инструментами (некоторые из них - одиночные снимки данных из долгосрочной перспективы), можно сделать некоторые заключения:

  • класс database использует ~60% CPU и ~40% памяти;
  • класс app5 использует от ~12 до 18% CPU и ~5% памяти;
  • класс Web использует от ~7 до 17% CPU и около 0% памяти;
  • класс app2 использует очень мало ресурсов.

Но данные, предоставленные инструментами, не охватывают 24 часа. В середине утра приходится пик запросов от пользователей, которые хотят выполнить генерацию отчета в фоновом режиме с помощью app5. Эти запросы занимали примерно 45% ресурсов CPU, поэтому общая загрузка системы была порядка 100%. Ночью много ресурсов компьютера использует app2; данные добавляются в БД и обрабатываются. Это все говорит о необходимости круглосуточного сбора данных WLM и сбора данных в наиболее напряженные дни. Если компьютер используется несколькими отделами, необходимо знать, кто больше всего загружает компьютер, чтобы распределять ресурсы более справедливо.

Без WLM большая часть представленной выше информации будет недоступна. Инструменты контроля производительности дадут информацию об общем использовании CPU и памяти (100% в середине утра и ночью), но не скажут о том, какое конкретно приложение или класс использует эти ресурсы. Узнать это можно при помощи других команд и множества форматирования и вычислений; однако, если на системе выполняется около 1000 процессов, общие библиотеки и распределенная память, выполнение этой задачи может занять неделю!


8. Дополнительно: как модифицировать использование ресурсов

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

Однако, если все-таки нужно модифицировать использование ресурсов приложением, то следует точно решить, чего необходимо достичь. Принять решение - достаточно сложная задача, поскольку в реальной системе доступно много возможностей. Если компьютер перегружен пару часов в сутки, можно расставить приоритеты процессов. Для содействия принятию решения WLM предоставит информацию о различных рабочих нагрузках и ресурсах. Эти параметры следует контролировать в долгосрочной перспективе, поскольку у одного приложения загрузка может быстро возрасти, а это останется незамеченным. Рассмотрим планирование мощности: если известно, что одна рабочая нагрузка (класс) вырастет в 2 раза, то можно примерно узнать, какие проблемы ожидать на данном компьютере. Итак, для классов, использованных выше:

  • если удвоилось использование класса Web-приложения, это значит, что использование им ресурсов выросло до 35% CPU и дополнительных 5% памяти. Это очень высокая рабочая нагрузка. Но она может и не быть критичной, если статистические данные WLM говорят о том, что такое состояние системы часто возникало;
  • увеличить на текущей системе интенсивность использования БД в 2 раза невозможно (120% использования CPU и вправду абсолютно недостижимо).

Далее необходимо ответить на следующие вопросы:

  1. Известно ли, для каких рабочих нагрузок важна скорость времени отклика, или какие классы нужно ускорить?
  2. Известно ли, какие рабочие нагрузки некритичны и их можно выполнять позднее, или классы, которые можно выполнить после того как минует пик использования системы?
  3. Есть ли рабочие нагрузки, которые в данный момент не выполняются, чтобы не тормозить систему? Можно ли использовать WLM для того чтобы запустить их, но позволить им использовать только те ресурсы, которые не требуются более важным классам (что позволит более интенсивно использовать компьютер)?
  4. Будет ли компьютер использоваться несколькими отделами? Нужно ли ограничить количество ресурсов, доступное одному из отделов в зависимости от того, сколько он заплатил за этот сервис?
  5. Имеется ли новая система и требуется ли ограничить ее производительность, чтобы неоправданные фантазии пользователей по поводу ее производительности не рухнули, когда в будущем на компьютер будут добавлены новые приложения?
  6. Имеются ли два или более компьютера или логических раздела (Logical Partitions, LPARs) с пиками использования в различное время и требуется ли при этом, чтобы одно приложение использовало один набор CPU, что позволит удерживать приемлемое время отклика при пиках высокой загрузки (особенно это касается Web-серверов, которые обычно очень загружены)?

9. Дополнительно: четыре способа активного управления рабочими нагрузками

Существуют четыре способа использовать WLM для проактивного контроля рабочих нагрузок. Эти способы описаны ниже. Но прежде чем перейти к их описанию, необходимо рассмотреть некоторые понятия. Для управления классами можно использовать четыре возможности WLM:

  • Shares (доли) - показывают относительную важность каждого класса;
  • Tiers (уровни) - позволяют низкоприоритетным задачам использовать дополнительные возможности;
  • Hard limits (строгие пределы) - предотвращает использование классом избыточных ресурсов;
  • Resource sets (ресурсы) - в целях изоляции или по иным причинам принуждает класс использовать определенные ресурсы.

Обычно в WLM на одной системе используется только одна такая возможность. Необходимо решить, какая возможность поможет наиболее вероятно добиться желаемой цели. Бывают случаи, когда используются две возможности, но все четыре никогда не используются.

Доли для управления рабочими нагрузками

Простой способ воспринимать доли (shares) - рассматривать их как проценты, хотя в сумме они не равняются 100%. У CPU, памяти и дискового ввода/вывода есть различные долевые значения, поэтому каждый класс имеет три доли. Для тестовых классов можно задать им следующие значения:

КлассДоли (проценты)Альтернатива 1Альтернатива 2Альтернатива 3
RDBMS 50 51000999
Web 20 2400399
App2202400 401
App5101200202

Все альтернативные значения в таблице служат одной цели. Различия между первой и второй альтернативой настолько малы, что их будет трудно определить. Доли похожи на проценты (во второй колонке 50, 20, 20, 10), так их легче понимать, но на самом деле они более гибкие. Если, например, был добавлен другой класс, и необходимо сделать его таким же важным как и текущий Web-класс, то при использовании процентов возникли бы проблемы. Пришлось бы уменьшить процентную важность каждого текущего класса, а затем присвоить освободившиеся проценты новому классу, или изменить все существующие классы (что потребовало бы много затрат).

Используя доли, достаточно только создать новый класс и присвоить ему 200 долей, и компьютер сам вычислит новые проценты. Также, если бы они были реальными процентами, что произошло бы, если бы они не составили в сумме 100%? Нужно ли нам, чтобы WLM не смог запуститься? Конечно, нет. При запуске WLM принимает значения долей, создает проценты и присваивает эти проценты классу. Однако здесь есть несколько тонкостей.

  • Предположим, что на данный момент в рассматриваемом классе нет процессов, и класс может не использовать свои ресурсы. Тогда WLM пересчитает целевые проценты и исключит пропущенный класс. Если позже в этом классе появятся процессы, то WLM повторно пересчитает проценты.
  • Если процессы класса ожидают чего-либо, например ввода от пользователя или завершения дискового ввода/вывода и сетевого взаимодействия, класс может не использовать выделенные ему проценты мощности (такое случается достаточно сложно). А что же делать с неиспользованными ресурсами? Другие классы могут использовать свободные ресурсы, но только если им разрешено (см. раздел строгие пределы).
  • Если в классе выполняется только один процесс, он может занимать только один CPU (предполагается, что потоки не используются). На компьютере с 10 CPU максимум загрузки для одного процесса - 10% от суммарной вычислительной мощности CPU. Данный факт вызывает удивление (в том числе и у авторов данной статьи), и затрагивает пакетные классы, которые часто имеют ограниченное число процессов.
  • Предположим, что имеется много классов. Естественно, что не все они одновременно должны выполняться (например, ночное приложение для резервного копирования). Если они будут выполняться одновременно, то есть вероятность, что некоторый важный класс получит для своего выполнения низкий процент ресурсов. Если добавить еще 20 классов к уже имеющимся четырем классам, можно обнаружить, что базе данных выделяется только 10% CPU. Чтобы этого не произошло, можно установить минимальный процент ресурсов для класса базы данных - 40%. Очевидно, что не нужно устанавливать минимумы для всех классов, так как это не имело бы никакого смысла!
  • Существует также максимальный процент ресурсов для случая, когда имеется совсем немного классов и не хочется выделять много ресурсов второстепенным приложениям. Например, требуется присвоить классу app5 максимум 20%. Если выполняется только класс app5 и класс базы данных, app5 получит 20%, а база данных получит все остальное.
  • Класс может превысить отведенный ему максимум ресурсов в случае, если они не нужны никакому другому классу. Такой предел называют нестрогим максимумом (soft maximum).
  • По умолчанию у классов нет долей. В различных инструментах это отражается как "-" или -1.

В простых настройках WLM обычно устанавливают значения долей и игнорируют минимальные/максимальные числа. Большинство пользователей обнаружило, что установка долей сотнями очень гибка (см. ниже). Задавать значения долей очень просто. В примере устанавливаются значения долей только для CPU. Однако аналогичные действия проводятся для памяти и дискового ввода/вывода. В командной строке введите:

chclass -c shares=500 database
chclass -c shares=200 web
chclass -c shares=200 app2
chclass -c shares=100 app5

Чтобы задать эти настройки при помощи smit, используется команда smitty wlm. Сначала необходимо выбрать опцию "Change / Show Characteristics of a class" (Изменить/показать характеристики класса), затем "CPU resource management" (Управление ресурсами центрального процессора), ввести имя класса или нажать F4 и выбрать нужное имя из списка, после этого будет показано следующее меню:

             CPU resource Management
  Class name                            web
  Shares                                [200]
  Minimum (%)                           [0] 
  Maximum (%)                           [100]
  Absolute Maximum (%)                  [100]

Необходимо добавить значения долей и нажать Return. Эти действия нужно проделать для каждого класса. Чтобы активизировать эти новые долевые значения, необходимо проинформировать WLM при помощи команды wlmcntrl -u. Или можно использовать smit: smitty wlm. Затем выбрать опции "Start/Stop/Update WLM" (Запустить/остановить/обновить WLM), "Update Workload Manager" (Обновить Workload Manager) и дважды нажать Return.

Что можно увидеть в статистике производительности, выводимой WLM? На рисунке 5 видны две рабочие нагрузки - Online и Batch - на одном компьютере, которые состязаются за время CPU. Потребности в ресурсах CPU были измерены и приведены в графике. Чтобы обе рабочие нагрузки выполнялись на полной скорости, требуется на 20% более мощный компьютер.

Рисунок 5. Запросы в CPU превышают 100%
Рисунок 5. Запросы в CPU превышают 100%

На практике график с рисунка 5 нельзя увидеть, если измерять использование CPU штатным инструментом контроля производительности (не WLM). Будет виден только общий процент использования CPU, который не очень полезен для понимания проблемы, описанной на рисунке 6.

Рисунок 6. Использование CPU
Рисунок 6. Использование CPU

При использовании WLM можно увидеть, что рабочие нагрузки Online и Batch состязаются за CPU в моменты максимальной загрузки системы; рабочая нагрузка Online была замедлена, а ее время отклика сильно уменьшено, как показано на рисунке 7.

Рисунок 7. WLM выключен. Процессы конкурируют за ресурсы...
Рисунок 7. WLM выключен. Процессы конкурируют за ресурсы...

Если переключиться в WLM и присвоить 850 долей Online и 150 долей Batch, то будет получено следующее: рабочая нагрузка Online (в моменты пика) будет использовать до 85% CPU, а рабочая нагрузка Batch использует оставшиеся ресурсы, как показано на рисунке 8.

Рисунок 8. WLM включен, рабочая нагрузка online достигает 85%
Рисунок 8. WLM включен, рабочая нагрузка online достигает 85%

Можно использовать этот подход, чтобы увеличить потребление ресурсов одними классами и уменьшить потребление ресурсов другими в моменты наивысшей загрузки системы. Когда имеются резервные ресурсы, все классы получают все необходимые ресурсы; доли в таком случае не ограничивают потребление ресурсов приложением, а только распределяют их в соответствии со своими значениями в моменты, когда состязание за ресурсы наиболее интенсивно. Например, при максимальных загрузках можно ускорить online-приложения и приостановить выполнение фоновых задач. Это поможет компьютеру более быстро отвечать на запросы пользователей, что, конечно, будет ими замечено. Эти улучшения получены за счет других классов, но обычно они необходимы.

Внутри WLM
Если бы можно было наблюдать за выполнением приложения на уровне CPU, можно было бы точно сказать, выполняется оно или нет (100% или 0%). Приложение не может выполняться частично или выполняться постоянно. С точки зрения человека, 50% времени CPU составляет несколько секунд, в каждой секунде более одного миллиарда системных тактов, в среднем приложение выполняется в течение только 50% времени CPU. И половина из этих системных тактов была выделена работающему приложению.

WLM должна наблюдать за приложением несколько секунд, чтобы определить средний процент загрузки и сравнить его с целевым процентом; затем WLM изменит приоритеты процессов. При изменении долей WLM несколько секунд тратится на выравнивание приоритетов; это означает, что показатели загрузки системы немного усредняются (особенно для приложений, которые постоянно запускаются и останавливаются - например, приложения, зависящие от ввода данных пользователем). Если дать приложению 50% ресурсов и наблюдать за ним в течение нескольких секунд, то будет видно, что приложение забирает около 50% CPU. Но оно может также забирать и 45%, и 55% CPU. Это совершенно нормально. Если выполнять контроль за классами в течение более продолжительных интервалов, например 5 секунд, то будет видно, что средний процент загрузки CPU будет более близок к целевому проценту.

Уровни (tiers) для управления рабочими нагрузками

В ходе рассуждений в этой статье использовался уровень 0 (tier 0), но существуют уровни, пронумерованные от 0 до 9. Для классов уровня 0 доступны все необходимые ресурсы; если в уровне 0 есть лишние ресурсы, они выделяются для классов уровня 1 и так далее вверх по иерархии. Если классы одного уровня используют 100% ресурсов, классы более высоких уровней могут вообще не получить ресурсов в определенный период времени в зависимости от пика рабочей нагрузки. Как уровни (tiers) помогают в управлении рабочими нагрузками? Если у рабочей нагрузки низкий приоритет, например пакетная задача, которая выполняется в фоновом режиме и может быть приостановлена при пиках рабочей нагрузки, то в этой ситуации лучше всего использовать уровни. Предположим, что имеется предельно загруженный класс Online и класс Batch, который использует 20% CPU, как показано на рисунке 9. Такая ситуация в случае максимально загруженной системы может привести к проблемам с производительностью.

Рисунок 9. Плохая производительность на CPU
Рисунок 9. Плохая производительность на CPU

Если класс Batch помещен на более высокий уровень (т.е. у него более низкий приоритет), то в моменты пиковой нагрузки он будет приостановлен и запущен вновь, когда пик пройдет (рисунок 10).

Рисунок 10. Откладывание выполнения пакетной задачи при помощи уровней
Рисунок 10. Откладывание выполнения пакетной задачи при помощи уровней

Поскольку задача Batch будет получать только свободные резервные ресурсы, компьютер сможет нормально работать при пиковых нагрузках CPU, поддерживая при этом время отклика на приемлемом уровне. Доли и уровни также смогут выполнить эту задачу, но при использовании долей не важные классы в любом случае получат некоторые ресурсы, а при использовании уровней не важные классы могут вообще остаться без ресурсов, поскольку все они будут отданы более важным классам. Считается, что лучше использовать уровни, а не экстремальные значения долей. Например, если класс A имеет 1000 долей и класс B имеет одну долю, WLM будет использовать приоритеты для удержания класса B. При использовании уровней WLM просто приостановит планирование выполнения процессов класса B. Номер уровня является параметром класса.

Чтобы задать жесткий предел для рабочей нагрузки, используется команда chclass -a tier=1 app2 или, для smitty, используется команда smitty wlm. Далее опции "Change / Show Characteristics of a class" (Изменить/просмотреть характеристики класса) и "General characteristics of a class" (Основные характеристики класса), затем ввести имя класса или нажать F4 и выбрать нужный класс. После этих действий будет выведено следующее меню:

         General Characteristics of a class
  Class name                       app2
  Description                      []
  Tier                             [1]  
  Resource Set      
  Inheritance                      [Yes]

Необходимо установить значение для поля Tier (уровень) и нажать Return. Чтобы сделанные изменения вступили в силу, необходимо обновить WLM командой wlmcntrl -u.

Использование жестких пределов для контроля рабочей нагрузки

При рассмотрении долей затрагивались максимальные и минимальные проценты. Жесткий предел, также называемый абсолютным процентом, действует точно так же за исключением того, что классу никогда не разрешается использовать более указанного количества ресурсов. Это означает, что невостребованные ресурсы будут простаивать, а не будут выделены жестко ограниченному классу. Для специалистов по производительности такая ситуация может показаться странной, поскольку может привести к умышленному спаду производительности рабочей нагрузки. В IT-отделах, которые могут выполнять для пользовательских отделов какие-либо рабочие нагрузки, это подход может пригодиться. Например, пользовательский отдел может запросить 4 CPU и 8 ГБ памяти компьютера от системы, мощности которой в 4 раза больше, или запросить себе фиксированный процент ресурсов компьютера, например 25% (на компьютере с 16 CPU).

Если рабочие нагрузки этого отдела никак не ограничиваются и оставшаяся часть ресурсов компьютера простаивает, тот этот отдел сможет использовать 100% ресурсов компьютера не платя за дополнительные CPU. Если установлены жесткие пределы, пользовательскому отделу сначала придется заплатить за лишние ресурсы, а затем системный администратор изменит для него жесткие пределы. Также это означает, что если пользовательский отдел заплатил за 4 CPU, другие жестко ограниченные отделы не смогут использовать их. Это пример типичной бюрократической службы, когда отделы получают только то, за что они заплатили.

Чтобы установить жесткий предел, из командной строки необходимо ввести chclass -c hardmax=50 app5 или при помощи smitty использовать smitty wlm. Затем использовать опции "Change / Show Characteristics of a class" (Изменить/Показать характеристики класса) и "CPU resource management" (Управление ресурсами CPU), ввести имя класса или нажать F4 и выбрать имя из предложенного списка, чтобы увидеть следующее меню:

           CPU resource Management
  Class name                            web
  Shares                                [-]  
  Minimum (%)                           [0]  
  Maximum (%)                           [100] 
  Absolute Maximum (%)                  [100]

Необходимо задать значения для поля Absolute Maximum (абсолютный максимум) и нажать Return.

Чтобы сделанные изменения вступили в силу, необходимо обновить wlmcntrl -u.

Предположим, что есть четыре отдела, каждый из которых потребляет 25% CPU. Тогда при помощи жестких пределов можно эффективно разделить ресурсы компьютера на четыре части (как это будет выглядеть логически - показано на рисунке 11). Неиспользованные ресурсы CPU в рамках каждой 25%-ной части не могут использоваться другими классами из-за жестких пределов, наложенных на них.

Рисунок 11. Жесткие пределы для каждого отдела
Рисунок 11. Жесткие пределы для каждого отдела

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

Рисунок 12. Мониторинг реальной системы
Рисунок 12. Мониторинг реальной системы

Рисунок 12 показывает, что на подконтрольном компьютере можно разместить еще и пятый отдел, поскольку на нем есть примерно 25% неиспользованных ресурсов CPU. Это означает, что IT-департамент сможет более продуктивно использовать свое оборудование и сэкономить свои средства, но вместе с тем сможет заработать больше денег на пользовательских отделах, т.е. IT-департамент сможет продать 125% компьютера.

Наборы ресурсов для управления рабочими нагрузками

Существует еще один способ контроля рабочих нагрузок при помощи наборов ресурсов (resource sets, rsets). Лучше всего это объяснено в следующем примере. Если используется компьютер с четырьмя CPU, как можно адекватно разбить ресурсы этого компьютера на части?

  • Один CPU = 1, 2, 3, 4.
  • Группы из двух CPU = 1 и 2 вместе, 3 и 4 вместе.
  • Группы с тремя CPU в одной и одним CPU в другой = 1 и 2 и 3 вместе, CPU 4 сам по себе.
  • Четыре CPU = все CPU в одной группе.

Можно придумать и другие комбинации, но следует помнить, что CPU одинаковы (поэтому набор из одного и двух CPU идентичен набору из двух и одного CPU, и так далее). Варианты группировки, приведенные выше, являются типичными наборами ресурсов для четырехпроцессорного компьютера. Чтобы заставить класс использовать набор ресурсов вместо всех CPU, можно использовать WLM. Чтобы показать рабочую нагрузку класса, выполняющего много процессов на всех CPU компьютера, в примере ниже используется nmon.

nmon64 v9a               Hostname=blue  Refresh=1.0secs  23:10.43
CPU Utilization            +-------------------------------------------------+
CPU  User%  Sys% Wait% Idle|0          |25         |50          |75       100|
 0   25.0   0.0   0.0  75.0|UUUUUUUUUUUU  >                                  |
 1   28.5   0.0   0.0  71.5|UUUUUUUUUUUUUU>                                  |
 2   33.5   1.5   0.0  65.0|UUUUUUUUUUUUUUUU>                                |
 3   32.0   0.0   0.0  68.0|UUUUUUUUUUUUUUUU                                 >
                           +-------------------------------------------------+
     29.9   0.4   0.0  69.8|UUUUUUUUUUUUUU>                                  |
                           +-------------------------------------------------+

Чтобы этот класс использовал только набор ресурсов, называемый sys/cpu.00003 (системой используется три CPU), необходимо изменить WLM. После обновления WLM класс будет вынужден использовать только один CPU, и это преобразование займет только 2 или 3 секунды.

nmon64 v9a               Hostname=blue  Refresh=1.0secs  23:14.02
CPU Utilization            +-------------------------------------------------+
CPU  User%  Sys% Wait% Idle|0          |25         |50          |75       100|
 0    0.0   1.0   0.0  99.0|              >                                  |
 1    2.0   1.0   0.0  97.0|              >                                  |
 2    0.0   2.0   0.0  98.0|s              >                                 |
 3   91.0   0.0   0.0   9.0|UUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUU >  |
                           +-------------------------------------------------+
     29.2   1.0   0.0  69.8|UUUUUUUUUUUUUUU           >                      |
                           +-------------------------------------------------+

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

Чтобы установить для этого класса набор ресурсов, используется следующая команда:

chclass -a rset='sys/cpu.00003'  database

Smitty гораздо легче использовать, поскольку он выводит список возможных наборов ресурсов. Чтобы использовать smitty, необходимо ввести команду smitty wlm. Затем выбрать опции "Change / Show Characteristics of a class" (Изменить характеристики класса) и "General characteristics of a class" (Основные характеристики класса), ввести имя класса или нажать F4 и затем выбрать это имя из предложенного списка. После этого будет выведено следующее меню:

          General Characteristics of a class
  Class name                          database
  Description                         [Production database]
  Tier                                [0]
  Resource Set                        sys/cpu.00003 <F4 and select the rset
  Inheritance                         [Yes] 
   . . .
  Localshm                            [Yes]

Далее нажать F4 в поле Resource Set, выбрать нужный набор ресурсов и нажать Return. Чтобы изменения вошли в силу, необходимо обновить WLM командой wlmcntrl -u.

На практике наборы ресурсов (rsets) могут быть очень полезными в следующих случаях:

  • В качестве альтернативы использованию жестких пределов. Класс можно заставить пользоваться только частью системы, что неплохо сработает в случае, если необходимо, чтобы класс использовал часть физических ресурсов компьютера. Например, если есть компьютер с 10 CPU и требуется, чтобы класс использовал только 20% вычислительной мощности; в таком случае класс сможет работать только с двумя CPU. Однако нельзя использовать rsets, если требуется работать только с 10% ресурсов четырехпроцессорного компьютера (поскольку расклады делятся следующим образом: 25%, 50% и 75% ресурсов от общей мощности компьютера).
  • Пользовательские отделы часто находят этот подход более понятным (они платят за 2 CPU и точно знают, что пользуются ими).
  • Если имеется некорректно работающее приложение (и класс), можно принудить его использовать только часть ресурсов компьютера. Это ограничит урон для производительности, который может нанести этот класс/приложение. Если приложение использует rset, это означает, что оно может использовать только фиксированное число CPU; но если оно не использует свои процессоры, их смогут использовать другие классы, для которых не установлен жесткий предел. Например, для двух пакетных задач отведено по два CPU, все остальные CPU используются в общем порядке.
  • Некоторые технические и научные приложения могут выиграть от разделения по различным CPU и областям памяти. Достичь этого можно при помощи логических разделов, и, как альтернатива, при помощи наборов ресурсов.

10. Вернуться к пункту 6

Напомним, что настройка производительности - цикличный процесс. Если вносились изменения в классы, уровни (tiers), доли, гибкие пределы, жесткие пределы, rsets (наборы ресурсов), необходимо убедиться, что изменения вступили в силу (перезапустив WLM), перезапустить инструменты, используемые для мониторинга производительности, и еще раз проверить, насколько было улучшено качество использования ресурсов. Теперь можно вернуться к разделу 6.


Что делать дальше?

Знаний, изложенных в той статье, достаточно для того, чтобы стать специалистом в WLM. Теперь время реализовать WLM на практике и начать решать конкретнные задачи. Применение WLM в пассивном режиме никогда не приводило к каким-либо проблемам, поскольку оно совершенно безопасно; однако перед тем как это делать, следует проверить Maintenance Level (см. Предварительные требования). Сначала необходимо использовать пассивный режим, чтобы собрать информацию о рабочих нагрузках, и затем уже принять решение о необходимости работы в активном режиме. Также желательно сразу ознакомиться с прекрасной книгой IBM Redbook AIX 5L Workload Manager (WLM).

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

  • Периодические изменения. Можно иметь несколько конфигурационных файлов WLM и переключаться между ними. Например, можно переключаться между дневной конфигурацией или ночной конфигурацией или конфигурацией выходного дня, чтобы форсировать выполнение пакетных классов и классов резервного копирования (AIX 5.2).
  • Подклассы для других классов (в данной статье использовались только суперклассы), и присвоение WLM-полномочий другим пользователям.
  • Применение WebSM для управления WLM. WebSM - это инструмент, позволяющий в графическом режиме использовать, управлять и наблюдать за WLM.
  • Наборы ресурсов могут создаваться и изменяться (подсказка: smitty rset).
  • Продолжительный WLM-мониторинг при помощи команд xmtend, wlmmon и wlmperf.
  • Полное планирование и консолидация сервера при помощи WLM.
  • Определение максимального количества входов в систему на уровне класса и предельного времени для процессоров (AIX 5.2).
  • Определение предельного времени для использования CPU процессами и предельного времени для входа пользователем в систему (безопасность), (AIX 5.2).
  • Расширение событий WLM (AIX 5.2).

Приложение A. Советы и замечания

Эти заметки взяты из практического опыта и изучения базы знаний AIX (AIX Support database) по теме проблем с WLM.

Перед тем как переходить в активный режим, необходимо выполнить пассивный мониторинг, wlmcheck и убедиться, что выполняющиеся процессы находятся в правильных классах. В разделе поддержки AIX содержится много примеров ситуаций, в которых клиенты считали, что WLM не смог запуститься из-за того, что они не проверяли его конфигурацию.
Другой причиной ошибки, связанной с WLM, может стать сам инструмент WLM (поэтому стоит попробовать использовать какой-либо другой инструмент для мониторинга производительности). WLM-совместимые инструментальные средства могут показывать странные данные после запуска WLM (некоторые из них не замечают запуска WLM). Поэтому при добавлении или удалении классов или правил необходимо выполнить команду wlmcheck, а затем перезапустить WLM (что займет 2 секунды); и затем, убедившись, что WLM не завершил аварийно свою работу, перезапустить инструмент мониторинга данных.
WLM не увеличивает производительность pSeries/AIX - он только позволяет управлять приоритетами рабочих нагрузок. При необходимости можно заставить одну рабочую нагрузку выполняться быстрее на сильно загруженной системе, что приведет к тому, что другая рабочая нагрузка будет выполняться медленнее. Поэтому следует помнить, что невозможно на загруженном компьютере ускорить выполнение всех рабочих нагрузок!
Большинство пользователей WLM управляют только использованием CPU.
Плохое управление памятью посредством WLM может привести к увеличению подкачки страниц в одном классе, даже если в системе будет достаточное количество свободной оперативной памяти!!
Единственной известной серьезной проблемой, связанной с поддержкой WLM, был клиент, который сильно ограничил память одного класса, выполняющего большое и сложное приложение. Это приложение интенсивно использовало AIX-процесс "lrud", который освобождал страницы памяти при освобождении списка свободных страниц, таким образом, тратя 100% времени на освобождение страниц. Система работала хорошо, но вот класс рабочей нагрузки выглядел так, как будто он завис, и система выполняла массивную подкачку страниц (для одного класса), что приводило к аварийному выключению компьютера.
Лучше управлять дисковым вводом/выводом, когда каждая рабочая нагрузка находится на различных дисках. Единственный способ, которым WLM может управлять дисковым вводом/выводом (если классы совместно используют диски) - это отсроченный дисковый ввод/вывод. Тогда интенсивный дисковый ввод/вывод используемого приложения будет ограничиваться медленными дисками. Такой подход работает, но он не совсем правильный.
Не нервничайте. Если случайно установить необоснованные доли и пределы, можно спровоцировать проблемы с производительностью. Лучше медленно изменять доли и пределы и наблюдать за получаемыми результатами, и так далее до нахождения оптимальной настройки.
WLM в AIX 4.3.3 имеет некоторые ограничения по сравнению с AIX 5. В частности, в AIX 4.3.3 присутствует только один глобальный флаг для принятия решения об использовании жестких пределов в WLM: wlmset -a hardcpumax=yes. В AIX 5 такой флаг доступен для каждого класса. Стоит ознакомиться с документом, в котором описаны остальные ограничения для AIX 4.3.3.
Когда WLM читает файл с правилами, он должен обратиться к программным файлам в указанных каталогах и раскрыть групповые символы. Это нужно для создания inode-номеров, используемых для помещения процессов в правильные классы (сравнение номеров файлов в сотни раз быстрее, чем сравнение имен файлов). Если пользователь root не может обратиться к нужному каталогу, то произойдет ошибка. Такая ситуация может возникнуть, если файлы смонтированы в файловой системе NFS, а пользователю root не были выданы права на чтение каталога, в котором находятся эти файлы.
Что понимается под непроизводительными издержками WLM? Ответ: ничего, ну или почти ничего (менее 0,1% CPU). WLM не процесс, так как он встроен в ядро AIX. В пассивном режиме ничего не происходит. Когда WLM переключается в активный режим, он немного изменяет вычисления, проводимые для определения приоритетов процессов, алгоритмов, используемых для управления памятью, и очередь запросов дискового ввода/вывода. Данные изменения являются заслугой команды разработки ядра AIX, которая превосходно спроектировала и реализовала WLM. WLM бесплатен, поскольку стандартно поставляется с AIX, и "бесплатен" с точки зрения потребления ресурсов CPU.

Ресурсы

Комментарии

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=435678
ArticleTitle=Настройка AIX Workload Manager за 30 минут
publish-date=10142009