Введение

AIX 5L™ версии 5.3 является последней версией ОС AIX®, которая предлагает одновременную многопоточность (simultaneous multi-threading – SMT) на системах eServer™ p5 для обеспечения максимальной пропускной способности и производительности. Благодаря расширенной поддержке виртуализации AIX 5L версии 5.3 помогает повысить эффективность использования сервера и консолидировать приложения для более эффективного управления.

За прошлые годы программисты разработали различные политики планирования использования CPU, в том числе "первым пришел, первым обслужен" (first-in, first-out – FIFO), "самая короткая задача выполняется первой" (shortest job first) и "карусельный" метод (round robin). Одна политика не может подходить для всех приложений, поэтому нужно использовать разные политики. Некоторые приложения при определенных условиях могут хорошо работать с использованием политики планирования по умолчанию, однако в других ситуациях тем же приложениям может потребоваться дополнительная настройка политики планирования для достижения оптимальной производительности.

Примечание. Эта статья является дополнением к документу AIX 5.3 performance. В этой статье не рассматривается расширенная виртуализация . Статья была улучшена и обновлена с акцентом на особенностях AIX 5L версии 5.3, утилитах и возможностях этой ОС.

В начало

Что такое SMT?

SMT – это возможность одного физического процессора одновременно выполнять инструкции от более чем одного аппаратного потока. В AIX 5L версии 5.3 выделенные логические разделы, созданные с одни процессором, конфигурируются по умолчанию как двухпоточные. Два аппаратных потока могут одновременно работать на одном физическом процессоре. SMT будет лучшим выбором, если суммарная производительность важнее, чем скорость выполнения отдельного потока. Например, Web-серверы и серверы баз данных хорошо подходят для использования SMT.

Просмотр информации о процессоре и атрибутах

По умолчанию SMT активизирована, как показано в листинге 1.

# smtctl

This system is SMT capable.

SMT is currently enabled.

SMT threads are bound to the same physical processor.

Proc0 has 2 SMT threads

Bind processor 0 is bound with proc0

Bind processor 2 is bound with proc0

Proc2 has 2 SMT threads

Bind processor 1 is bound with proc2

Bind processor 3 is bound with proc2

# lsattr -El proc0

frequency   1656376000     Processor Speed       False

smt_enabled true           Processor SMT enabled False

smt_threads 2              Processor SMT threads False

state       enable         Processor state       False

type        PowerPC_POWER5 Processor type        False

Команда smtctl предоставляет привилегированным пользователям и приложениям возможность контролировать использование процессоров, которые поддерживают SMT. При помощи этой команды можно включать и выключать SMT . Синтаксис команды smtctl следующий:

smtctl [-m off | on [ -w boot | now] ]

Что такое общие процессоры?

Общие процессоры (shared processors) являются физическими процессорами, которые выделяются логическому разделу в зависимости от кванта времени (интервал времени, выделяемый задаче или процессу в операционных системах с разделением времени). Любой физический процессор можно использовать в общем процессорном пуле для выполнения задач разделов, использующих общий процессорный пул. Система eServer p5 может содержать сочетание общих разделов и выделенных разделов. Раздел должен быть или целиком общий или полностью выделенный, причем нельзя использовать команды динамических LPAR-разделов (DLPAR) для переключения между этими двумя режимами. Чтобы сменить режим использования раздела, надо освободить его от текущих выполняемых задач и сменить режим с выделенного использования на общее использование, или наоборот.

Блок обработки данных

После того как логический раздел был сконфигурирован, можно присвоить ему определенное число так называемых единиц обработки данных (processing units). Раздел должен обладать как минимум одной десятой частью ресурсов процессора. После того как это требование будет удовлетворено, можно настроить число единиц обработки данных с шагом в 1/100 процессора. Раздел, который использует общие процессоры, часто называется общим разделом или разделом для совместного использования. Выделенный раздел – это такой раздел, который единолично использует выделенные процессоры.

Каждый раздел конфигурируется в процентном отношении к потребляемой мощности CPU и кванта времени 10 миллисекунд (мс). Например:

• раздел с числом единиц обработки данных 0.2 будет потреблять 20% вычислительной мощности каждый квант времени;
• раздел с числом единиц обработки данных 1.8 будет занимать 18 мс процессорного времени с каждого 10-миллисекундного кванта времени (при использовании нескольких процессоров).

Неиспользованные циклы вычисления на CPU не накапливаются. Если раздел не использует предоставленные ему мощности процессора, лишнее процессорное время возвращается назад в общий процессорный пул.

Разделы с общими процессорами подразделяются на динамические сегменты (uncapped) и нединамические сегменты (capped). Нединамическому разделу capped установлен жесткий предел допустимой для использования мощности процессора. Если разделу необходимо больше циклов вычисления на CPU (больше, чем отведенное ему число блоков обработки данных), он может использовать невостребованные вычислительные мощности в общем процессорном пуле.

В начало

Алгоритмы планирования

AIX 5 реализует следующие политики планирования: FIFO, round robin, fair round robin. Политика FIFO имеет три различных реализации - FIFO, FIFO2 и FIFO3. Политика round robin в AIX называется SCHED_RR, а fair round robin называется SCHED_OTHER. Далее эти политики будут рассмотрены детально.

Политики планирования могут оказывать решающее влияние на производительность системы в зависимости от того, как их назначать и как управлять ими (время отклика и пропускная способность). Например, FIFO является хорошим выбором для процессов, которые интенсивно используют CPU, но эта политика может также остановить выполнение всех других заданий, поскольку все они будут стоять в очереди. Стандартный "карусельный" round robin метод для каждого задания выделяет "квант времени" ("timeslice"). В результате эта политика "дискриминирует" задачи с интенсивным вводом/выводом, так как эти задачи часто прекращают использование центрального процессора, пока ждут ввода/вывода. Fair round robin является "справедливой" (fair) "карусельной" политикой, поскольку приоритеты в этой политике планирования меняются по ходу накопления задачами, в течение времени их выполнения, квантов времени CPU. Это позволяет операционной системе снижать приоритет задачи, занимающей CPU; поэтому задачи, связанные с вводом/выводом, имеют хорошие шансы использовать CPU.

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

Команды nice и renice

AIX имеет две важные для планирования команды: nice и renice. Пользовательская задача в AIX обладает базовым приоритетом 40 и значением nice по умолчанию 20. Вместе эти два числа формируют уровень приоритета по умолчанию 60. Это значение приоритета применимо к большинству процессов в системе.

При запуске процесса командой nice, например nice -n 10 myjob, число 10 становится значением delta_NICE. Это число добавляется к значению по умолчанию 20 для формирования нового значения nice, равного 30. В AIX чем выше значение nice, тем ниже приоритет. После выполнения команды из примера процесс запустится с приоритетом 70, который на 10 единиц ниже, чем значение приоритета по умолчанию.

Команда renice применяется к процессам, которые уже выполняются. Например, команда renice -n 5 -p 2345 заставляет процесс 2345 поднять значение nice до 25. Заметим, что значение renice всегда добавляется к значению nice по умолчанию 20, а не к текущему значению nice процесса.

Приоритеты в AIX и очередь на выполнение

Значение приоритета потока лежит в диапазоне от 0 до 255 (в диапазоне от 0 до 127 в версиях ранее AIX 5). Приоритет 0 является наивысшим, а 255 – самое низкое значение приоритета. AIX поддерживает очередь выполнения, которая имеет вид очереди с 256 уровнями приоритета для эффективной поддержки 256 уровней приоритета потоков.

AIX также реализует 256-разрядный массив для сопоставления с 256-ю уровнями очереди. Если определенный уровень очереди пуст, соответствующий бит устанавливается в 0. Подобная схема позволяет планировщику AIX быстро идентифицировать первый не пустой уровень и запускать первый готовый процесс на этом уровне. Структура очереди выполнения AIX изображена на рисунке 1.

На рисунке 1 планировщик поддерживает очередь выполнения всех потоков, которые готовы выполняться. Все выполняемые потоки с одним приоритетом занимают последовательные (друг за другом) позиции в очереди выполнения.

AIX 5L реализует одну очередь выполнения для каждого CPU и глобальную очередь выполнения. Например, на сервере eServer pSeries® p590 есть 32 очереди выполнения для каждого процессора и одна глобальная очередь выполнения. В очереди на выполнение для конкретного CPU у потока есть больше шансов после приоритетного прерывания в обслуживании выполняться снова на том же CPU, что называется родственностью процессов. Кроме того, использование нескольких очередей выполнения уменьшает конфликты между CPU из-за блокировки очереди выполнения.

Однако в некоторых ситуациях структура с несколькими очередями выполнения может быть нежелательна. Экспортирование переменной системного окружения RT_GRQ=ON может повлечь за собой перемещение потока в глобальную очередь выполнения, когда она станет доступна. Это может улучшить производительность для потоков, которые управляются прерываниями и схемой планирования SCHED_OTHER. Если выполнить команду schedo -o fixed_pri_global=1 на AIX 5L версии 5.2 и более поздних версиях, потоки с фиксированными приоритетами будут помещены в глобальную очередь выполнения.

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

FIFO

Хотя политика FIFO является простейшей, она редко используется из-за невозможности приоритетного прерывания. Согласно этой политике планирования, поток выполняется непрерывно до конца, только если не произойдет следующее:

• поток добровольно отдает CPU, выполнив функцию, которая заставит его "уснуть", например, sleep() или select();
• поток был блокирован в ходе борьбы за ресурсы;
• поток ждет завершения операций ввода/вывода.

Очередь в продовольственном магазине использует политику FIFO. Вообразите себя в этой очереди с одним обедом быстрого приготовления, в то время как корзинка впереди стоящего человека забита продуктами. Что можно сделать в такой ситуации? Не так много. Так как это FIFO, необходимо набраться терпения и дождаться своей очереди.

Точно так же, если несколько процессов выполняются в режиме FIFO в AIX, очевидно, что время ответа процесса может значительно растянуться. В результате FIFO редко используется в AIX. Только процесс, принадлежащий пользователю root, может поменять свою (или другого процесса) политику на FIFO при помощи системного вызова thread_setsched().

Существуют две разновидности политики FIFO: FIFO2 и FIFO3. В FIFO2 говорится, что поток помещается в начало списка только в том случае, если его время простоя было меньше, чем заданное число системных тактов (значение affinity_lim ticks, настраиваемое при помощи команды schedo -p). Это дает потоку хорошие шансы повторно использовать содержимое кэша. Для FIFO3 поток, когда он становится работоспособным, всегда помещается во главу очереди.

Round robin

Хорошо известная "карусельная" политика планирования или round robin даже старше, чем сам UNIX". AIX 5L реализует политику round robin поверх своей приоритетной очереди из 256 уровней. На заданном уровне приоритета поток, реализующий политику round robin, совместно с другими потоками такого же приоритета использует кванты времени на выполнение в CPU. Поток будет выполняться, если только не произойдет одно из следующих событий:

• поток уступит CPU другим потокам;
• поток будет ожидать завершения операций ввода/вывода;
• поток израсходует свои кванты времени.

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

При политике round robin прерванный поток помещается в начало своей очереди на выполнение, потому что AIX перед тем как поместить поток в конец очереди, хочет удостовериться, что данный поток израсходовал все свои кванты времени. Важно отметить, что приоритет потока, реализующего политику round robin, фиксирован и не меняется с течением времени. Поэтому приоритет потока в round robin является постоянным (в отличие от изменения приоритетов в fair round robin) и более предсказуемым.

Так как поток (с политикой round robin) имеет специальный статус, только пользователь root может настроить поток на выполнение согласно политике планирования round robin. Для задания SCHED_RR можно использовать следующие интерфейсы программирования приложений (API): thread_setsched() или setpri().

SCHED_OTHER

Эта последняя политика планирования также является и политикой по умолчанию. Алгоритм SCHED_OTHER (имя, определенное стандартом POSIX™) был разработан в ходе попыток создать самую справедливую политику планирования. В AIX SCHED_OTHER имеет в своей основе схему с очередью приоритетов с использованием round robin, но с одним большим отличием от round robin – приоритет потока не является фиксированным. Если процесс использует чрезмерное количество времени CPU, то его приоритет понижается, чтобы дать другим процессам возможность получить доступ к CPU.

Если задача имеет такой низкий уровень приоритета (большое число), что нет возможности выполнения ее на CPU, то ее приоритет поднимается (маленькое число) до такого уровня, чтобы она могла завершить свое выполнение. Новая концепция была также реализована для дальнейшего увеличения эффективности значения nice: если приоритет задачи (значение nice) был изначально равен значению по умолчанию, система будет держать его таким все время. Эта особенность будет рассмотрена позже.

Традиционные критерии использования CPU

До AIX 5.3 или с отключенным SMT в AIX для оценки степени использования CPU использовались следующие подходы, основанные на получении выборок данных:

• процент процессорного времени, потраченного на выполнение пользовательских программ;
• системный код;
• ожидание дискового ввода/вывода;
• время простоя.

AIX выполняет 100 прерываний в секунду для сбора данных. На каждом прерывании вновь прерванному таймером процессу задается значение системного таймера 10 мс. Затем, основываясь на состоянии прерванного потока, выбирается один из видов использования:

• если поток выполнял код в ядре, используя системный вызов, квант времени на работу с CPU целиком добавляется к системному времени процесса;
• если поток выполнял приложение, квант времени на работу с CPU целиком добавляется к пользовательскому времени процесса. В противном случае, если текущий выполняемый поток был простаивающим процессом операционной системы, тик времени заменяется на отдельную переменную. Проблема с этим методом заключается в следующем: процесс, который получил квант процессорного времени, не выполнялся в течение всего отведенного ему времени и, возможно, начал работу, когда отведенное для него время уже истекло. С включенным SMT на AIX 5.3 традиционные показатели использования работают некорректно из-за двух логических процессоров;
• если один поток загружен на 100%, то один простаивающий поток будет показывать 50% загрузки. Но в действительности, если один SMT-поток будет использовать все ресурсы CPU, то этот CPU будет загружен на 100%, как это выводится методом, основанным на PURR (Processor Utilization Resource Register – регистр степени использования ресурсов процессора).

PURR

Начиная с AIX 5.3, число циклов выполнения для каждого потока может измеряться при помощи нового регистра PURR. Каждый физический процессор имеет два PURR-регистра (по одному на каждый аппаратный поток). PURR является новым регистром, предоставляемым процессором POWER5, который используется для предоставления реального времени выполнения на физическом процессоре, которые использовал логический процессор. Все инструменты для увеличения производительности и API используют это значение PURR для предоставления отчета о показателях использования CPU для SMT-систем. Этот регистр является регистром специального назначения, чтение или запись в него может осуществляться посредством гипервизора POWER™ Hypervisor™, а операционная система может только читать этот регистр. Аппаратное приращение PURR основано на том, как каждый поток использует ресурсы процессора, включая циклы выполнения, которые выделены каждому потоку. В том случае, если по ходу цикла выполнения не было выполнено никаких инструкций, регистр PURR потока, который последним выполнял какую-либо команду, увеличивается. Регистр работает автоматически, поэтому операционная система всегда будет обладать своевременной информацией.

Когда процессор работает в однопоточном режиме, PURR увеличивается на единицу каждые восемь тактовых циклов выполнения процессора. Когда процессор работает в режиме SMT, поток, который выполняет группу инструкций в течение одного цикла, увеличивает счетчик PURR на 1/8 за этот цикл. Если никаких действий в этом цикле не выполняется, то оба потока увеличивают свои значения PURR на 1/16. В течение некоторого периода времени сумма двух регистров PURR, при работе в режиме SMT, должна быть очень близкой, но не больше числа выделенных квантов времени.

Использование CPU в AIX 5.3

В AIX 5L V5.3 есть новые показатели использования CPU, собирающиеся ядром, которые основаны скорее на состояниях, нежели на подходе с выборками данных. Подход с состояниями состоит из сбора информации, основанном на увеличении значения регистра PURR, а не на сборе информации через временной интервал 10 мс. AIX 5.3 использует PURR для ведения учета по процессам. Вместо того, чтобы прерывать процессы каждые 10 мс, как было ранее, выполняется учет приращения регистра PURR (PURR delta) аппаратного потока за каждый интервал времени. На каждом прерывании:

• для текущего интервала вычисляется накопившееся значение PURR;
• это значение добавляется к подходящему виду использования (user, sys, iowait и idle) вместо фиксированного приращения (10 мс), которое добавлялось в другом, предыдущем способе.

Существуют два разных способа для измерения: время выполнения потока на процессоре и истекшее время. Для измерения истекшего времени по-прежнему применяется регистр с временным критерием (time-based register – TB). Показатели использования физических ресурсов для логического процессора следующие:

• (delta PURR/delta TB) отражает долю физического процессора, используемую логическим процессором;
• (delta PURR/delta TB) * 100 – это процентное соотношение циклов выполнения к выбранному логическому процессору на всем интервале времени.

Пример использования CPU

Предположим, что два потока выполняются на одном физическом процессоре с включенным режимом SMT. Оба SMT-потока на физическом CPU загружены. При использовании старого метода, основанного на посылке сигналов через равные промежутки времени, оба SMT-потока будут сообщать о 100%-ной загрузке, но в действительности они поровну делят ресурсы одного CPU. Это значит, что новый метод, основанный на регистрах PURR, покажет, что каждый SMT-поток загружен на 50%.

Используя методы, связанные с PURR, каждый логический процессор докладывает о своей 50%-ной загрузке, отражая долю физического процессора, которую этот логический процессор использует; это при условии одинакового распределения ресурсов физического процессора на оба аппаратных потока.

Дополнительные показатели использования CPU

В таблице 1 приведены показатели, которые используют метод PURR для измерения процессорного времени потока и используют регистр TB для измерения прошедшего времени выполнения потока.

В начало

Изменения в командах для AIX 5.3

Когда AIX работает с активизированным SMT, команды, которые отображают информацию о CPU, такие как vmstat, iostat, topas и sar, отобразят статистическую информацию, связанную с PURR, а не с традиционным методом измерений через временные интервалы. В режиме SMT появятся дополнительные колонки с информацией, как показано в таблице 2.

Другим инструментом, который нуждался в модификации, был trace/trcrpt и несколько других инструментов, которые основаны на утилите trace. В среде SMT trace может выборочно собирать значения регистров PURR в каждой точке контроля параметров, и trcrpt может отобразить накопившиеся значение PURR.

Таблица 3 показывает аргументы, которые следует использовать для режима SMT.

В начало

Формулы для вычисления приоритетов потоков

Вычислить приоритеты потоков можно при помощи формул, показанных в листинге 2. Эти формулы являются функциями от значения nice, показателя использования CPU c и коэффициента настройки r.

В начало

Как AIX вычисляет новый приоритет

Прерывания по таймеру происходят каждые 10 мс или один такт системных часов на каждом CPU. Таймеры отрегулированы так, чтобы прерывание одного CPU не случилось одновременно с прерыванием другого CPU. Когда по сигналу таймера происходит прерывание работы CPU (даже если до этого поток отработал все 10 мс), поток, использовавший CPU, увеличивает свое значение показателя использования CPU на один, вплоть до максимума 120. Если поток не израсходовал полностью интервал 10 мс и выполнялся согласно политике планирования RR, то диспетчер системы меняет приоритет потока в очереди выполнения, чтобы поток вскоре смог снова начать выполняться.

Приоритет большинства пользовательских процессов меняется согласно количеству времени работы на CPU, которое поток использовал в последнее время. Вычисления планировщика приоритетов CPU основаны на следующих двух параметрах, которые задаются при помощи schedo – sched_R и sched_D. Значения sched_R и sched_D измеряются в 1/32 секунды. Планировщик использует эту формулу для вычисления величины, которую надо добавить к величине приоритета процесса в качестве штрафа (CPU penalty) за последнее использование CPU. Например:

штраф CPU = (значение последнего показателя использования CPU для процесса) * (r/32)

Повторное вычисление (один раз в секунду) показателя использования CPU для каждого процесса:

Новое значение последнего показателя использования CPU = 
(старое значение последнего показателя использования CPU процессом)
 * (d/32)

Оба параметра: r (sched_R) и d (sched_D) имеют значение по умолчанию 16.

Значение последнего показателя использования CPU (CPU charge) С впоследствии используется, чтобы определить штраф для приоритета и пересчитать новое значение приоритета. Используя первую формулу в качестве справки (см. листинг 2), можно сказать, что новый пользовательский процесс, базовое значение приоритета которого равно 40, значение по умолчанию nice равняется 20 и значение показателя использования CPU равняется 0, начинает свое выполнение с уровнем приоритета 60.

Также в первой формуле значение r определяет степень штрафа, лежащую в диапазоне от 0 до 32. Значение r , равное нулю, означает, что отсутствует штраф по использованию CPU, так как данное выражение -- C*r/32 -- будет всегда равняться нулю. Если r=32, штраф использования CPU будет максимальным – каждые 10 мс использования CPU процессом приведут к падению его приоритета на один уровень.

В большинстве случаев значение r лежит близко к середине между 0 и 32. В AIX значение r по умолчанию равняется 16; поэтому использование CPU в течение двух тактов системных часов приводит к штрафу в виде падения приоритета процесса на один уровень. Если значение r высокое, влияние значения nice становится менее важным, поскольку преобладает штраф CPU. И наоборот, маленькое r заметно увеличивает влияние nice.

Подытожив приведенные выше рассуждения, можно сказать, что влияние значения nice падает с течением времени. Причина этого в том, что загрузка CPU со времени растет и мало-помалу становится основным фактором в определении нового приоритета.

Эта формула была модифицирована в AIX 5L для увеличения влияния значения nice в вычислении уровня приоритета. Во всех различных версиях AIX были введены два новых фактора: x_nice и x_nice_factor ("extra nice" и "extra nice factor"). Давайте рассмотрим следующую формулу в листинге 2.

<формула 1 : базовая формула>
Priority = p_nice + (C * r/32)                 (1)

<формула 2 : для AIX 5L>
Priority = x_nice + (C * r/32 * x_nice_factor) (2)
где:
   p_nice = base_PRIORITY + NICE
      base_PRIORITY = 40
      NICE = 20 + delta_NICE
      (20 – это значение nice по умолчанию)
      это значит,
   P_nice = 60 + delta_NICE

   C – показатель использования CPU
      максимальное значение C - 120
   Если NICE <= 20 тогда x_nice = p_nice
   Если NICE > 20 тогда
   x_nice = p_nice * 2 - 60 или
   x_nice = p_nice + delta_NICE, или         (3)
   x_nice = 60 + (2 * delta_NICE)           (3a)
   x_nice_factor = (x_nice + 4)/64          (4)
   приоритет имеет максимальное значение

Как можно видеть из формул 2 и 3, x_nice удвоил возросшее значение nice. x_nice_factor усилил коэффициент r. Например, начальное значение nice, равное 16, даст значение nice в 36, что приведет к новому значению коэффициента x_nice_factor, равному 1.5. Это значение означает 50%-ный штраф использования CPU, накопившегося за весь жизненный цикл потока, в течение которого он использовал CPU.

Уменьшение показателя использования CPU

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

Когда потоки выполняются согласно политике SCHED_OTHER, по ходу выполнения на CPU приоритет этих потоков падает. Когда поток ждет своей очереди на выполнение, AIX пытается увеличить его приоритет, уменьшая один раз в секунду его показатель использования CPU. Правило простое: процессу, использующему только CPU, должен быть присвоен более низкий приоритет, чтобы другие процессы могли выполняться, но нельзя предвзято относиться к процессу и не давать ему возможности закончить свое выполнение. Показатели использования CPU (CPU сharge) всех потоков уменьшаются на основании предопределенного коэффициента один раз в секунду, как показано ниже:

New Charge C = (Old Charge C) * d / 32              (5)

Это работу выполняет процесс ядра swapper. Каждую секунду swapper "просыпается" и уменьшает значение показателя использования CPU всем потокам. По умолчанию коэффициент уменьшения равняются 0.5 или d=16, что наполовину уменьшает показатель использования CPU.

При помощи этого механизма процессы, интенсивно использующие CPU, увеличивают значение своего показателя использования CPU, что приводит к уменьшению их приоритета, а затем один раз в секунду уровень приоритета поднимается. С другой стороны, у интенсивных процессов ввода/вывода значение приоритета сильно не меняется, так как они не интенсивно используют время CPU.

В начало

Контроль потребления ресурсов CPU

Теперь, после того, как был рассмотрен механизм расстановки приоритетов планировщиком AIX, давайте взглянем на несколько наиболее часто используемых команд. Если кажется, что AIX слишком долго выполняет задачу или медленно реагирует на запросы, следует использовать эти команды, чтобы проверить, имеет ли место ограничение в возможностях CPU: vmstat, iostat и sar.

В статье не будут рассмотрены все возможные способы использования этих команд, а акцент делается на информации, которую предоставляют эти команды. Для детального описания этих команд следует изучить другие публикации по AIX или посетить Web-сайт AIX по этому адресу. Если это необходимо, то перейдите в конец документа к ресурсу AIX Version 5L Version 5.3 documentation library, где дан список публикаций по AIX 5.

История изменения приоритета для потока

В листинге 3 показано, как показатель использования CPU может изменить приоритет потока:

базовый приоритет - 40
значение NICE по умолчанию - 20,
и предположим, что задача была запущена со значением nice по умолчанию
p_nice = base_priority + NICE = 40 + 20 = 60
предположим, что r=2, чтобы снизить шаг увеличения штрафа (значение r по умолчанию - 16)
приоритет: P = p_nice + C*r/32 = 60 + C * r / 32
цикл 0 P = 60 + 0 * 2 / 32 = 60
цикл 1 P = 60 + 1 * 2 / 32 = 60
цикл 2 P = 60 + 2 * 2 / 32 = 60
+.
цикл 15 P = 60 + 15 * 2 / 32 = 60
цикл 16 P = 60 + 16 * 2 / 32 = 61
цикл 17 P = 60 + 17 * 2 / 32 = 61
+.
+.
цикл 100 P = 60 + 100 * 2 / 32 = 66
цикл 100 процессор Swapper снижает степень использования CPU для всех потоков.
новое значение C CPU Charge = (текущее значение CPU Charge) * d / 32
предположим, что d = 16 (значение по умолчанию)
для тестового потока новое значение C = 100 * 16 / 32 = 50

цикл 101 P = 60 + 51 * 2 / 32 = 63

В листинге 4 показано, как установить высокий или низкий приоритет.

fast.c:
main(){for (;;)}

slow.c:
main() {sleep 80;}

В начало

Распространенные команды

Команды vmstat, iostat и sar часто используются для мониторинга CPU. Читатель должен иметь представление о том, как использовать эти команды и уметь интерпретировать отчеты, которые генерирует каждая команда.

vmstat

Команда vmstat предоставляет обзор потребления ресурсов системы посредством предоставления отчетов об активности использования CPU, жесткого диска и памяти в формате "один отчет на одну строку". Пример вывода, показанный в листинге 5, сгенерирован в AIX 5L версии 5.3 командой "vmstat 1 6". Этот отчет генерируется каждую секунду, как и было указано в запросе. После вывода шестого отчета генерация отчетов прекращается, как было указано в команде. Популярный способ выполнения команды vmstat состоит в том, чтобы не вводить параметр числа отчетов; vmstat будет генерировать отчеты до тех пор, пока его не завершат.

Исключая колонки avm и fre, первый отчет содержит усредненную статистику каждой секунды работы системы после ее запуска. Более поздние отчеты содержат статистические данные, собранные за интервал времени, прошедший с момента генерации предыдущего отчета.

Начиная с AIX 5L версии 5.3, команда vmstat выводит отчет о числе используемых физических процессоров (pc) и процент от потребления допустимых мощностей CPU (entitlement) (ec) в микроразделах™ и SMT-средах.Эти показатели отображаются только для сред микроразделов и SMT.

AIX 5L предоставляет новую полезную опцию "-I" для vmstat, которая показывает число потоков, ожидающих завершения неформатированного ввода/вывода (raw I/O) (колонка p) и число файлов страниц, подкачанных в оперативную память и выгруженных из оперативной памяти в секунду (колонки fi/fo).

Следующее детальное описание колонок предоставит очень полезную информацию об использовании CPU. Листинг 5 показывает вывод команды vmstat 1 6:

vmstat 1 6 
System configuration: lcpu=4 mem=15808MB  
kthr   memory     page     faults      cpu 
-----  -------    ------   --------    ----------- 
r b avm    fre    re  pi  po  fr  sr  cy  in   sy   cs  us sy id wa 
1 1 110996 763741 0   0   0   0    0   0 231   96   91  0  0  99  0 
0 0 111002 763734 0   0   0   0    0   0 332 2365  179  0  1  99  0 
0 0 111002 763734 0   0   0   0    0   0 330 2283  139  0  5  93  1 
0 0 111002 763734 0   0   0   0    0   0 310 2212  153  0  0  99  0 
1 0 111002 763734 0   0   0   0    0   0 314 2259  173  0  0  99  0 
0 0 111002 763734 0   0   0   0    0   0 321 2261  177  0  1  99  0

Рисунок 2 показывает результат работы команды vmstat -I 1 (результат получен во время установки программного обеспечения):

Таблица 4 содержит список столбцов с описанием каждого.

Если CPU простаивает и на нем был запущен простаивающий процесс ввода/вывода, то этот CPU маркируется как wio каждый раз во время прерывания по таймеру (каждые 1/100 мс). Если CPU простаивает без наличия невыполненных процессов ввода/вывода, то он маркируется как id вместо wa. Например, для системы с четырьмя CPU и одним потоком, выполняющим ввод/вывод, будет выведен отчет о максимум 25% времени wio. Для системы с 12 CPU и одним потоком, делающим запросы ввода/вывода, будет выведено максимум 8.3% времени wio. Для большей определенности wio измеряет процент времени, в течение которого CPU простаивает в ожидании завершения процесса ввода/вывода.

Эти четыре колонки в сумме должны давать 100% (или очень близко к этому значению). Если сумма процентных оценок использования CPU пользователем (user) и системой (system) (us и sy) близка к 100%, возможно, что в системе возникло "узкое место" в центральном процессоре.

iostat

Команда iostat используется для мониторинга систем ввода/вывода, но она также может предоставлять информацию об использовании центрального процессора. Начиная с AIX 5.3, команда iostat предоставляет информацию о числе используемых физических процессоров (physc) и о проценте потребляемой доступной мощности (% entc) в средах с микро-разделами и SMT-средах. Эти показатели отображаются только в средах с SMT и микро-разделами. Когда SMT активизирован, iostat автоматически использует данные регистра PURR и связанные с ним формулы для:

• %user
• %sys
• %wait
• %idle

Листинг 6 создан на системе AIX 5L версии 5.3 при помощи команды "iostat 5 3".

System configuration: lcpu=4 drives=9

tty: tin tout avq-cpu: %user %sys %idle %iowait
     0.0 4.3        0.2   0.6  98.8   0.4
Disks: %tm_act Kbps tps      Kb_read Kb_wrtn
hdisk0   0.0   0.2  0.0       7993    4408
hdisk1   0.0   0.0  0.0       2179    1692
hdisk2   0.4   1.5  0.3      67548   59151
cd0      0.0   0.0  0.0          0       0
tty: tin tout cpu: %user %sys %idle %iowait
     0.0 30.3       8.8   7.2  83.9    0.2
Disks: %tm_act Kbps tps      Kb_read Kb_wrtn
hdisk0   0.2   0.8  0.2          4       0
hdisk1   0.0   0.0  0.0          0       0
hdisk2   0.0   0.0  0.0          0       0
cd0      0.0   0.0  0.0          0       0
tty: tin tout cpu: %user %sys %idle %iowait
     0.0 8.4        0.2   5.8   0.0   93.8
Disks: %tm_act Kbps tps      Kb_read Kb_wrtn
hdisk0   0.0   0.0  0.0          0       0
hdisk1   0.0   0.0  0.0          0       0
hdisk2  98.4  75.6 61.9        396    2488
cd0      0.0   0.0  0.0          0       0

Example iostat with SPLAR configuration
#iostat –t 2 3
System Configuration: lcpu=4 ent=0.80
avg-cpu   %user   %sys    %idle     %iowait   physc     %entc
           0.1     0.2     99.7       0.0      0.0       0.9
           0.1     0.4     99.5       0.0      0.0       1.1
           0.1     0.2     99.7       0.0      0.0       0.9

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

Четыре колонки, которые делят время использования CPU на категории, предоставляют ту же информацию, что и аналогичные колонки в команде vmstat. Общая сумма этих колонок должна быть примерно равна 100%. Если сумма процентного использования ресурсов пользователем (user) и системой (system) (us и sy) приближается к 100%, то, возможно, в системе возникло "узкое место" в центральном процессоре.

На системах, выполняющих одно приложение, высокий процент ожидания ввода/вывода может быть отнесен к рабочей нагрузке. На системах с множеством процессов некоторые из процессов будут работать, тогда как другие будут ждать ввода/вывода. В этом случае, значение %iowait может быть маленьким или равным нулю, поскольку выполняющиеся процессы "скрадывают" некоторое количество времени ожидания. Хотя значение %iowait является низким, этот критический параметр все же может ограничивать производительность приложения. Если команда iostat указывает, что ситуации, связанной с ограниченными возможностями процессора, не существует, а значение времени %iowait больше 20%, то, возможно, проблема в подсистеме ввода/вывода или дисковой подсистеме.

sar

Команда sar имеет два варианта – первый производит выборку образцов, отображает и/или сохраняет статистику системы, а второй - обрабатывает и отображает предварительно собранные данные. Команда sar может предоставить статистику по очереди выполнения и процессору так же, как команды vmstat и iostat. Однако у этой команды есть две особенности:

• каждый набор данных имеет свою временную метку (т. е. данные соответствуют только одному моменту работы системы), поэтому общие усредненные статистические данные появятся после окончания выборки образцов;
  
  
• в дополнение к усредненным статистическим значениям по всем процессорам можно использовать опцию -P для формирования статистических данных об отдельных процессорах. Листинг 7 показывает результат работы утилиты sar для четырехканальной SMT-системы, который получен при помощи двух команд:

• sar -o savefile 5 3 > /dev/null &

  
  Примечание: эта команда собирает данные 3 раза с пятисекундным интервалом, сохраняет собранные данные в savefile и перенаправляет отчет в "черную дыру", таким образом, на терминал ничего не будет выведено.

• sar -P ALL -u -f savefile

  
  Примечание: параметр -P ALL предназначен для сбора статистических данных о каждом отдельном процессоре и -u для сбора данных об использовании CPU. В дополнение, -f savefile указывает sar сформировать отчет, используя данные, сохраненные в savefile. Вывод sar -P All для всех логических процессоров с активизированным режимом SMT показывает потребление физического процессора physc (delta PURR/delta TB). Эта колонка показывает сравнительное разделение SMT между процессорами, другими словами, она иллюстрирует часть времени, в течение которого логический процессор пользовался вычислительными циклами физического процессора. Всякий раз, когда количество потребляемой доступной мощности меньше 100%, для предоставления неиспользуемой мощности добавляется строка, начинающаяся с U. При работе в совместном режиме sar отображает процент использования выделенной мощности %entc, который вычисляется по формуле ((PPC/ENT)*100).

AIX nutmeg 3 5 00CD241F4C00    06/14/05
 
System configuration: lcpu=4
 
11:51:33 cpu    %usr    %sys    %wio   %idle   physc
11:51:34  0        0       0       0     100    0.30
          1        1       1       1      98    0.69
          2        2       1       0      96    0.69
          3        0       0       0     100    0.31
          -        1       1       0      98    1.99
11:51:35  0        0       0       0     100    0.31
          1        0       0       0     100    0.69
          2        0       0       0     100    0.73
          3        0       0       0     100    0.31
          -        0       0       0     100    2.04
11:51:36  0        0       0       0     100    0.31
          1        0       0       0     100    0.69
          2        0       0       0     100    0.70
          3        0       0       0     100    0.31
          -        0       0       0     100    2.01
11:51:37  0        0       0       0     100    0.31
          1        0       0       0     100    0.69
          2        0       0       0     100    0.69
          3        0       0       0     100    0.31
          -        0       0       0     100    2.00
 
Average   0        0       0       0     100    0.31
          1        0       0       0      99    0.69
          2        1       0       0      99    0.70
          3        0       0       0     100    0.31
          -        0       0       0      99    2.01

mpstat

Команда mpstat собирает и отображает статистику производительности для всех логических CPU в системе. Если активизирован режим SMT, команда mpstat -s отображает использование как физических, так и логических процессоров, как показано в листинге 8.

System configuration: lcpu=4
 
Proc0           Proc1
63.65%          63.65%
 
cpu2    cpu0    cpu1    cpu3
58.15%   5.50%  61.43%   2.22%

lparstat

Команда lparstat предоставляет информацию, связанную с LPAR-разделами и статистикой использования. Эта команда выводит текущие параметры LPAR-раздела, информацию о гипервизоре и статистику использования LPAR-раздела. Механизм сбора данных выводит определенное число отчетов за определенный интервал времени (листинг 9).

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

Следующие статистические данные отображаются только в том случае, если установлен флаг -h:

System configuration: type=Dedicated mode=Capped smt=On lcpu=4 mem=15808
 
%user  %sys  %wait  %idle
-----  ----  -----  -----
  0.0   0.1    0.0   99.9
  0.0   0.1    0.0   99.9
  0.4   0.2    0.1   99.3
 
# lparstat 1 3
 
System configuration: type=Shared mode=Uncapped smt=On lcpu=2 mem=2560 ent=0.50
 
%user  %sys  %wait  %idle physc %entc  lbusy   app  vcsw phint
-----  ----  -----  ----- ----- ----- ------   ---  ---- -----
  0.3   0.4    0.0   99.3  0.01   1.1    0.0     -   346     0
 43.2   6.9    0.0   49.9  0.29  58.4   12.7     -   389     0
  0.1   0.4    0.0   99.5  0.00   0.9    0.0     -   312     0

В начало

Улучшение производительности системы

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

Изменение приоритетов пользовательских процессов

В команды для изменения или настройки приоритетов пользовательских процессов входят команды nice и renice и два системных вызова, которые позволяют менять приоритеты потоков и политики планирования посредством API-вызовов.

Применение команды nice

При запуске процесса из оболочек ksh или csh, стандартное значение nice процесса, выполняющегося на переднем плане, равняется 20; стандартное значение nice для фонового процесса равняется 24 (или 20, если запуск приложения был выполнен из оболочек tcsh и bsh). Система использует значение nice для вычисления приоритета всех потоков, ассоциированных с процессом. Используя команду nice, пользователь может задать приращение или уменьшение стандартного значения nice таким образом, что процесс будет запущен с приоритетом, отличным от приоритета по умолчанию. Приоритет потока пока что не зафиксирован и меняет свое значение в зависимости от степени использования CPU потоком.

Используя nice, любой пользователь может запустить программу с более низким приоритетом, чем значение по умолчанию. Только администратор может использовать nice для запуска команд с приоритетом выше, чем по умолчанию. Например, команда nice -5 iostat 10 3 >iostat.out принуждает запуститься команду iostat со значением nice равным 25 (вместо 20), т.е. с более низким уровнем приоритета. Значения nice и приоритета могут быть получены при помощи команды ps с флагом -l. В листинге 10 приведен обычный вывод команды ps -l:

       F S UID   PID  PPID   C PRI NI ADDR    SZ    WCHAN    TTY  TIME CMD
  240001 A   0 15396  5746   1  60 20 393ce   732           pts/3  0:00 ksh
  200001 A   0 15810 15396   3  70 25 793fe   524           pts/3  0:00 iostat

Администратор может запустить iostat на самом высоком уровне приоритета командой # nice --5 vmstat 10 3 >io.out. Команда iostat запустится с более высоким уровнем приоритета.

Использование команды renice

Если процесс уже выполняется, можно использовать команду renice для изменения значения nice, и, следовательно, приоритета. Процессы идентифицируются по своему идентификационному номеру (process ID), идентификационному номеру группы-владельца процесса (process group ID), по имени пользователя, который владеет процессом. Команда renice не может применяться для процессов с фиксированным приоритетом.

Использование процедур setpri() и thread_setsched()

Существуют два системных вызова, которые позволяют пользователям планировать выполнение отдельных процессов или потоков с фиксированным приоритетом. Системный вызов setpri() является процессно-ориентированным, системный вызов thread_setsched() является поточно-ориентированным. Эти системные вызовы надо использовать с осторожностью, поскольку неправильное их применение может привести к зависанию системы.

Приложение, которое запустил пользователь root, может самостоятельно осуществить вызов процедуры setpri() для установки собственного приоритета или приоритета другого процесса. Выполнение целевого процесса осуществляется согласно политике планирования SCHED_RR с фиксированным приоритетом. Изменение применяется ко всем потокам в процессе. Отметим два следующих примера:

retcode = setpri(0, 45);

Присваивает процессу, который выполнил вызов, фиксированный приоритет 45.

retcode = setpri(1234, 35);

Присваивает процессу с PID, равным 1234, фиксированный приоритет 35.

Если изменение приоритета предназначено для определенного потока, можно использовать процедуру thread_setsched():

retcode = thread_setsched(thread_id,priority_value, scheduling_policy)

Параметр scheduling_policy принимает одно из следующих значений:

SCHED_OTHER, SCHED_FIFO, or SCHED_RR.

Если в первом параметре значением политики планирования выбрано значение SCHED_OTHER, то второй параметр (priority_value) игнорируется.

Глобальное изменение алгоритма планирования

AIX позволяет пользователям сделать изменения в формуле вычисления приоритета при помощи команды schedo.

Подбор значений r и d

Как упоминалось ранее, формула для вычисления значения приоритета следующая:

Priority = x_nice + (C * r/32 * x_nice_factor)

Показатель интенсивности последнего использования CPU (recent CPU usage) отображается в колонке C в выводе команды ps. Максимальное значение этого показателя равняется 120. Каждую секунду значение показателя использования CPU (Charge C) для каждого потока уменьшается по следующей формуле:

New Charge C = (Old Charge C) * d / 32

Значение r по умолчанию равняется 16; следовательно, штраф к приоритету потока будет recent CPU usage * 0.5. Значение d также по умолчанию равняется 16, что означает, что значение показателя последнего использования CPU (recent CPU usage) каждого процесса каждую секунду уменьшается на половину от своего исходного значения. Для некоторых пользователей значения по умолчанию sched_R и sched_D не имеют достаточных различий между приоритетными и фоновыми процессами. Эти два значения могут быть настроены при помощи параметров sched_R и sched_D, применяемых с командой schedo. Рассмотрим два примера:

• # schedo -o sched_R=0

  
  
  (R=0, D=.5) указывает на то, что штраф за использование CPU всегда был нулевым. Значение приоритета для этого процесса будет эффективно зафиксировано, но этот процесс не будет обрабатываться так же, как процесс с политикой планирования RR.
  
  

• # schedo -o sched_D=32

  
  
  (R=0.5, D=1) указывает на то, что процесс, выполняющийся длительное время, достигнет значения C в 120 и так и останется с этим значением дальше. Показатель последнего использования CPU (С) не будет уменьшаться каждую секунду, и приоритет длительно выполняющихся процессов не станет вновь высоким для соперничества за ресурсы CPU с новыми процессами.

Изменение временного интервала

Хотя команда schedo может модифицировать длину временного интервала планировщика, изменить временной интервал можно только для потоков, реализующих политику планирования RR. Команда для изменения временного интервала не будет работать с потоками, реализующими другие политики планирования. Синтаксис этой команды следующий:

schedo -L timeslice

n – это число системных тактов в 10 мс, которые будут использоваться в качестве временного интервала. Команда schedo -p -o timeslice=2 задаст длину временного интервала в 20 мс.

Для того чтобы вносить изменения посредством команды schedo, надо войти с учетной записью root.

В начало

Другие приемы

Другие приемы, которые могут помочь системе с ограниченными ресурсами CPU, заключаются в следующем.

Планирование

В зависимости от сравнительной важности приложений можно сделать так, чтобы менее важные приложения выполнялись во внерабочее время, используя команды at, cron или batch.

Использование команды mkpasswd

Если в системе имеются тысячи записей в файле /etc/passwd, можно использовать команду mkpasswd для создания хешированной или проиндексированной версии файла /etc/passwd, что приведет к уменьшению времени CPU, потраченного на поиск идентификатора пользователя.

В начало

Настройка отдельных приложений

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

Применение команды ps

Команда ps или профайлер (profiler) может определить приложение, которое использует много процессорного времени. Эта информация может потом использоваться для ускорения "узкого места" в CPU. После того как причина проблемы будет обнаружена, можно настроить или улучшить приложение. Возможно, придется перекомпилировать приложение или внести изменения в исходный код.

Использование команды schedo.

Команда schedo используется для настройки или отображения текущих значений параметров планировщика CPU или значений, которые будут применены при следующей загрузке. Эта команда может быть выполнена только пользователем root. Команда schedo также может внести постоянные изменения в работу планировщика или отложить внесение этих изменений до следующей перезагрузки. Начиная с AIX 5L версии 5.3, в команду schedo было добавлено несколько параметров настройки. В листинге 11 показаны все параметры планировщика CPU.

# schedo -a
              %usDelta = 100
          affinity_lim = 7
         big_tick_size = 1
      fixed_pri_global = 0
             force_grq = 0
       hotlocks_enable = 0
idle_migration_barrier = 4
    krlock_confer2self = n/a
  krlock_conferb4alloc = n/a
         krlock_enable = n/a
    krlock_spinb4alloc = n/a
   krlock_spinb4confer = n/a
               maxspin = 16384
    n_idle_loop_vlopri = 100
              pacefork = 10
               sched_D = 16
               sched_R = 16
 search_globalrq_mload = 256
  search_smtrunq_mload = 256
  setnewrq_sidle_mload = 384
   shed_primrunq_mload = 64
    sidle_S1runq_mload = 64
    sidle_S2runq_mload = 134
    sidle_S3runq_mload = 134
    sidle_S4runq_mload = 4294967040
    slock_spinb4confer = 1024
      smt_snooze_delay = 0
     smtrunq_load_diff = 2
             timeslice = 1
        unboost_inflih = 1
         v_exempt_secs = 2
         v_min_process = 2
           v_repage_hi = 0
         v_repage_proc = 4
            v_sec_wait = 1

Обновление аппаратного обеспечения

Если настройка различных параметров не улучшила производительности, возможно, необходима замена процессоров системы на более мощные или установка дополнительных процессоров.

В начало

Примеры из практики

Два примера показывают, как эксперты по производительности компании IBM реализовали на практике эти теории и методики.

Пример 1

Симптомы: У пользователя имелся пакетный сценарий, который запускал 500 других пакетных сценариев, и каждый из этих сценариев запрашивал и обновлял базу данных. Каждый сценарий также начинался в виде клиентского запроса с другого компьютера. Каждый клиентский запрос создавал пользовательский поток базы данных на компьютере сервера базы данных. Время ответа сначала было меньше 10 секунд, однако затем время ответа становилось все больше. Временами оно было больше минуты, иногда больше двух минут.

Диагностика: Очередь выполнения разрасталась до сотен процессов. Другим симптомом было то, что CPU использовался на 100% (это была восьмипроцессорная SMP-система), причем 99% CPU использовалось в пользовательском режиме. После изучения данных трассировки AIX, собранных за несколько секунд, была замечена некоторая тенденция. Пока поток использовал CPU, прибывал сетевой пакет и вызывал внезапное прерывание от сетевого адаптера. Это могло привести к тому, что выполнение потока, занимавшего в данный момент CPU, прекращалось, чтобы CPU мог обслужить возникшее прерывание от сетевого адаптера.

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

Одним из результатов этого прерывания был в том, что иногда поток мог быть прерван тогда, когда он держал блокировку базы данных. Поскольку этот тип блокировки реализован на уровне приложения в ПО базы данных, ядро не знает, что поток удерживает блокировку. Если бы блокировка была реализована на уровне ядра или была бы мутекс-блокировкой (mutex lock) библиотеки pthread, тогда ядро могло бы выполнить повышение приоритета потока, удерживающего блокировку, до того же уровня, что и у выполняющегося потока, который запрашивает блокировку. Таким образом, запрашивающий поток не должен будет ждать длительное время, пока удерживающий блокировку поток не начнет снова выполняться на CPU и не освободит блокировку.

Но так как блокировка в данном случае была на пользовательском уровне, поток базы данных "крутился" в цикле блокировки вплоть до достижения максимально возможного числа оборотов, после чего переходил в неактивное состояние. Таким образом, 99% использования CPU приходилось на потоки, ожидающих блокировки базы данных.

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

pri = base_pri + NICE + (C * r/32) 

pri является новым приоритетом, base_pri равняется 40, NICE равняется значению nice (20 в этом случае), C – это показатель использования CPU (CPU usage) в тактах системных часов, r равняется 16.

По мере того как поток накапливает такты выполнения на CPU, его значение приоритета становится выше, следовательно уровень приоритета ниже.

Команда schedo предоставляет способ изменить значение r при помощи параметра sched_R. Выполнение команды schedo -p -o sched_R=0 приведет к тому, что r будет равняться 0, что, в свою очередь, приведет к тому, что штраф за использование CPU (C * r/32) будет равняться 0. Такое значение будет препятствовать изменению приоритетов, если не будет изменяться значение nice. Если значение nice одинаково для всех потоков, тогда потоки могут завершить свое выполнение в течение отведенных им квантов времени без прерываний из-за изменения приоритетов. Это позволит потоку, который выполняется в данный момент и удерживает блокировку базы данных, успешно завершиться и освободить эту блокировку.

Результаты: Эти изменения оказали мгновенное влияние на производительность. Время ответа на запрос, которое временами было больше двух минут, начало уменьшаться до тех пор, пока все сценарии не начали выполняться всего за несколько секунд каждый. Значение C в формуле вычисления приоритета пересчитывается только один раз в секунду с учетом коэффициента уменьшения использования CPU (usage decay factor) (C = C*d/32). Установка значения d в 0 путем использования команды schedo приведет к таким же результатам. В данном случае, если d=0, тогда C*d/32 = 0. Так как штраф к использованию CPU вычисляется по формуле C*r/32 и, следовательно, он также становится равным 0, значение приоритета будет вычисляться следующим образом: 40 + NICE.

Пример 2

Симптомы: Компьютер pSeries использовался как сервер базы данных и сервер приложений. Пользователи должны вводить запросы в приложение с формами и затем подтверждать транзакции. Пользователи заметили, что иногда формы на их экранах обновляются дольше, чем всегда, и их короткие, обычно быстро выполняющиеся запросы выполняются слишком долго.

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

С течением времени выполнения пакетных заданий их уровень приоритета падал, что позволяло выполняться пользовательским процессам. Однако ядро уменьшало показатель использования CPU C на половину каждую секунду. Данное обстоятельство позволяло приоритетам пакетных заданий улучшаться за короткий период времени. И пакетные задания снова начинали соревноваться с пользовательскими процессами за центральный процессор.

Рекомендации: Изменив коэффициент уменьшения (d/32), используемый один раз в секунду для уменьшения показателя использования CPU, удалось улучшить производительность системы для пользователей. Для этого использовалась команда schedo для присвоения параметру d значения 31. Чем выше значение d, тем выше значение C (C=C*d/32).

Так как C используется для вычисления приоритетов (pri=40+NICE+C*r/32), с увеличением C приоритет будет становиться хуже. Если присвоить d более высокое значение, значение C будет уменьшаться медленнее, чем обычно.

Результаты: Пользовательские потоки используют CPU более часто, чем пакетные потоки. И, как результат, пользователи увидели немедленное увеличение производительности. Конечно, выполнение пакетных заданий будет несколько замедленно, но эти задания получат процессорное время, как только пользовательские потоки станут неактивными или будут ожидать ввода/вывода. Влияние этих изменений на пакетные задания было минимальным, а на пользовательские процессы очень значительным.

Заметки по примерам: отслеживание повторяющихся событий

Последний раздел описывает некоторые необычные вещи, которые влияют на производительность. В течение одного из наших эталонных тестов было установлено, что использование CPU достигает 100%, причем большинство процессорного времени использует "система". В то же время производительность приложений заметно упала.

После того как были собраны данные трассировки AIX, было выявлено повторяющееся событие. Один прикладной процесс сталкивался с ошибкой из-за отсутствия страницы по определенному адресу. Эта ошибка отсутствия страниц вызывала исключение защиты (protection exception) в VMM, что, в свою очередь, служило причиной отсылки ядром этому процессу сигнала SIGSEGV (segmentation violation). Когда процесс возобновлял свою работу, ошибка из-за отсутствия страницы по данному адресу памяти возникала опять, что приводило к следующему исключению защиты и отсылке очередного сигнала SIGSEGV процессу. Реакцией по умолчанию для сигнала SIGSEGV является завершение процесса и создание дампа (core dump), но в этом случае приложение продолжало работать и оставалось в этом цикле. Большая часть процессорного времени была потрачена в этом цикле.

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

Ресурсы

• Примите участие в обсуждении материала на форуме.
  
  
• CPU monitoring and tuning: Get rid of your CPU bottlenecks and improve performance: оригинал статьи (EN).
  
  
• AIX 5L Support for Micro-Partitioning and Simultaneous Multi-threading (EN): статья, описывающая одновременную многопоточную обработку (SMT) и, дополнительно, новые технологии, связанные с микроразделами, и их поддержку в ОС AIX 5L.
  
  
• Operating system exploitation of the POWER5 system (EN): эта статья рассматривает, как новые особенности работы системы улучшают ее масштабируемость и производительность.
  
  
• AIX 5L Differences Guide Version 5.3 Edition (EN): этот учебник IBM RedBook рассказывает о нововведениях AIX 5L версии 5.3 при сравнении этой версии ОС с AIX 5L версии 5.2.
  
  
• Capped and Uncapped Partitions in IBM POWER5 (EN): эта статья представляет и объясняет концепции нединамических и динамических сегментов (capped and uncapped partitions), а также рассматривает вес приоритетов и использование ресурсов CPU пулами памяти.
  
  
• AIX 5L Practical Performance Tools and Tuning Guide (EN): этот учебник IBM RedBook является всеобъемлющим руководством по мониторингу производительности и инструментам настройки, поставляемым с AIX 5L версии 5.3.
  
  
• Popular content: популярные материалы об AIX и UNIX.(EN)
  
  
• Раздел developerWorks AIX and UNIX содержит сотни информативных статей для читателей начальной, средней и высокой квалификации.
  
  
• Новичок в AIX и UNIX?: страница AIX и UNIX для новичков.
  
  
• AIX 5L Wiki: совместная разработка документации AIX.(EN)
  
  
• Разделы библиотеки информации по темам AIX и UNIX:(EN)
  • Системное администрирование
  • Разработка приложений
  • Производительность
  • Переносимость
  • Безопасность
  • Подсказки
  • Инструментальные средства и утилиты
  • Java™-технологии
  • Linux®
  • Open source
  
  
  
• IBM trial software: ознакомительные версии программного обеспечения для разработчиков, которые можно загрузить прямо со страницы сообщества developerWorks.(EN)
  
  
• Safari bookstore: сайт магазина книг по ИТ.(EN)
  
  
• developerWorks blogs: участвуйте в жизни сообщества developerWorks.(EN)
  
  
• Примите участие в форумах AIX и UNIX:(EN)
  • Управление кластерными системами
  • Поддержка IBM
  • Инструменты управления производительностью - технический форум
  • Виртуализация - технический форум
  
  
  
• Команда IBM developerWorks проводит по всему миру сотни бесплатных технических консультаций.(EN)
  
  
• Podcasts: аудиозаписи презентаций экспертов IBM.(EN)
  
  

Об авторах

Оценить эту статью

Комментарии

В начало

Содержание

• Введение
• Что такое SMT?
• Алгоритмы планирования
• Изменения в командах для AIX 5.3
• Формулы для вычисления приоритетов потоков
• Как AIX вычисляет новый приоритет
• Контроль потребления ресурсов CPU
• Распространенные команды
• Улучшение производительности системы
• Другие приемы
• Настройка отдельных приложений
• Примеры из практики
• Ресурсы
• Об авторах
• Комментарии