Приоритет процессов и управление процессами в AIX

Управление процессами в ОС AIX

Можно управлять процессами при помощи стандартных команд kill и nice, но они не позволяют реализовать тонкий контроль над процессами. Можно "привязать" какие-либо конкретные процессы и потоки к определенным процессорам многопроцессорного сервера, работающего под управлением AIX®, но как выбрать правильные приложения и оптимизировать под них большую систему? В этой статье рассмотрены инструментальные средства для управления процессами и приведено теоретическое обоснование организации и выбора процессов и назначения им приоритетов.

Кен Милберг, 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.



11.01.2008

Введение

Администратор AIX® обычно хорошо знает основы работы с процессами, включая получение информации о них, изменение их приоритета и завершение их выполнения, и умеет настраивать и оптимизировать процессы при помощи инструментальных средств, в том числе при помощи новых утилит, которые появились в AIX 5.3. Для обеспечения эффективного контроля процессов системы крайне важно понимать различие между процессами и потоками. Эта статья также затрагивает команды ps, nice и schedtune, Process Monitor Console (procmon), AIX Workload Manager (WLM) и другие инструментальные средства. Сначала обозначим различие между процессами и потоками:

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

Другая точка зрения на их различие состоит в том, что процесс - это сущность, которую ОС использует для контроля за системными ресурсами, в то время как потоки контролируют фактическое потребление времени процессора. Большинство инструментальных средств для управления системой все еще работают с процессами, а не с потоками. Каждый процесс может владеть одним или несколькими потоками ядра (например, многопоточные приложения). Что касается потоков, то различные потоки могут выполняться на заранее определенных центральных процессорах, что является определенным преимуществом в многопроцессорных компьютерах. Приложения могут быть разработаны для работы с потоками уровня пользователя, чья работа (потоков) планируется самим же приложением или планировщиком pthreads. Многопоточность позволяет приложению обрабатывать запросы от различных пользователей одновременно. При реализации библиотеки libpthreads пользовательские потоки выполняются на виртуальных процессорах, которые расположены над потоками ядра. По ходу этой статьи будет более подробно рассмотрено взаимодействие процессов с ядром и инструментальные средства, способные помочь управлять системой в целом. Для того, чтобы увеличить эффективность управления системой, нужно изучить и использовать множество проверенных временем команд, использующихся на платформе UNIX®, и новые инструментальные средства, разработанные специально для AIX.

Потоки и SMT

Возможность выполнять потоки на различных центральных процессорах реализована для наиболее эффективного использования параллельной многопоточности (simultaneous multi-threading (SMT)). В системе, работающей в режиме SMT, процессор получает инструкции от более чем одного потока. Реализованная только в архитектуре POWER5, концепция SMT состоит в том, что ни один процесс не занимает одновременно все модули команд процессора. Архитектура POWER5 реализует двухканальный режим SMT для каждого ядра центрального процессора – каждое ядро физического процессора представлено двумя виртуальными процессорами. SMT наиболее выгоден для бизнес-приложений, где скорость одной транзакции не так важна по сравнению с общим числом выполненных транзакций. SMT, как предполагается, должен увеличить производительность приложений с большими объемами или часто изменяющимися данными, например, серверов баз данных и Web-серверов. У приложений, использующих вычисления с плавающей точкой, производительность при использовании SMT скорей всего снизится, а не улучшится, поскольку они сильно загружают блок вычислений с плавающей точкой и оперативную память. Приложения с низким числом непопаданий в кэш и низким количеством операций за один цикл скорее всего получат минимальный прирост в производительности. В обычных случаях следует ожидать примерно 30-процентного увеличения производительности системы при использовании SMT. Нужно определить, извлекают ли максимальную пользу из SMT важнейшие процессы, выполняющиеся на конкретной системе. В большинстве случаев эффективность выполнения важнейших процессов увеличивается при использовании SMT; однако если это увеличение производительности не нужно, то можно отключить режим SMT (по умолчанию он включен).

Принципы планирования

Я не будут вдаваться в тонкости работы планировщика AIX, но стоит объяснить принципы его работы прежде чем углубляться в администрирование процессов или настройку планировщиков.

Каждый центральный процессор в системе имеет свою собственную очередь на выполнение, которая представляет из себя список запущенных потоков, отсортированных по приоритетам. Есть и другая очередь выполнения, называемая глобальной. Все новые потоки помещаются в глобальную очередь на выполнение. Каждый раз, как только центральный процессор готов запустить поток на исполнение, глобальная очередь на выполнение проверяется прежде, чем очередь на выполнение самого процессора. Когда поток отработал время, отведенное ему на центральном процессоре, он возвращается в очередь выполнения процессора, на котором выполнялся. Это помогает обеспечивать родственность (affinity) процессоров в AIX. (Мы рассмотрим родственность процессоров далее.)

Есть несколько переменных среды, которые можно настроить в планировщике для увеличения производительности, но они не рассматриваются в этой статье. Центральные процессоры в системе совместно используются всеми потоками путем задания каждому потоку определенного промежутка времени, в течение которого он может работать на процессоре. Интервал времени по умолчанию равняется 10 микросекундам (один такт системных часов). Его можно поменять командой schedo. Увеличение этого временного интервала может увеличить производительность системы из-за уменьшения контекстного переключения. Оценить интенсивность контекстного переключения можно командами vmstat или sar. Если число контекстных переключений очень велико, увеличение интервала времени (количество процессорного времени, выделяемого на поток) может поднять производительность, но делать подобные действия следует только после тщательного анализа работы системы.

Теперь относительно системных режимов - существует два режима, в которых работает центральный процессор: режим ядра и пользовательский режим. В пользовательском режиме программы имеют доступ на чтение и запись пользовательских данных в области памяти, закрепленной за процессом. В этом режиме процесс работает наибольшее количество своего времени, отведенного ему на выполнение в центральном процессоре. Другой режим называется режимом ядра. Некоторые программы, которые выполняются в режиме ядра, включают в себя обработчики прерываний и процессы, выполняющиеся в ядре. Программа, выполняющаяся в этом режиме, имеет доступ на чтение и запись данных, используя всю доступную память системы, включая область данных, закрепленную за ядром. Для доступа к пользовательским данным в пределах адресного пространства процесса нужно обращаться к службам ядра. Когда пользовательская программа обращается к системным вызовам, она делает это в режиме ядра, а не в пользовательском режиме. Необходимо учитывать эту концепцию при анализе результатов, выводимых командами vmstat и sar.

Родственность процессов и их привязывание к определенным процессорам

Родственность процессов - это возможность, предоставляемая операционными системами, работающими на аппаратном обеспечении с поддержкой симметричной многопроцессорной обработки (SMP). По существу все потоки внутри процесса можно привязать на выполнение к определенному процессору. AIX сама по себе способствует родственности процессов, поддерживая очередь выполнения для каждого центрального процессора, что было рассмотрено ранее. Использование настроек родственности процессов для привязывания или, наоборот, открепления потоков от процессоров, помогает определить причину зависаний, которые трудно отладить. Некоторые приложения могут работать быстрее, если их потоки будут выполняться всегда на каком-то единственном центральном процессоре.

В обыкновенной системе с поддержкой симметричной многопроцессорной обработки (SMP) все процессоры одинаковы и могут выполнять любой поток в системе. По существу, выполнение любого процессора или потока может быть определено на любой процессор, кроме потоков и процессов, которые привязаны к какому-либо конкретному процессору. Достичь этого результата (закрепить процессы или потоки на процессоре) можно командой bindprocessor. Давайте взглянем на пример (см. листинг 1).

Листинг 1. Использование команды bindprocessor
# bindprocessor -q

The available processors are:  0 1 2 3

Эта команда выводит четыре доступных процессора: 0 1 2 3.

Следующая команда показывает, какие потоки привязаны к третьему центральному процессору (см. листинг 2).

Листинг 2. Узнаем, какие потоки привязаны к 3-му центральному процессору
# ps -emo THREAD | grep p3
    root 401544 389152        - A    0  60  1 f10001001ece2fb8   200001  pts/0
- grep p3

Также можно использовать команду SMIT fast path smit bindproc для привязывания процессов. Другой путь привязать процессы в программе состоит в использовании команды bindprocessor с интерфейсом API, доступной для AIX. Рекомендую изучить и применять эти эффективные команды. Привязывание процесса к процессору в некоторых случаях может понизить эффективность выполнения этого процесса, если процессор, к которому его привязали, слишком загружен, в то время как другие процессоры простаивают.

Утилита PS

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

Для получения списка процессов, используйте команду как в листинге 3.

Листинг 3. Получение подробного списка процессов
# ps -ef
     UID    PID   PPID   C    STIME    TTY  TIME CMD
    root      1      0   0   Jan 08      -  0:05 /etc/init
    root  82126 204974   0   Jan 08      -  0:00 /usr/sbin/snmpmibd
    root  86210 106640   0   Jan 08      -  0:00 /usr/dt/bin/dtcm
    root  90172 123038   0   Jan 08      -  0:35 /usr/lpp/X11/bin/X -D /usr/lib/X11//rgb
-T -force :0 -auth /var/dt/A:0-DjUjUa
    root  98390      1   0   Jan 08      -  8:36 /usr/sbin/syncd 60
    root 106640 131160   0   Jan 08      -  0:25 /usr/dt/bin/dtsession

Для дальнейшей идентификации процессов, загружающих центральный процессор, используйте команду из листинг 4.

Листинг 4. Идентификация процессов
# ps aux | more
USER        PID %CPU %MEM   SZ  RSS    TTY STAT    STIME  TIME COMMAND
root       8196 12.9  0.0  384  384      - A      Jan 08 14695:30 wait
root      57372 12.8  0.0  384  384      - A      Jan 08 14542:51 wait
root      61470 12.2  0.0  384  384      - A      Jan 08 13884:38 wait
root      53274 12.0  0.0  384  384      - A      Jan 08 13711:38 wait
root     245938  0.0  0.0  828  856      - A      Jan 08 20:17 /usr/bin/xmwlm -
root      98390  0.0  0.0  508  516      - A      Jan 08  8:36 /usr/sbin/syncd
root      69666  0.0  0.0  960  960      - A      Jan 08  3:46 gil
root          0  0.0  0.0  384  384      - A      Jan 08  2:49 swapper
root      49176  0.0  0.0  448  448      - A      Jan 08  1:13 xmgc
root     241842  0.0  0.0 23

Если нужно получить информацию о параметре nice для каждого процесса, то используйте флаг -l. Колонка NI отображает значение параметра nice (см. листинг 5).

Листинг 5. Использование флага -l для получения значений параметра nice
# ps -elf
   F   S   UID   PID   PPID   C PRI   NI ADDR    SZ   WCHAN  STIME   TTY TIME   CMD
200003 A   root   1      0     0      60  20 14001400  660   Jan 08  - 0:05    /etc/init
240001 A   root  82126 204974  0      60  20 3c22b510  1264  Jan 08  - 0:00 /usr/sbin/
snmpmibd
240801 A   root  86210 106640  0      60  20 584d2400  2156  Jan 08  - 0:00 
/usr/dt/bin/dtcm
240001 A   root  90172 123038  0      60  20 5136 f1000100224650e0 5136 Jan 08  - 0:35
/usr/lpp/X11/bin/X
  -D /usr/lib/X11//rgb -T -force :0 -auth /var/dt/A:0-DjUjUa
240001 A   root  98390     1   0      60  20 41a5400   508 * Jan 08  - 8:36 
/usr/sbin/syncd 60
240001 A   root 106640 131160  0      60  20 3816a400  1880  Jan 08 - 0:25 
/usr/dt/bin/dtsession
40001  A   root 123038     1   0      60  20 5c153400   380  Jan 08-  0:00 
/usr/dt/bin/dtlogin
  -daemon

Команда в листинге 6 выводит три наиболее интенсивно загружающих ресурсы процесса вместе со значениями их параметров nice.

Листинг 6. Получение тройки самых активно выполняющихся процессов
# ps -elf | egrep -v "STIME|$LOGNAME" | sort +3 -r | head -n 15
40401 A   nobody 323762 127128 060 20 602dc400 660 f1000600002daa08Jan 08  -  0:00
/usr/HTTPServer/bin/httpd -d /usr/HTTPServer -k restart
   40001 A   nobody 319662 127128   0  60 20 6c35f400  1336        *   Jan 08      -  0:00
/usr/HTTPServer/bin/httpd -d /usr/HTTPServer -k restart
   40001 A   nobody 307358 127128   0  60 20 3834a400  1340        *   Jan 08      -  0:00
/usr/HTTPServer/bin/httpd -d /usr/HTTPServer -k restart
  240001 A   daemon 254084 204974   0  60 20 58272400  1364            Jan 08      -  0:00
/usr/sbin/rpc.statd -d 0 -t 50

Итак, мы выяснили, какие процессы тормозят систему (для этих целей также можно использовать topas или nmon) и теперь нужно понизить их приоритет. Существует команда, которая позволяет устанавливать приоритет процесса до начала его выполнения, и команда, которая позволяет менять приоритет уже выполняющихся процессов - nice и renice соответственно. Пользовательские процессы в AIX имеют базовое значение приоритета 40 и значение параметра nice равным 20. В сумме эти два числа являются значением приоритета по умолчанию 60. Большинство процессов имеют такой приоритет. Чем выше значение приоритета процесса, тем менее он приоритетен. Если нужно запустить процесс с наименьшим приоритетом, то используйте команду из листинга 7.

Листинг 7. Запуск процесса с наименьшим приоритетом
# nice -n 10 thisjob

Команда в листинг 7 добавляет 10 единиц к значению параметра nice по умолчанию (20 единиц) (итого значение параметра nice становится 30) и суммарный приоритет становится 70.

Запуск команды из листинга 8 принудит процесс 1683 сменить значение параметра nice на 30.

Листинг 8. Изменение значения параметра nice на 10 единиц для процесса 1683
# renice -n 10 -p 1683

Утилита procmon

Хотя существует несколько инструментов контроля производительности, входящих в комплект поставки AIX, возможно самый эффективный из них – это появившаяся в AIX 5.3 утилита procmon. Эта утилита отображает список процессов, меняющийся со временем при необходимости, с подробной информацией о каждом элемента списка.Также она позволяет использовать базовые команды администрирования nice, renice и kill. Инструментальное средство procmon выполняется на платформе Performance Workbench, которая в свою очередь является приложением, созданным на основе Eclipse, и содержит некоторые элементы графического интерфейса для отображения деятельности системы. procmon вызывается командой perfwb, которая запустит Eclipse с плагином procmon (см. листинг 9) (для этого необходим набор файлов bos.perf.gtools.perfwb ).

Листинг 9. Выполнение perfwb
# /usr/bin/perfwb

По умолчанию утилита procmon выведет информацию по следующим аспектам:

  • Как долго выполняется процесс
  • Сколько ресурсов центрального процессора потребляется использующими его процессами
  • Штрафуются ли процессы системой
  • Как много памяти используют процессы
  • Как много процессов ввода/вывода выполняется
  • Приоритет процесса
  • Кто запустил какой-либо определенный процесс

Также можно запускать ее со следующими опциями:

  • procfiles
  • proctree
  • procsig
  • procstack
  • procrun
  • procmap
  • procflags
  • proccred
  • procldd

Таблица с процессами, являющаяся главным компонентом procmon, отображает различные процессы, которые выполняются в системе, эти процессы могут быть упорядочены по критериям пользователя, или на них можно наложить фильтр, условия которого также задаются пользователем. Хотя по умолчанию число процессов, отображаемых в таблице, равно 20, можно изменить это число при помощи панели Table Properties (Свойства Таблицы), доступной из главного меню. Ознакомьтесь с разделом Ресурсы, в котором можно найти полную информацию об этом важном инструментальном средстве.

WLM

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

WLM на AIX включает себя инструменты, которые собирают статистику о производительности и реализуют механизм контроля за распределением ресурсов между процессами. WLM предназначена для использования на больших вычислительных системах, на которых консолидированы различные приложения, например, базы данных и системы обработки транзакций. Данная утилита обеспечивает динамическое распределение ресурсов системы между приложениями без разделения самой системы. WLM помогает предотвратить конфликты между приложениями и распределять ресурсы в зависимости от требований различных групп пользователей. Ее часто путают с Partition Load Manager (PLM), который является менеджером ресурсов, распределяющим их и переназначающим другим процессам основываясь на заданной политике и загруженности ресурсов в системах IBM System p™ с технологией Advanced Power Virtualization. PLM способен управлять памятью, разделами с выделенным процессорами и разделами внутри общего процессора при помощи технологии микроразбиения, которая настраивает использование ресурсов. Таким способом, PLM расширяет возможности технологии микроразделов гипервизора POWER. К сожалению, PLM не может определять приоритет приложений в разделах и поэтому не может менять приоритет в зависимости от изменения типа приложений.

Заключение

Управление процессами - это обязательная, хотя далеко не самая интересная процедура, которую должен выполнять системный администратор UNIX. Он должен при необходимости ускорить процесс и выяснить, почему процесс так медленно выполняется. Системный администратор также должен идентифицировать процессы, которые тормозят систему, и сделать все возможное для улучшения их эффективности. Он также должен правильно выбрать наиболее подходящий инструмент для конкретной задачи, независимо от того, будет ли это просто вызов команды ps и последующее использование renice, новая утилита procmon для контроля производительности или утилита для планирования процессов в масштабах предприятия WLM, которая поможет эффективно управлять всеми системными процессами. Рекомендую изучить подробнее сами концепции выполнения процессов на ядре и их планирования. Прежде чем выполнять какую-то работу, стоит точно выяснить, что нужно сделать.

Ресурсы

Научиться

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

  • 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=281518
ArticleTitle=Приоритет процессов и управление процессами в AIX
publish-date=01112008