Часть I Управление ресурсами

В этом разделе предоставлено введение в диспетчер ресурсов Solaris 10, который позволяет контролировать использование доступных системных ресурсов приложениями.

Глава 1 Введение в диспетчер ресурсов Solaris 10

Функциональные возможности управления ресурсами являются компонентом среды Solaris^TM Container. Управление ресурсами позволяет регулировать использование доступных системных ресурсов приложениями. Имеются следующие возможности:

• распределение вычислительных ресурсов, например процессорного времени;

• Наблюдение за использованием выделенных ресурсов и регулирование распределения по мере необходимости;

• генерация данных расширенного учета для анализа, биллинга и планирования пропускной способности.

В этой главе рассматриваются следующие темы:

• Обзор управления ресурсами

• Рекомендации по использованию управления ресурсами

• Настройка управления ресурсами (карта задач)

Обзор управления ресурсами

Современные вычислительные среды должны гибко реагировать на изменчивые рабочие нагрузки, создаваемые в системе разнообразными приложениями. Рабочая нагрузка – это совокупность всех процессов приложения или группы приложений. Если функции управления ресурсами не используются, операционная система Solaris реагирует на запросы рабочих нагрузок путем динамической адаптации к новым запросам приложений. Эта стандартная реакция обычно предоставляет всем приложениям, работающим в системе, равный доступ к ресурсам. Функции управления ресурсами Solaris позволяют реализовать дифференцированный подход к рабочим нагрузкам. Имеются следующие возможности:

• ограничение доступа к определенному ресурсу;

• предоставление ресурсов рабочим нагрузкам на основе приоритетов;

• изоляция рабочих нагрузок друг от друга.

Способность минимизации падения производительности по всем рабочим нагрузкам вместе со средствами наблюдения, использования и потребления ресурсов достигается за счет управления ресурсами. Управление ресурсами реализуется через ряд алгоритмов. Эти алгоритмы используются для обработки ряда запросов ресурсов, создаваемых приложениями в ходе выполнения.

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

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

• коллективная обработка определенных распределений вместо использования изолированных механизмов.

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

• предотвращение недифференцированного потребления ресурсов приложениями;

• изменение приоритета приложения на основании внешних событий;

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

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

• определение рабочих нагрузок, конкурирующих в системе;

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

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

Эффективное управление ресурсами реализуется в системе Solaris благодаря механизмам управления, механизмам уведомления и механизмам наблюдения. Многие из этих возможностей предоставляются через расширения существующих механизмов, например файловой системы proc(4), наборов процессоров и классов планирования. Другие возможности относятся исключительно к управлению ресурсами. Описание этих возможностей приводится в последующих главах.

Классификация ресурсов

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

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

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

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

Механизмы контроля в управлении ресурсами

В операционной системе Solaris доступны три типа механизмов управления – ограничения, планирование и распределение.

Механизмы ограничений

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

Использование ограничений ведет к усложнению среды с точки зрения приложений. Взаимосвязь между приложением и системой может измениться вплоть до полной невозможности дальнейшего функционирования приложения. Один из подходов, способных смягчить этот риск, состоит в постепенном сужении ограничений для приложений с неизвестным поведением в отношении ресурсов. Механизм ограничения обеспечивается функцией элементов управления ресурсами, рассматриваемой в Глава 6Элементы управления ресурсами (обзор). Более новые приложения могут создаваться с учетом соответствующих ограничений по ресурсам, однако реализация данной возможности зависит от авторов приложения.

Механизмы планирования

Под планированием понимается формирование последовательности принимаемых решений по распределению ресурсов с определенными интервалами. Решения принимаются на основании предсказуемого алгоритма. Если приложение не потребляет выделенные ему ресурсы, эти ресурсы остаются доступными для других приложений. Управление ресурсами на основе планирования позволяет полностью использовать конфигурацию с неполным распределением, обеспечивая при этом управляемость приложений в сценарии с полным или чрезмерным распределением. Интерпретация термина "управляемость" зависит от лежащего в основе алгоритма. В некоторых случаях алгоритм планирования может гарантировать определенный уровень доступности ресурса для всех приложений. Доступом приложений к ресурсам ЦП управляет настраиваемый планировщик долевого распределения (FSS), описанный в Глава 8Планировщик долевого распределения (обзор).

Механизмы распределения

Распределение используется для привязывания рабочей нагрузки к подмножеству доступных системных ресурсов. Эта привязка позволяет гарантировать доступность для этой рабочей нагрузки известного количества ресурсов. Описанные в Глава 12Пулы ресурсов (обзор) пулы ресурсов позволяют ограничить выполнение рабочих нагрузок определенными подмножествами компьютера.

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

Настройка управления ресурсами

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

Более подробное описание параметров управления ресурсами и идентификаторов, ориентированных на рабочие нагрузки, приведены в Глава 2Проекты и задачи (обзор). Подсистема расширенного учета, связывающая эти идентификаторы с потреблением ресурсов приложениями, описана в Глава 4Расширенный учет (обзор).

Взаимодействие с зонами Solaris

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

Рекомендации по использованию управления ресурсами

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

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

Консолидация серверов

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

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

При необходимости предоставления интернет- и прикладных сервисов управление ресурсами может обеспечить следующие возможности:

• Размещение нескольких веб-серверов на одной машине. Можно управлять потреблением ресурсов для каждого веб-сайта и защитить каждый сайт от потенциального превышения использования ресурсов другими сайтами.

• Предотвращение исчерпания ресурсов ЦП неисправным сценарием общего шлюзового интерфейса (CGI).

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

• Предотвращение воздействия на приложения клиентов со стороны приложений других клиентов, выполняющихся на том же сайте.

• Предоставление дифференцированных уровней или классов обслуживания на одной машине.

• Получение учетной информации для биллинга.

Поддержка большого или дифференцированного коллектива пользователей

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

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

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

Настройка управления ресурсами (карта задач)

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

Глава 2 Проекты и задачи (обзор)

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

В этой главе рассматриваются следующие темы:

• Средства управления проектами и задачами

• Идентификаторы проекта

• Идентификаторы задач

• Команды, используемые с проектами и задачами

Для получения информации по использованию средств управления проектами и задачами см. Глава 3Администрирование проектов и задач.

Новые функции и возможности базы данных project и команд управления ресурсами в Solaris 10

В версии Solaris 10 были добавлены следующие усовершенствования:

• Добавлена поддержка кратных единиц и модификаторов единиц в элементах и командах управления ресурсами.

• Усовершенствована проверка допустимости и упрощено манипулирование полями атрибутов проекта.

• Пересмотрен формат вывода и добавлены новые параметры для команд prctl и projects

• Добавлена возможность установки проекта пользователя по умолчанию командой useradd и изменения информации командами usermod и passmgmt

В дополнение к информации, приведенной в этой главе и в Глава 6Элементы управления ресурсами (обзор), см. следующие справочные страницы:

• passmgmt(1M)

• projadd(1M)

• projmod(1M)

• useradd(1M)

• usermod(1M)

• resource_controls(5)

В Solaris 10 5/08 к команде projmod добавлен параметр -A. См. Команды, используемые с проектами и задачами.

Полный список новых функций Solaris 10 и описание версий Solaris приведены в Solaris 10 What’s New.

Средства управления проектами и задачами

Для оптимизации времени отклика рабочих нагрузок необходимо сначала определить нагрузки, которые выполняются в анализируемой системе. Получить эту информацию методами, ориентированными только на процесс или только на пользователя, непросто. В системе Solaris предусмотрены два дополнительных средства для разделения и идентификации рабочих нагрузок. Эти проект и задача. Проект project обеспечивает общесетевой административный идентификатор для связанных работ. Задача объединяет группу процессов в управляемую сущность – компонент рабочей нагрузки.

Элементы управления, указанные в базе данных project службы имен, задаются на уровне процессов, задач и проектов. Поскольку элементы управления процессов и задач наследуются при системных вызовах fork и settaskid, они наследуются всеми процессами и задачами, создаваемыми внутри проекта. Для получения информации об этих системных вызовах см. справочные страницы fork(2) и settaskid(2).

Управление выполняющимися процессами осуществляется стандартными командами Solaris на основании членства в проекте или задаче. Отчеты подсистемы расширенного учета могут создаваться в отношении степени использования ресурсов как процессами, так и задачами, причем каждая запись маркируется идентификатором основного проекта. Этот процесс позволяет сопоставлять данные автономного анализа рабочих нагрузок с данными текущего наблюдения. Идентификатор проекта может быть общим для нескольких машин благодаря базе данных службы имен project. Таким образом, возможен анализ совокупного потребления ресурсов связанными рабочими нагрузками, которые выполняются (или располагаются) на нескольких машинах.

Идентификаторы проекта

Идентификатор проекта – это административный идентификатор, предназначенный для идентификации связанных работ. Идентификатор проекта представляет собой тег рабочей нагрузки, принципиально эквивалентный идентификаторам пользователей и групп. Отдельный пользователь или группа могут принадлежать одному или нескольким проектам. Эти проекты могут использоваться для представления рабочих нагрузок, в которых разрешается участвовать пользователю (или группе пользователей). Членство в этих проектах может служить основой для гибкого управления ресурсами, базирующегося, например, на степени использования или на начальном распределении ресурсов. Несмотря на то, что пользователю должен быть назначен проект по умолчанию, процессы, запущенные пользователем, могут быть связаны с любым проектом, членом которого является пользователь.

Определение проекта пользователя по умолчанию

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

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

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

1. Если в расширенной базе данных атрибутов пользователей /etc/user_attr для пользователя определена запись с атрибутом project, то в качестве проекта по умолчанию используется значение атрибута project. См. справочную страницу user_attr(4).

2. Если в базе данных project присутствует проект с именем user.идентификатор_пользователя, то по умолчанию используется этот проект. Для получения дополнительной информации см. справочную страницу project(4).

3. Если в базе данных project присутствует проект с именем group.имя_группы, где имя_группы соответствует группе по умолчанию для данного пользователя, как указано в файле passwd, то по умолчанию используется этот проект. Для получения информации о файле passwd см. справочную страницу passwd(4).

4. Если в базе данных project присутствует особый проект default, то этот проект используется по умолчанию.

Эта логика обеспечивается библиотечной функцией getdefaultproj(). Для получения дополнительной информации см. справочную страницу getprojent(3PROJECT).

Установка атрибутов пользователя командами useradd , usermod и passmgmt

Для установки атрибутов пользователей в локальных файлах используются перечисленные ниже команды с параметром -K и парой ключ=значение:

passmgmt

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

useradd

Настройка проекта по умолчанию для пользователя.

usermod

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

Могут использоваться следующие локальные файлы:

• /etc/group

• /etc/passwd

• /etc/project

• /etc/shadow

• /etc/user_attr

Если для дополнения локального файла дополнительными записями используется сетевая служба имен, такая как NIS, информация, предоставляемая сетевой службой имен, не может изменяться этими командами. Однако эти команды производят сверку следующих данных с информацией из внешней базы данных службы имен:

• уникальность имени пользователя (или роли),

• уникальность идентификатора пользователя,

• существование указанных имен групп.

Для получения дополнительной информации см. справочные страницы passmgmt(1M), useradd(1M), usermod(1M) и user_attr(4).

База данных project

Данные о проектах могут храниться в локальном файле, в карте проектов сетевой информационной службы (NIS), либо в службе каталогов протокола LDAP. Файл /etc/project или служба имен используются подключаемым модулем аутентификации (PAM) для связывания пользователя с проектом по умолчанию при входе в систему, а также при всех запросах на управление учетными записями.

Обновления записей в базе данных проектов, будь то файл /etc/project или представление базы данных в сетевой службе имен, не применяются к проектам, активным в текущий момент. Обновления применяются к новым задачам, присоединяющимся к проекту, при использовании команд login или newtask. Для получения дополнительной информации см. справочные страницы login(1) и newtask(1).

Подсистема PAM

К операциям, изменяющим или задающим идентификаторы, относятся вход в систему, вызов команд rcp и rsh, а также использование ftp и su. Если в ходе выполнения операции изменяется или задается идентификатор, то для аутентификации, управления учетными записями, управления параметрами доступа и управления сеансами используется набор настраиваемых модулей.

Описание модуля управления учетными записями проектов PAM см. на справочной странице pam_projects(5). Обзор PAM приведены в разделе Глава 17, Using PAM, в System Administration Guide: Security Services.

Настройка служб имен

Для управления ресурсами могут использоваться базы данных project службы имен. Место хранения базы данных project указывается в файле /etc/nsswitch.conf. По умолчанию первым в списке приводится пункт files, однако источники можно указывать в любом порядке.

project: files [nis] [ldap]

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

Для получения дополнительной информации о файле /etc/nsswitch.conf см. раздел Глава 2, The Name Service Switch (Overview), в System Administration Guide: Naming and Directory Services (DNS, NIS, and LDAP) и nsswitch.conf(4).

Формат локального файла /etc/project

Если в качестве источника базы данных project в файле nsswitch.conf выбрано значение files, процесс регистрации выполняет поиск информации о проекте в файле /etc/project. Для получения дополнительной информации см. справочные страницы projects(1) и project(4).

В файле project для каждого проекта, распознаваемого системой, содержится по одной строке следующей формы:

projname:projid:comment:user-list:group-list:attributes

Поля определены следующим образом:

projname

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

projid

Уникальный числовой идентификатор проекта (PROJID) внутри системы. Максимальное значение поля projid – UID_MAX (2147483647).

comment

Описание проекта.

user-list

Разделенный запятыми список пользователей, которым разрешено участие в проекте.

В этом поле могут использоваться групповые символы. Знак звездочки (*) разрешает всем пользователям присоединяться к проекту. Символ восклицательного знака, после которого находится символ звездочки (!*), исключает всех пользователей из проекта. Символ восклицательного знака (!), после которого указывается имя пользователя, исключает из проекта указанного пользователя.

group-list

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

В этом поле могут использоваться групповые символы. Знак звездочки (*) разрешает всем группам присоединяться к проекту. Символ восклицательного знака, после которого находится символ звездочки (!*), исключает все группы из проекта. Символ восклицательного знака (!), после которого указывается имя группы, исключает из проекта указанную группу.

attributes

Разделенный точками с запятыми список пар "имя-значение", например элементов управления ресурсами (см. Глава 6Элементы управления ресурсами (обзор)). name – произвольная строка, указывающая на связанный с объектом атрибут, а value – необязательное значение данного атрибута.

name[=value]

В паре "имя-значение" имена могут состоять только из букв, цифр, знаков подчеркивания и точек. Точка традиционно используется как разделитель между категориями и подкатегориями элементов управления ресурсами (rctl). Первый символ имени атрибута должен быть буквой. Имя зависит от регистра символов.

Порядок старшинства значений определяется запятыми и скобками.

Для разделения пар "имя-значение" используется точка с запятой. Использование точки с запятой в определении значения не допускается. Двоеточие используется для разделения полей проекта. Использование двоеточия в определении значения не допускается.

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

В этом примере показан файл /etc/project по умолчанию:

system:0:System:::
user.root:1:Super-User:::
noproject:2:No Project:::
default:3::::
group.staff:10::::

В этом примере показан файл /etc/project по умолчанию с добавленными в конец файла записями проекта:

system:0:System:::
user.root:1:Super-User:::
noproject:2:No Project:::
default:3::::
group.staff:10::::
user.ml:2424:Lyle Personal:::
booksite:4113:Book Auction Project:ml,mp,jtd,kjh::

Элементы управления ресурсами и атрибуты также можно добавлять в файл /etc/project :

• Информацию по добавлению элементов управления ресурсами для проекта приведены в Настройка элементов управления ресурсами.

• Информацию по настройке ограничения потребления физической памяти проектом с помощью демона ограниченного выделения ресурсов, описанного на странице rcapd(1M), приведены в разделе Атрибут ограничения использования физической памяти проектами.

• Информацию относительно добавления атрибута project.pool к записи проекта приведены в разделе Создание конфигурации.

Настройка проекта для NIS

Если используется NIS, в файле /etc/nsswitch.conf можно задать поиск проектов в картах проектов NIS:

project: nis files 

Карты NIS – и project.byname, и project.bynumber , – имеют такую же форму, как и файл /etc/project:

projname:projid:comment:user-list:group-list:attributes

Для получения дополнительной информации см. раздел Глава 4, Network Information Service (NIS) (Overview), в System Administration Guide: Naming and Directory Services (DNS, NIS, and LDAP).

Настройка проекта для LDAP

Если используется LDAP, в файле /etc/nsswitch.conf можно задать поиск проектов в базе данных LDAP project:

project: ldap files

Для получения дополнительной информации о LDAP см. раздел Глава 8, Introduction to LDAP Naming Services (Overview/Reference), в System Administration Guide: Naming and Directory Services (DNS, NIS, and LDAP). Для получения дополнительной информации о схеме записей проекта в базе данных LDAP см. раздел Solaris Schemas в System Administration Guide: Naming and Directory Services (DNS, NIS, and LDAP).

Идентификаторы задач

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

Каждый процесс участвует в одной задаче, а каждая задача связана с одним проектом.

Рисунок 2–1 Дерево проектов и задач

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

Задача создается при каждом присоединении проекта. Задачи создаются следующими действиями, командами и функциями:

• вход в систему

• cron

• newtask

• setproject

• su

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

• Можно использовать команду newtask с параметром - F.

• Для проекта в базе данных task.final службы имен можно установить атрибут project. Все задачи, создаваемые в данном проекте командой setproject, будут иметь флаг TASK_FINAL.

Для получения дополнительной информации см. справочные страницы login(1), newtask(1), cron(1M), su(1M) и setproject(3PROJECT).

Для получения учетных данных по процессам может использоваться подсистема расширенного учета. Данные агрегируются на уровне задачи.

Команды, используемые с проектами и задачами

Команды, показанные в следующей таблице, обеспечивают главный административный интерфейс к средствам проектов и задач.

Глава 3 Администрирование проектов и задач

В этой главе рассматривается использование проектов и задач для управления ресурсами Solaris.

Рассматриваются следующие темы:

• Примеры команд и их параметров

• Администрирование проектов

Краткое описание средств проектов и задач приведены в Глава 2Проекты и задачи (обзор).

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

Администрирование проектов и задач (карта задач)

Примеры команд и их параметров

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

Параметры команд, используемые с проектами и задачами

Команда ps

По команде ps с параметром -o отображаются идентификаторы задач и проектов. Например, для просмотра идентификатора проекта используется следующая команда:

# ps -o user,pid,uid,projid
USER PID   UID  PROJID
jtd  89430 124  4113

Команда id

Команда id с параметром -pпозволяет в дополнение к идентификаторам пользователя и группы вывести текущий идентификатор проекта. Если указывается операнд user, то отображается проект, связанный с нормальной учетной записью этого пользователя:

#  id -p
uid=124(jtd) gid=10(staff) projid=4113(booksite)

Команды pgrep и pkill

Если необходимо выполнить сопоставление только процессов с идентификаторами проектов из определенного списка, можно воспользоваться командами pgrep и pkill с параметром -J:

# pgrep -J projidlist
# pkill -J projidlist

Если необходимо отобразить сопоставление только для процессов, идентификаторы задач которых входят в определенный список, можно воспользоваться командами pgrep и pkill с параметром -T:

# pgrep -T taskidlist
# pkill -T taskidlist

Команда prstat

Команда prstat с параметром - J используется для отображения статистических данных для процессов и проектов, выполняющихся в настоящий момент.

% prstat -J
	  PID USERNAME  SIZE   RSS STATE  PRI NICE      TIME  CPU PROCESS/NLWP
 21634 jtd      5512K 4848K cpu0    44    0   0:00.00 0.3% prstat/1
   324 root       29M   75M sleep   59    0   0:08.27 0.2% Xsun/1
 15497 jtd        48M   41M sleep   49    0   0:08.26 0.1% adeptedit/1
   328 root     2856K 2600K sleep   58    0   0:00.00 0.0% mibiisa/11
  1979 jtd      1568K 1352K sleep   49    0   0:00.00 0.0% csh/1
  1977 jtd      7256K 5512K sleep   49    0   0:00.00 0.0% dtterm/1
   192 root     3680K 2856K sleep   58    0   0:00.36 0.0% automountd/5
  1845 jtd        24M   22M sleep   49    0   0:00.29 0.0% dtmail/11
  1009 jtd      9864K 8384K sleep   49    0   0:00.59 0.0% dtwm/8
   114 root     1640K  704K sleep   58    0   0:01.16 0.0% in.routed/1
   180 daemon   2704K 1944K sleep   58    0   0:00.00 0.0% statd/4
   145 root     2120K 1520K sleep   58    0   0:00.00 0.0% ypbind/1
   181 root     1864K 1336K sleep   51    0   0:00.00 0.0% lockd/1
   173 root     2584K 2136K sleep   58    0   0:00.00 0.0% inetd/1
   135 root     2960K 1424K sleep    0    0   0:00.00 0.0% keyserv/4
PROJID    NPROC  SIZE   RSS MEMORY      TIME  CPU PROJECT
    10       52  400M  271M    68%   0:11.45 0.4% booksite
     0       35  113M  129M    32%   0:10.46 0.2% system

Total: 87 processes, 205 lwps, load averages: 0.05, 0.02, 0.02

Команда prstat с параметром -T используется для отображения статистических данных для процессов и задач, выполняющихся в настоящий момент.

% prstat -T
   PID USERNAME  SIZE   RSS STATE  PRI NICE      TIME  CPU PROCESS/NLWP
 23023 root       26M   20M sleep   59    0   0:03:18 0.6% Xsun/1
 23476 jtd        51M   45M sleep   49    0   0:04:31 0.5% adeptedit/1
 23432 jtd      6928K 5064K sleep   59    0   0:00:00 0.1% dtterm/1
 28959 jtd        26M   18M sleep   49    0   0:00:18 0.0% .netscape.bin/1
 23116 jtd      9232K 8104K sleep   59    0   0:00:27 0.0% dtwm/5
 29010 jtd      5144K 4664K cpu0    59    0   0:00:00 0.0% prstat/1
   200 root     3096K 1024K sleep   59    0   0:00:00 0.0% lpsched/1
   161 root     2120K 1600K sleep   59    0   0:00:00 0.0% lockd/2
   170 root     5888K 4248K sleep   59    0   0:03:10 0.0% automountd/3
   132 root     2120K 1408K sleep   59    0   0:00:00 0.0% ypbind/1
   162 daemon   2504K 1936K sleep   59    0   0:00:00 0.0% statd/2
   146 root     2560K 2008K sleep   59    0   0:00:00 0.0% inetd/1
   122 root     2336K 1264K sleep   59    0   0:00:00 0.0% keyserv/2
   119 root     2336K 1496K sleep   59    0   0:00:02 0.0% rpcbind/1
   104 root     1664K  672K sleep   59    0   0:00:03 0.0% in.rdisc/1
TASKID    NPROC  SIZE   RSS MEMORY      TIME  CPU PROJECT                     
   222       30  229M  161M    44%   0:05:54 0.6% group.staff                 
   223        1   26M   20M   5.3%   0:03:18 0.6% group.staff                 
    12        1   61M   33M   8.9%   0:00:31 0.0% group.staff                 
     1       33   85M   53M    14%   0:03:33 0.0% system                      

Total: 65 processes, 154 lwps, load averages: 0.04, 0.05, 0.06	

Совместное использование параметров -J и -T не допускается.

Использование команд cron и su с проектами и задачами

Команда cron

Команда cron использует функцию settaskid, что позволяет обеспечить выполнение каждого задания cron, at и batch в отдельной задаче, с соответствующим проектом по умолчанию для пользователя, отправляющего его на выполнение. Команды at и batch также сохраняют текущий идентификатор проекта, что позволяет обеспечить восстановление идентификатора проекта при выполнении задания at.

Команда su

Команда su присоединяется к проекту по умолчанию целевого пользователя путем создания новой задачи в порядке симуляции входа в систему.

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

# su user

Администрирование проектов

Определение проекта и просмотр текущего проекта

В этом примере показано добавление записи проекта командой projadd и изменение этой записи командой projmod.

1. Перейдите в режим суперпользователя или воспользуйтесь эквивалентной ролью.

   Роли содержат подтвержденные полномочия и привилегированные команды. Для получения дополнительной информации о ролях см. раздел Using the Solaris Management Tools With RBAC (Task Map) в System Administration Guide: Basic Administration.

2. Отобразите файл /etc/project по умолчанию командой projects -l.

   # projects -l system:0:::: user.root:1:::: noproject:2:::: default:3:::: group.staff:10::::system projid : 0 comment: "" users : (none) groups : (none) attribs: user.root projid : 1 comment: "" users : (none) groups : (none) attribs: noproject projid : 2 comment: "" users : (none) groups : (none) attribs: default projid : 3 comment: "" users : (none) groups : (none) attribs: group.staff projid : 10 comment: "" users : (none) groups : (none) attribs:

3. Добавьте проект с именем booksite. Назначьте проект пользователю с именем mark и укажите идентификатор проекта 4113.

   # projadd -U mark -p 4113 booksite

4. Снова просмотрите файл /etc/project.

   # projects -l system projid : 0 comment: "" users : (none) groups : (none) attribs: user.root projid : 1 comment: "" users : (none) groups : (none) attribs: noproject projid : 2 comment: "" users : (none) groups : (none) attribs: default projid : 3 comment: "" users : (none) groups : (none) attribs: group.staff projid : 10 comment: "" users : (none) groups : (none) attribs: booksite projid : 4113 comment: "" users : mark groups : (none) attribs:

5. Добавьте в поле комментария описание проекта.

   # projmod -c `Book Auction Project' booksite

6. Просмотрите изменения в файле /etc/project .

   # projects -l system projid : 0 comment: "" users : (none) groups : (none) attribs: user.root projid : 1 comment: "" users : (none) groups : (none) attribs: noproject projid : 2 comment: "" users : (none) groups : (none) attribs: default projid : 3 comment: "" users : (none) groups : (none) attribs: group.staff projid : 10 comment: "" users : (none) groups : (none) attribs: booksite projid : 4113 comment: "Book Auction Project" users : mark groups : (none) attribs:

См. также

Инструкции по связыванию проектов, задач и процессов с пулом приведены в Установка атрибутов пулов и связывание с пулом.

Удаление проекта из файла /etc/project

В этом примере показан способ удаления проекта командой projdel.

1. Перейдите в режим суперпользователя или воспользуйтесь эквивалентной ролью.

   Роли содержат подтвержденные полномочия и привилегированные команды. Для получения дополнительной информации о ролях см. раздел Using the Solaris Management Tools With RBAC (Task Map) в System Administration Guide: Basic Administration.

2. Удалите проект booksite командой projdel.

   # projdel booksite

3. Просмотрите файл /etc/project.

   # projects -l system projid : 0 comment: "" users : (none) groups : (none) attribs: user.root projid : 1 comment: "" users : (none) groups : (none) attribs: noproject projid : 2 comment: "" users : (none) groups : (none) attribs: default projid : 3 comment: "" users : (none) groups : (none) attribs: group.staff projid : 10 comment: "" users : (none) groups : (none) attribs:

4. Войдите в систему как пользователь mark и введите команду projects для просмотра проектов, назначенных этому пользователю.

   # su - mark # projects default

Проверка допустимости содержимого файла /etc/project

При отсутствии параметров редактирования команда projmod проверяет допустимость содержимого файла project.

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

# ypcat project | projmod -f —

Команда ypcat project | projmod -f – еще не реализована.

Проверку синтаксиса файла /etc/project можно выполнить следующей командой:

# projmod -n

Получение информации о членстве в проекте

Для вывода данных о принадлежности запускаемого процесса к проекту используется команда id с параметром -p.

$ id -p
uid=100(mark) gid=1(other) projid=3(default)

Создание новой задачи

1. Войдите в систему как участник целевого проекта booksite.

2. Создайте новую задачу в проекте booksite с помощью команды newtask с параметром - v (подробный режим) для получения системного идентификатора задачи.

   machine% newtask -v -p booksite 16

   По команде newtask в указанном проекте создается новая задача, и в эту задачу помещается интерпретатор команд пользователя по умолчанию.

3. Просмотрите текущие данные по членству вызывающего процесса в проекте следующей командой.

   machine% id -p uid=100(mark) gid=1(other) projid=4113(booksite)

   Процесс теперь является членом нового проекта.

Перемещение выполняющегося процесса в новую задачу

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

1. Перейдите в режим суперпользователя или воспользуйтесь эквивалентной ролью.

   Роли содержат подтвержденные полномочия и привилегированные команды. Для получения дополнительной информации о ролях см. раздел Using the Solaris Management Tools With RBAC (Task Map) в System Administration Guide: Basic Administration.

   ---

   Примечание –

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

   ---

2. Определите идентификатор процесса book_catalog.

   # pgrep book_catalog 8100

3. Свяжите процесс 8100 с новым идентификатором задачи в проекте booksite.

   # newtask -v -p booksite -c 8100 17

   Параметр -c указывает, что команда newtask должна быть выполнена в отношении существующего именованного процесса.

4. Проверьте связь идентификаторов задачи и процесса.

   # pgrep -T 17 8100

Редактирование и проверка допустимости атрибутов проекта

Для редактирования атрибутов проекта используются команды администрирования базы данных проектов projadd и projmod.

Параметр -K позволяет указать альтернативный список атрибутов. Атрибуты разграничиваются символом точки с запятой (;). Если параметр -K используется с параметром -a, атрибут или значение атрибута добавляется. Если параметр -K используется с параметром -r, атрибут или значение атрибута удаляется. Если параметр -K используется с параметром - s, выполняется замена атрибута или значения атрибута.

Добавление атрибутов и значений атрибутов к проектам

Для добавления значений к атрибуту проекта используется команда projmod с параметрами -a и - K. Если атрибут не существует, он создается.

1. Перейдите в режим суперпользователя или воспользуйтесь эквивалентной ролью.

   Роли содержат подтвержденные полномочия и привилегированные команды. Для получения дополнительной информации о ролях см. раздел Using the Solaris Management Tools With RBAC (Task Map) в System Administration Guide: Basic Administration.

2. Добавьте атрибут элемента управления ресурсами без значений task.max-lwps в проект myproject. Задача, вступающая в проект, оперирует только системным значением для этого атрибута.

   # projmod -a -K task.max-lwps myproject

3. Затем можно добавить значение для task.max-lwps в проекте myproject. Значение состоит из уровня полномочий, порогового значения и действия в случае достижения этого порогового значения.

   # projmod -a -K "task.max-lwps=(priv,100,deny)" myproject

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

   # projmod -a -K "task.max-lwps=(priv,1000,signal=KILL)" myproject

   Множественные значения разделяются запятыми. Запись task.max-lwps теперь имеет следующий вид:

   task.max-lwps=(priv,100,deny),(priv,1000,signal=KILL)

Удаление значений атрибутов из проектов

В процедуре предполагаются значения:

task.max-lwps=(priv,100,deny),(priv,1000,signal=KILL)

1. Перейдите в режим суперпользователя или воспользуйтесь эквивалентной ролью.

   Роли содержат подтвержденные полномочия и привилегированные команды. Для получения дополнительной информации о ролях см. раздел Using the Solaris Management Tools With RBAC (Task Map) в System Administration Guide: Basic Administration.

2. Для удаления значения атрибута из элемента управления ресурсами task.max-lwps в проекте myproject используется команда projmod с параметрами -r и -K.

   # projmod -r -K "task.max-lwps=(priv,100,deny)" myproject

   Если у task.max-lwps несколько значений, например:

   task.max-lwps=(priv,100,deny),(priv,1000,signal=KILL)

   Удаляется первое совпадающее значение. Результат будет следующим:

   task.max-lwps=(priv,1000,signal=KILL)

Удаление атрибута элемента управления ресурсами из проекта

Для удаления элемента управления ресурсами task.max-lwps в проекте myproject используется команда projmod с параметрами - r и -K.

1. Перейдите в режим суперпользователя или воспользуйтесь эквивалентной ролью.

   Роли содержат подтвержденные полномочия и привилегированные команды. Для получения дополнительной информации о ролях см. раздел Using the Solaris Management Tools With RBAC (Task Map) в System Administration Guide: Basic Administration.

2. Удалите атрибут task.max-lwps и все его значения из проекта myproject:

   # projmod -r -K task.max-lwps myproject

Замена атрибутов и значений атрибутов для проектов

Для подстановки другого значения атрибута task.max-lwps в проекте myproject используется команда projmod с параметрами -s и -K. Если атрибут не существует, он создается.

1. Перейдите в режим суперпользователя или воспользуйтесь эквивалентной ролью.

   Роли содержат подтвержденные полномочия и привилегированные команды. Для получения дополнительной информации о ролях см. раздел Using the Solaris Management Tools With RBAC (Task Map) в System Administration Guide: Basic Administration.

2. Замените текущие значения task.max-lwps новыми значениями, приведенными ниже:

   # projmod -s -K "task.max-lwps=(priv,100,none),(priv,120,deny)" myproject

   Результат будет следующим:

   task.max-lwps=(priv,100,none),(priv,120,deny)

Удаление существующих значений атрибутов элементов управления ресурсами

1. Перейдите в режим суперпользователя или воспользуйтесь эквивалентной ролью.

   Роли содержат подтвержденные полномочия и привилегированные команды. Для получения дополнительной информации о ролях см. раздел Using the Solaris Management Tools With RBAC (Task Map) в System Administration Guide: Basic Administration.

2. Для удаления текущих значений task.max-lwps из проекта myproject введите следующую команду:

   # projmod -s -K task.max-lwps myproject

Глава 4 Расширенный учет (обзор)

Контроль потребления ресурсов каждой задачей достигается путем классификации и разделения задач с помощью средств работы с процессами и задачами, описанными в Глава 2Проекты и задачи (обзор). Для регистрации подробной статистики потребления ресурсов по процессам и по задачам используется подсистема расширенного учета.

В этой главе рассматриваются следующие темы.

• Введение в расширенный учет

• Принцип действия расширенного учета

• Настройка расширенного учета

• Команды, используемые совместно с расширенным учетом

• Интерфейс Perl к libexacct

Вводная информация по использованию расширенного учета приведена в Активация расширенного учета для процессов, задач и потоков.

Новые функции и возможности расширенного учета в Solaris 10

Добавлена возможность генерации данных mstate для учета процессов. См. Просмотр доступных ресурсов учета.

Полный список новых функций Solaris 10 и описание версий Solaris приведены в Solaris 10 What’s New.

Введение в расширенный учет

Записи об использовании ресурсов маркируются в подсистеме расширенного учета метками проекта, для которого выполняется сбор данных. Расширенный учет также может использоваться для регистрации информации о сетевых потоках в системе вместе с модулем учета потоков IPQoS (Internet Protocol Quality of Service), описанным в разделе Глава 36, Using Flow Accounting and Statistics Gathering (Tasks), в System Administration Guide: IP Services.

Перед использованием механизмов управления ресурсами необходимо сначала охарактеризовать потребности в ресурсах, свойственные различным рабочим нагрузкам в системе. Подсистема расширенного учета в операционной системе Solaris обеспечивает гибкий способ регистрации потребления системных и сетевых ресурсов для отдельных задач или процессов, либо на основании селекторов, предоставленных модулем IPQoS flowacct. Для получения дополнительной информации см. ipqos(7IPP).

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

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

Принцип действия расширенного учета

Для хранения учетных данных в подсистеме расширенного учета операционной Solaris используется расширяемый формат файла с версиями. Файлы с этим форматом данных можно использовать или создавать посредством API, обеспечиваемого поставляемой библиотекой libexacct (см. libexacct(3LIB)). Эти файлы затем могут быть проанализированы на любой платформе с включенным расширенным учетом, и их данные могут использоваться для планирования доступных ресурсов и гибкого управления ими.

Если активен расширенный учет, выполняется сбор статистики, которую можно исследовать с помощью интерфейса API libexacct. Библиотека libexacct позволяет исследовать файлы exacct в прямом или обратном направлении. API поддерживает файлы, генерируемые libexacct, а также файлы, создаваемые ядром. Существует также интерфейс Perl (Practical Extraction and Report Language) для libexacct, позволяющий разрабатывать собственные сценарии для создания отчетов и извлечения данных. См. Интерфейс Perl к libexacct.

Например, при включенном расширенном учете каждая задача отслеживает совокупное использование ресурсов задействованными процессами. Учетная запись задачи записывается по завершении ее выполнения. Также могут создаваться промежуточные записи по выполняемым процессам и задачам. Для получения дополнительной информации о задачах см. Глава 2Проекты и задачи (обзор).

Рисунок 4–1 Отслеживание задач при включенном расширенном учете

Расширяемый формат

Формат расширенного учета существенно более гибок с точки зрения расширения по сравнению со старым форматом учета системных ресурсов SunOS^TM (см. What is System Accounting? в System Administration Guide: Advanced Administration). Расширенный учет позволяет добавлять и удалять метрики учета в системе – как при переходе с одной версии на другую, так и во время нормальной работы системы.

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

Записи и формат exacct

Программы, допускающие создание записей exacct, служат двум целям:

• возможность создания сторонних файлов exacct;

• возможность создания записей маркировки, внедряемых в учетный файл ядра системным вызовом putacct (см. getacct(2)).

  ---

  Примечание –

  Системный вызов putacct также доступен из интерфейса Perl.

  ---

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

Для преобразования и создания файлов в формате exacct используется библиотека libexacct. Эта библиотека является единственным поддерживаемым интерфейсом к файлам формата exacct.

Системные вызовы getacct, putacct и wracct не применимы к потокам. Если настроен потоковый учет IPQoS, ядро создает записи потока и записывает их в файл.

Использование расширенного учета в системе Solaris с установленными зонами

При работе в глобальной зоне подсистема расширенного учета выполняет сбор и выдачу информации для всей системы (включая неглобальные зоны). Потребление ресурсов также может задаваться для отдельных зон глобальным администратором. Для получения дополнительной информации см. Расширенный учет в системе Solaris с установленными зонами.

Настройка расширенного учета

Текущая конфигурация расширенного учета содержится в файле /etc/acctadm.conf. Этот файл редактируется через интерфейс acctadm ; непосредственное редактирование пользователем не допускается.

Стандартным расположением данных расширенного учета является каталог /var/adm/exacct. Для указания другого места назначения для файлов данных учета процессов и задач используется команда acctadm. Для получения дополнительной информации см. acctadm(1M).

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

Информацию по командам, связанным с задачами и проектами, приведены в Примеры команд и их параметров. Информацию по учету потоков IPQoS приведены в ipqosconf(1M).

Интерфейс Perl к libexacct

Интерфейс Perl позволяет создавать сценарии на Perl для чтения учетных файлов, созданных архитектурой exacct. Также имеется возможность создания сценариев на Perl, записывающих файлы exacct.

Интерфейс функционально эквивалентен API на C, лежащему в его основе. Когда это возможно, данные, полученные из основного API на C, представляются в виде типов данных Perl. Эта функциональность упрощает доступ к данным и устраняет необходимость в операциях помещения в буфер и изъятия из буфера. Кроме того, все управление памятью выполняется библиотекой Perl.

Разнообразные функции, связанные с проектами, задачами и exacct, разнесены по группам. Каждая группа функций располагается в отдельном модуле Perl. Каждый модуль начинается со стандартного префикса пакетов Perl Sun::Solaris::. Все классы, предоставляемые библиотекой Perl exacct, располагаются в модуле Sun::Solaris::Exacct.

Лежащая в основе библиотека libexacct(3LIB) обеспечивает операции над файлами в формате exacct, тегами каталогов и объектами exacct. Объекты exacct подразделяются на два типа:

• элементы, представляющие собой одиночные значения данных (скаляры);

• группы, представляющие собой списки элементов.

В следующей таблице дается краткая характеристика каждого из модулей.

Примеры использования модулей, описанных в предыдущей таблице, приведены в Использование интерфейса Perl для libexacct.

Глава 5 Администрирование расширенного учета (задачи)

В этой главе описывается администрирование подсистемы расширенного учета.

Краткое описание подсистемы расширенного учета приведены в Глава 4Расширенный учет (обзор).

Администрирование подсистемы расширенного учета (карта задач)

Использование функциональных возможностей расширенного учета

Активация расширенного учета для процессов, задач и потоков

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

1. Перейдите в режим суперпользователя или воспользуйтесь эквивалентной ролью.

   Роли содержат подтвержденные полномочия и привилегированные команды. Для получения дополнительной информации о ролях см. Using the Solaris Management Tools With RBAC (Task Map) в System Administration Guide: Basic Administration.

2. Активируйте расширенный учет для процессов.

   # acctadm -e extended -f /var/adm/exacct/proc process

3. Активируйте расширенный учет для задач.

   # acctadm -e extended,mstate -f /var/adm/exacct/task task

4. Активируйте расширенный учет для потоков.

   # acctadm -e extended -f /var/adm/exacct/flow flow

См. также

Для получения дополнительной информации см. acctadm(1M).

Активация расширенного учета при помощи сценария запуска

Активировать расширенный учет на постоянной основе можно путем установки ссылки на сценарий /etc/init.d/acctadm в /etc/rc2.d.

# ln -s /etc/init.d/acctadm /etc/rc2.d/Snacctadm
# ln -s /etc/init.d/acctadm /etc/rc2.d/Knacctadm

Переменная n заменяется числом.

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

Информацию по настройке учета приведены в Настройка расширенного учета.

Отображение состояния расширенного учета

Для вывода текущего состояния подсистемы расширенного учета введите acctadm без аргументов.

# acctadm
                 Task accounting: active
            Task accounting file: /var/adm/exacct/task
          Tracked task resources: extended
        Untracked task resources: none
              Process accounting: active
         Process accounting file: /var/adm/exacct/proc
       Tracked process resources: extended
     Untracked process resources: host
                 Flow accounting: active
            Flow accounting file: /var/adm/exacct/flow
          Tracked flow resources: extended
        Untracked flow resources: none

В примере выше для системных задач активирован учет в расширенном режиме и в режиме mstate. Для процессов и потоков активен учет в расширенном режиме.

В контексте расширенного учета микросостояние (mstate) означает дополнительные данные, связанные с переключением микросостояний процессов, которые доступны в файле использования процесса (см. proc(4)). Эти данные предоставляют существенно более подробную информацию о работе процесса, чем базовые или расширенные записи.

Просмотр доступных ресурсов учета

Доступные ресурсы могут варьироваться в зависимости от конкретной системы или платформы. Для просмотра ресурсов учета, доступных в системе, можно воспользоваться командой acctadm с параметром -r.

# acctadm -r
process:
extended pid,uid,gid,cpu,time,command,tty,projid,taskid,ancpid,wait-status,zone,flag,
memory,mstatedisplays as one line
basic    pid,uid,gid,cpu,time,command,tty,flag
task:
extended taskid,projid,cpu,time,host,mstate,anctaskid,zone
basic    taskid,projid,cpu,time
flow:
extended 
saddr,daddr,sport,dport,proto,dsfield,nbytes,npkts,action,ctime,lseen,projid,uid
basic    saddr,daddr,sport,dport,proto,nbytes,npkts,action

Деактивация учета для процессов, задач и потоков

Учет деактивируется по отдельности для процессов, задач и потоков командой acctadm с параметром -x.

1. Перейдите в режим суперпользователя или воспользуйтесь эквивалентной ролью.

   Роли содержат подтвержденные полномочия и привилегированные команды. Для получения дополнительной информации о ролях см. Using the Solaris Management Tools With RBAC (Task Map) в System Administration Guide: Basic Administration.

2. Отключите учет для процессов.

   # acctadm -x process

3. Отключите учет для задач.

   # acctadm -x task

4. Отключите учет для потоков.

   # acctadm -x flow

5. Проверьте отключение учета для задач, процессов и потоков.

   # acctadm Task accounting: inactive Task accounting file: none Tracked task resources: extended Untracked task resources: none Process accounting: inactive Process accounting file: none Tracked process resources: extended Untracked process resources: host Flow accounting: inactive Flow accounting file: none Tracked flow resources: extended Untracked flow resources: none

Использование интерфейса Perl для libexacct

Рекурсивный вывод содержимого объекта exacct

Для рекурсивного вывода содержимого объекта exacct используется следующий код. Следует отметить, что эта возможность предоставляется библиотекой в виде функции Sun::Solaris::Exacct::Object::dump(). Эта возможность также доступна через упрощенную функцию ea_dump_object().

sub dump_object
     {
             my ($obj, $indent) = @_;
             my $istr = '  ' x $indent;

             #
             # Retrieve the catalog tag.  Because we are 
             # doing this in an array context, the
             # catalog tag will be returned as a (type, catalog, id) 
             # triplet, where each member of the triplet will behave as 
             # an integer or a string, depending on context.
             # If instead this next line provided a scalar context, e.g.
             #    my $cat  = $obj->catalog()->value();
             # then $cat would be set to the integer value of the 
             # catalog tag.
             #
             my @cat = $obj->catalog()->value();

             #
             # If the object is a plain item
             #
             if ($obj->type() == &EO_ITEM) {
                     #
                     # Note: The '%s' formats provide s string context, so
                     # the components of the catalog tag will be displayed
                     # as the symbolic values. If we changed the '%s'
                     # formats to '%d', the numeric value of the components
                     # would be displayed.
                     #
                     printf("%sITEM\n%s  Catalog = %s|%s|%s\n", 
                        $istr, $istr, @cat);
                     $indent++;

                     #
                     # Retrieve the value of the item.  If the item contains
                     # in turn a nested exacct object (i.e., an item or
                     # group),then the value method will return a reference
                     # to the appropriate sort of perl object
                     # (Exacct::Object::Item or Exacct::Object::Group).
                     # We could of course figure out that the item contained
                     # a nested item orgroup by examining the catalog tag in
                     # @cat and looking for a type of EXT_EXACCT_OBJECT or
                     # EXT_GROUP.
                     #
                     my $val = $obj->value();
                     if (ref($val)) {
                             # If it is a nested object, recurse to dump it.
                             dump_object($val, $indent);
                     } else {
                             # Otherwise it is just a 'plain' value, so
                             # display it.
                             printf("%s  Value = %s\n", $istr, $val);
                     }

             #
             # Otherwise we know we are dealing with a group.  Groups
             # represent contents as a perl list or array (depending on
             # context), so we can process the contents of the group
             # with a 'foreach' loop, which provides a list context.
             # In a list context the value method returns the content
             # of the group as a perl list, which is the quickest
             # mechanism, but doesn't allow the group to be modified.
             # If we wanted to modify the contents of the group we could
             # do so like this:
             #    my $grp = $obj->value();   # Returns an array reference
             #    $grp->[0] = $newitem;
             # but accessing the group elements this way is much slower.
             #
             } else {
                     printf("%sGROUP\n%s  Catalog = %s|%s|%s\n",
                         $istr, $istr, @cat);
                     $indent++;
                     # 'foreach' provides a list context.
                     foreach my $val ($obj->value()) {
                             dump_object($val, $indent);
                     }
                     printf("%sENDGROUP\n", $istr);
             }
     }

Создание новой записи группы с записью в файле

Следующий сценарий позволяет создать новую запись группы, которая помещается в файл /tmp/exacct.

#!/usr/bin/perl

use strict;
use warnings;
use Sun::Solaris::Exacct qw(:EXACCT_ALL);
# Prototype list of catalog tags and values.
     my @items = (
             [ &EXT_STRING | &EXC_DEFAULT | &EXD_CREATOR      => "me"       ],
             [ &EXT_UINT32 | &EXC_DEFAULT | &EXD_PROC_PID     => $$         ],
             [ &EXT_UINT32 | &EXC_DEFAULT | &EXD_PROC_UID     => $<         ],
             [ &EXT_UINT32 | &EXC_DEFAULT | &EXD_PROC_GID     => $(         ],
             [ &EXT_STRING | &EXC_DEFAULT | &EXD_PROC_COMMAND => "/bin/rec" ],
     );

     # Create a new group catalog object.
     my $cat = ea_new_catalog(&EXT_GROUP | &EXC_DEFAULT | &EXD_NONE)

     # Create a new Group object and retrieve its data array.
     my $group = ea_new_group($cat);
     my $ary = $group->value();

     # Push the new Items onto the Group array.
     foreach my $v (@items) {
             push(@$ary, ea_new_item(ea_new_catalog($v->[0]), $v->[1]));
     }

     # Open the exacct file, write the record & close.
     my $f = ea_new_file('/tmp/exacct', &O_RDWR | &O_CREAT | &O_TRUNC)
        || die("create /tmp/exacct failed: ", ea_error_str(), "\n");
     $f->write($group);
     $f = undef;

Вывод содержимого файла exacct

Следующий сценарий на Perl позволяет вывести содержимое файла exacct.

#!/usr/bin/perl

     use strict;
     use warnings;
     use Sun::Solaris::Exacct qw(:EXACCT_ALL);

     die("Usage is dumpexacct <exacct file>\n") unless (@ARGV == 1);

     # Open the exact file and display the header information.
     my $ef = ea_new_file($ARGV[0], &O_RDONLY) || die(error_str());
     printf("Creator:  %s\n", $ef->creator());
     printf("Hostname: %s\n\n", $ef->hostname());

     # Dump the file contents
     while (my $obj = $ef->get()) {
             ea_dump_object($obj);
     }

     # Report any errors
     if (ea_error() != EXR_OK && ea_error() != EXR_EOF)  {
             printf("\nERROR: %s\n", ea_error_str());
             exit(1);
     }
     exit(0);

Пример выходных данных Sun::Solaris::Exacct::Object->dump()

Ниже приводится пример результата работы функции Sun::Solaris::Exacct::Object->dump() над файлом, созданным в Создание новой записи группы с записью в файле.

Creator:  root
Hostname: localhost
GROUP
       Catalog = EXT_GROUP|EXC_DEFAULT|EXD_NONE
       ITEM
         Catalog = EXT_STRING|EXC_DEFAULT|EXD_CREATOR
         Value = me
       ITEM
         Catalog = EXT_UINT32|EXC_DEFAULT|EXD_PROC_PID
         Value = 845523
       ITEM
         Catalog = EXT_UINT32|EXC_DEFAULT|EXD_PROC_UID
         Value = 37845
       ITEM
         Catalog = EXT_UINT32|EXC_DEFAULT|EXD_PROC_GID
         Value = 10
       ITEM
         Catalog = EXT_STRING|EXC_DEFAULT|EXD_PROC_COMMAND
         Value = /bin/rec
ENDGROUP

Глава 6 Элементы управления ресурсами (обзор)

После определения потребления ресурсов рабочими задачами в системе в соответствии с Глава 4Расширенный учет (обзор) можно задать ограничения по использованию ресурсов. Ограничения позволяют предотвратить чрезмерное потребление ресурсов рабочими нагрузками. В качестве механизма ограничения используются элементы управления ресурсами.

В этой главе рассматриваются следующие темы:

• Принципы действия элементов управления ресурсами

• Настройка элементов управления ресурсами и атрибутов

• Применение элементов управления ресурсами

• Временное обновление значений элементов управления ресурсами в работающей системе

• Команды, используемые с элементами управления ресурсами

Для получения информации об администрировании элементов управления ресурсами см.Глава 7Администрирование элементов управления ресурсами (задачи).

Новые функции и возможности управления ресурсами в Solaris 10

Набор элементов управления ресурсами, приведенный ниже, заменяет собой настраиваемые средства взаимодействия процессов (IPC) системы System V из /etc/system:

• project.max-shm-ids

• project.max-msg-ids

• project.max-sem-ids

• project.max-shm-memory

• process.max-sem-nsems

• process.max-sem-ops

• process.max-msg-qbytes

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

• project.max-device-locked-memory

• project.max-port-ids

• process.max-port-events

Добавлены следующие элементы управления ресурсами криптографии:

• project.max-crypto-memory

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

• project.max-lwps

• project.max-tasks

• project.max-contracts

Для получения дополнительной информации см. Доступные элементы управления ресурсами.

Полный список новых функций Solaris 10 и описание версий Solaris приведены в Solaris 10 What’s New.

Принципы действия элементов управления ресурсами

В операционной системе Solaris концепция ограничения ресурсов для отдельных процессов была расширена и распространяется также на экземпляры задач и проектов в соответствии с описанием в Глава 2Проекты и задачи (обзор). Эти расширения обеспечиваются механизмом элементов управления ресурсами (rctls). Кроме того, схемы распределения, ранее назначавшиеся посредством настраиваемых значений в /etc/system, теперь настраиваются автоматически или также через механизм элементов управления ресурсами.

Элемент управления ресурсами идентифицируется по префиксу zone, project, task или process. Управление ресурсами может настраиваться на уровне всей системы в целом. Для обновления значений элементов управления ресурсами остановка системы не требуется.

Список стандартных элементов управления ресурсами, доступных в этой версии, приведены в Доступные элементы управления ресурсами. Информацию относительно доступных элементов управления ресурсами всей зоны приведены в Свойства типов ресурса.

Список стандартных элементов управления ресурсами, доступных в этой версии, приведены в Доступные элементы управления ресурсами.

Ограничения ресурсов и элементы управления ресурсами

В системах UNIX традиционно имеется средство ограничения ресурсов ( rlimit). Средство rlimit позволяет администратору задать одно или несколько численных ограничений количества ресурсов, потребляемых процессом. К числу этих ограничений относится процессорное время, потребляемое каждым процессом, размер файла дампа оперативной памяти и максимальный размер кучи для каждого процесса. Размер кучи – это количество рабочей памяти, выделяемой для сегмента данных процесса.

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

Взаимодействие процессов и элементы управления ресурсами

Процессы могут взаимодействовать между собой посредством одного из типов взаимодействия процессов (IPC). IPC позволяет передавать информацию или выполнять синхронизацию между процессами. В Solaris до версии 10 настраиваемые параметры IPC задавались путем добавления записи в файл /etc/system. Теперь же механизм элементов управления ресурсами предоставляет элементы управления ресурсами, определяющие поведение настроек IPC ядра. В Solaris до версии 10 настраиваемые параметры IPC задавались путем добавления записи в файл /etc/system.

Устаревшие параметры в данной системе Solaris могут быть добавлены в файл /etc/system. В таком случае эти параметры используются для инициализации значений элементов управления ресурсами по умолчанию, как и в предыдущих версиях Solaris. Однако использовать устаревшие параметры не рекомендуется.

Для выявления объектов IPC, вносящих свой вклад в потребление ресурсов проектом, используется команда ipcs с параметром -J. См. пример результата ее работы в Использование команды ipcs. Для получения дополнительной информации о команде ipcs см. ipcs(1).

Для получения дополнительной информации о настройке системы Solaris см. Solaris Tunable Parameters Reference Manual .

Механизмы ограничения элементов управления ресурсами

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

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

Механизмы атрибутов проекта

Элементы управления ресурсами также могут использоваться в качестве простого механизма атрибутов для средств управления ресурсами. Например, количество долей ЦП, предоставленных проекту в классе планирования планировщика долевого распределения (FSS), определяется элементом управления ресурсами project.cpu-shares. Поскольку элемент управления присваивает проекту фиксированное количество долей, разнообразные действия, связанные с элементом управления, не имеют силы. В этом контексте текущее значение элемента управления project.cpu-shares считается атрибутом указанного проекта.

Другой тип атрибута проекта используется для регулирования потребления ресурсов физической памяти наборами процессов, связанных с проектом. Эти атрибуты снабжаются префиксом rcap, например rcap.max-rss . Подобно элементам управления ресурсами, этот тип атрибута настраивается в базе данных project. Однако, несмотря на синхронное применение элементов управления ресурсами в ядре, на уровне пользователя лимиты ресурсов реализуются демоном ограниченного выделения ресурсов rcapd в асинхронном режиме. Для получения информации о демоне rcapd см. Глава 10Управление физической памятью с помощью демона ограниченного выделения ресурсов (обзор) и rcapd (1M).

Атрибут project.pool используется для установки привязки к пулу для проекта. Для получения дополнительной информации о пулах ресурсов см. Глава 12Пулы ресурсов (обзор).

Настройка элементов управления ресурсами и атрибутов

Механизм элементов управления ресурсами настраивается посредством базы данных project . См. Глава 2Проекты и задачи (обзор). Элементы управления ресурсами и другие атрибуты задаются в последнем поле записи базы данных project. Значения, связанные с каждым элементом управления ресурсами, заключаются в круглые скобки и выводятся в виде простого текста, разделенного запятыми. Значения в круглых скобках представляют собой "выражения действия". Каждое выражение действия состоит из уровня полномочий, порогового значения и действия, связанного с определенным пороговым значением. Каждому элементу управления ресурсами может соответствовать несколько выражений действия, также разделенных запятыми. Ниже показано определение ограничения по легковесным процессам для каждой задачи, а также ограничение максимального потребления процессорного времени для каждого процесса в проекте. process.max-cpu-time передает процессу сигнал SIGTERM после работы процесса в течение 1 часа и сигнал SIGKILL, если процесс продолжает выполняться в течение 1 часа и 1 минуты. См. Таблица 6–3.

development:101:Developers:::task.max-lwps=(privileged,10,deny);
  process.max-cpu-time=(basic,3600,signal=TERM),(priv,3660,signal=KILL)
typed as one line

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

Команда rctladm позволяет опрашивать и модифицировать настройки элементов управления ресурсами во время выполнения в глобальной области действия. Команда prctl позволяет опрашивать и модифицировать настройки элементов управления ресурсами во время выполнения влокальной области действия.

Для получения дополнительной информации см.Глобальные и локальные действия со значениями элементов управления ресурсами, rctladm(1M) и prctl(1).

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

Доступные элементы управления ресурсами

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

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

• Количества соответствуют ограниченным объемам.

• Индексы соответствуют максимально допустимым идентификаторам.

Так, project.cpu-sharesуказывает количество долей, которые разрешено использовать для проекта. process.max-file-descriptor указывает наивысший номер файла, который может быть назначен процессу системным вызовом open(2).

Таким образом можно отобразить значения по умолчанию для элементов управления ресурсами в системе, в которой элементы управления ресурсами не задавались и не изменялись. В подобной системе в /etc/system или в базе данных project отсутствуют записи, отличные от значений по умолчанию. Для вывода значений используется команда prctl.

Элементы управления ресурсами всей зоны

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

Для получения информации о настройке элементов управления ресурсами для всей зоны см. Свойства типов ресурса и Настройка зоны. Информацию по использованию элементов управления ресурсами для всей зоны в типизированных зонах lx приведены в Настройка, проверка и сохранение параметров типизированной зоны lx.

Следует отметить, что общезоновый элемент управления ресурсами можно применить и к глобальной зоне. Для получения дополнительной информации см. Глава 17Настройка неглобальной зоны (обзор) и Использование планировщика долевого распределения в системе Solaris с установленными зонами.

Поддержка единиц

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

• строки единиц измерения, подходящих для каждого элемента управления ресурсами;

• правильного масштаба для интерпретации масштабируемых значений.

Доступны следующие глобальные флаги:

С элементами управления ресурсами могут использоваться кратные единицы. В следующем примере демонстрируется пороговое значение в кратных единицах:

task.max-lwps=(priv,1K,deny)

Модификаторы единицы принимаются командами prctl, projadd и projmod. Использование модификаторов единиц в самой базе данных project не допускается.

Значения элементов управления ресурсами и уровни полномочий

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

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

• базовый (Basic), подлежащий изменению владельцем вызывающего процесса;

• привилегированный (Privileged), для которого допускается изменение только привилегированными пользователями (суперпользователями);

• системный (System), фиксированный в течение времени существования экземпляра операционной системы.

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

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

Уровень полномочий значения элемента управления ресурсами определяется в поле полномочий блока элементов управления ресурсами как RCTL_BASIC, RCTL_PRIVILEGED или RCTL_SYSTEM. Для получения дополнительной информации см. setrctl(2). Для изменения значений, связанных с базовыми и привилегированными уровнями, используется команда prctl.

Глобальные и локальные действия со значениями элементов управления ресурсами

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

Глобальные действия со значениями элементов управления ресурсами

Глобальные действия применяются в отношении значений элементов управления ресурсами для каждого элемента управления ресурсами в системе. Команда rctladm, описанная на справочной странице rctladm(1M), позволяет выполнять следующие действия:

• отображение глобального состояния активных элементов управления ресурсами системы;

• настройка глобальных действий по журналированию.

Глобальные действия по журналированию для элементов управления ресурсами можно включить или выключить. Для действия syslog можно задать определенную степень с помощью уровня категории, syslog=уровень. Ниже приведены возможные значения параметра уровень:

• debug

• info

• notice

• warning

• err

• crit

• alert

• emerg

По умолчанию глобальное журналирование превышения ограничений, устанавливаемых элементом управления ресурсами, не выполняется. В Solaris версии 10 5/08 добавлен уровень n/a, предназначенный для элементов управления ресурсами, для которых невозможно задать какие-либо глобальные действия.

Локальные действия со значениями элементов управления ресурсами

Локальные действия, выполняемые над процессом, который пытается превысить заданное значение. С каждым пороговым значением, заданным для элемента управления ресурсами, можно связать одно или несколько действий. Существуют три типа локальных действий: none, deny и signal=. Эти три действия используются следующим образом:

none

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

deny

Отклонение запросов ресурсов в объеме, превышающем пороговое значение. Например, элемент управления ресурсами task.max-lwps с действием deny приводит к отказу системного вызова fork, если новый процесс попробует превысить управляющее значение. См. справочную страницу fork(2).

signal=

Для случаев превышения элемента управления ресурсами можно задать глобальное действие, сводящееся к выдаче сигнального сообщения. Сигнал передается процессу при превышении порогового значения. Если процесс продолжает потреблять дополнительные ресурсы, новые сигналы не выдаются. Список доступных сигналов приведен в Таблица 6–3.

Не все действия можно применить к каждому элементу управления ресурсами. Например, процесс не может превысить количество долей ЦП, назначенных проекту, членом которого он является. Поэтому действие deny для элемента управления ресурсами project.cpu-shares не допускается.

Вследствие ограничений, связанных с реализацией, глобальные свойства каждого элемента управления могут ограничивать диапазон доступных действий, которые могут быть заданы для порогового значения. См. справочную страницу rctladm(1M). Список доступных сигнальных действий приведен в следующей таблице. Для получения дополнительной информации о сигналах см. справочную страницу signal(3HEAD).

Флаги и свойства элементов управления ресурсами

С каждым элементом управления ресурсами в системе связан определенный набор свойств. Этот набор свойств определяется как набор флагов, связанных со всеми управляемыми экземплярами данного ресурса. Глобальные флаги не подлежат изменению, однако могут быть считаны с помощью системных вызовов rctladm или getrctl.

Локальные флаги определяют поведение по умолчанию и конфигурацию для определенного порогового значения данного элемента управления ресурсами по определенному процессу или совокупности процессов. Локальные флаги одного порогового значения не воздействуют на поведение других пороговых значений, определенных для того же элемента управления ресурсами. Однако глобальные флаги воздействуют на поведение всех значений, связанных с определенным элементом управления. Локальные флаги можно изменять в пределах ограничений, заданных соответствующими глобальными флагами, командой prctl или системным вызовом setrctl. См. setrctl(2).

Полный список локальных флагов, глобальных флагов и их определений приведены в rctlblk_set_value(3C).

Для определения поведения системы в случае достижения порогового значения по определенному элементу управления ресурсами используется команда rctladm, отображающая глобальные флаги для элемента управления ресурсами. Например, для отображения значений process.max-cpu-time необходимо ввести следующую команду:

$ rctladm process.max-cpu-time
	process.max-cpu-time  syslog=off  [ lowerable no-deny cpu-time inf seconds ]

Глобальные флаги имеют следующие значения.

lowerable

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

no-deny

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

cpu-time

По достижении пороговых значений для этого ресурса возможна передача SIGXCPU.

seconds

Значение времени для элемента управления ресурсами.

no-basic

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

no-signal

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

no-syslog

Для этого элемента управления ресурсами невозможно определить глобальное действие сообщения syslog.

deny

Отклонение запросов на ресурс при превышении пороговых значений.

count

Значение счетчика (целое число) для элемента управления ресурсами.

bytes

Единица измерения для элемента управления ресурсами.

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

$ prctl -n process.max-cpu-time $$
	process 353939: -ksh
	NAME    PRIVILEGE    VALUE    FLAG   ACTION              RECIPIENT
 process.max-cpu-time
         privileged   18.4Es    inf   signal=XCPU                 -
         system       18.4Es    inf   none 

Флаг max (RCTL_LOCAL_MAXIMAL) устанавливается для обоих пороговых значений, а для данного элемента управления ресурсами определяется флаг inf (RCTL_GLOBAL_INFINITE). Значение inf соответствует бесконечному количеству. Это значение никогда не реализуется. Следовательно, в соответствии с конфигурацией оба пороговых показателя представляют собой бесконечные значения, которые не могут быть превышены.

Реализация управления ресурсами

Для ресурса может быть задано несколько элементов управления ресурсами. Элемент управления ресурсами может существовать на каждом уровне контейнеров модели процессов. Если элементы управления ресурсами активны для одного ресурса в контейнерах разных уровней, первым реализуется элемент управления наименьшего контейнера. Таким образом, в случае одновременного срабатывания сначала выполняется действие по process.max-cpu-time, а затем по task.max-cpu-time.

Рисунок 6–1 Совокупности процессов, взаимосвязи контейнеров и наборы элементов управления ресурсами

Глобальный контроль событий элементов управления ресурсами

Нередко потребление ресурсов процессами неизвестно. Для получения дополнительной информации можно воспользоваться глобальными действиями элементов управления ресурсами, доступными по команде rctladm. Команда rctladm позволяет установить действие syslog для элемента управления ресурсами. Затем, если какой-либо экземпляр, управляемый данным элементом, сталкивается с пороговым значением, в журнал заносится системное сообщение с заданным уровнем журналирования. Для получения дополнительной информации см. Глава 7Администрирование элементов управления ресурсами (задачи) и справочную страницу rctladm(1M).

Применение элементов управления ресурсами

Каждый элемент управления ресурсами, приведенный в Таблица 6–1, можно назначить проекту при регистрации или при вызове newtask, su или других средств запуска с поддержкой проектов at, batch или cron. Каждая инициированная команда запускается в отдельной задаче с проектом по умолчанию для вызывающего пользователя. Для получения дополнительной информации см. справочные страницы login(1), newtask(1), at(1), cron(1M) и su(1M).

Обновления записей в базе данных project, будь то файл /etc/project или представление базы данных в сетевой службе имен, не применяются к проектам, активным в настоящее время. Обновления применяются, когда к проекту присоединяется новая задача путем регистрации или командой newtask.

Временное обновление значений элементов управления ресурсами в работающей системе

Значения, измененные в базе данных project, вступают в силу только для новых задач, запускаемых в проекте. Однако для обновления элементов управления ресурсами в работающей системе можно использовать команды rctladm и prctl.

Обновление статуса журналирования

Команда rctladm изменяет глобальное состояние журналирования для каждого элемента управления ресурсами по всей системе. Эта команда может использоваться для просмотра глобального состояния и настройки уровня журналирования syslog при превышении управляющих значений.

Обновление элементов управления ресурсами

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

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

Командой project также можно изменять все параметры настройки элементов управления ресурсами, для которых возможно изменение в базе данных prctl. Можно добавлять как базовые, так и привилегированные значения. Также имеется возможность изменения связанных действий. По умолчанию для всех операций настройки предполагается базовый тип, однако процессы и пользователи с полномочиями суперпользователя также могут изменять привилегированные элементы управления ресурсами. Изменение элементов управления ресурсами системы не допускается.

Команды, используемые с элементами управления ресурсами

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

На справочной странице resource_controls(5) описаны элементы управления ресурсами, доступные в базе данных project, включая единицы измерения и коэффициенты масштабирования.

Глава 7 Администрирование элементов управления ресурсами (задачи)

В этой главе описывается администрирование элементов управления ресурсами.

Краткое описание механизма элементов управления ресурсами приведены в Глава 6Элементы управления ресурсами (обзор).

Администрирование элементов управления ресурсами (карта задач)

Настройка элементов управления ресурсами

Настройка максимального количества LWP для каждой задачи в проекте

Эта процедура позволяет добавить проект с названием x-files в файл /etc/project и установить максимальное количество LWP для задач, создаваемых в проекте.

1. Перейдите в режим суперпользователя или воспользуйтесь эквивалентной ролью.

   Роли содержат подтвержденные полномочия и привилегированные команды. Для получения дополнительной информации о ролях см. Using the Solaris Management Tools With RBAC (Task Map) в System Administration Guide: Basic Administration.

2. Создайте проект с названием x-files, используя команду projadd с параметром -K. Для всех задач, создаваемых в проекте, устанавливается максимальное количество LWP, равное 3 .

   # projadd -K 'task.max-lwps=(privileged,3,deny)' x-files

3. Просмотрите запись в файле /etc/project одним из следующих способов:

   • Введите следующее:

     # projects -l system projid : 0 comment: "" users : (none) groups : (none) attribs: . . . x-files projid : 100 comment: "" users : (none) groups : (none) attribs: task.max-lwps=(privileged,3,deny)

   • Введите следующее:

     # cat /etc/project system:0:System::: . . . x-files:100::::task.max-lwps=(privileged,3,deny)

Пример 7–1 Пример сеанса

После выполнения этих действий при создании суперпользователем новой задачи в проекте x-files путем соединения проекта с newtask суперпользователь не сможет создать в этой задаче более трех LWP. Это можно проиллюстрировать следующим примером сеанса.

# newtask -p x-files csh

# prctl -n task.max-lwps $$
process: 111107: csh
NAME    PRIVILEGE    VALUE    FLAG   ACTION            RECIPIENT
task.max-lwps
        privileged       3       -   deny                      -
        system       2.15G     max   deny                      -
# id -p
uid=0(root) gid=1(other) projid=100(x-files)

# ps -o project,taskid -p $$
 PROJECT TASKID
 x-files    73

# csh        /* creates second LWP */

# csh        /* creates third LWP */

# csh        /* cannot create more LWPs */
Vfork failed
#

Настройка нескольких элементов управления для проекта

Файл /etc/project может содержать параметры для ряда элементов управления ресурсами по каждому проекту, а также несколько пороговых значений для каждого элемента управления. Пороговые значения определяются в выражениях действия, разделяемых запятыми в случае указания нескольких значений.

1. Перейдите в режим суперпользователя или воспользуйтесь эквивалентной ролью.

   Роли содержат подтвержденные полномочия и привилегированные команды. Для получения дополнительной информации о ролях см. Using the Solaris Management Tools With RBAC (Task Map) в System Administration Guide: Basic Administration.

2. Настройте элементы управления ресурсами для проекта x-files командой projmod с параметрами -s и -K:

   # projmod -s -K 'task.max-lwps=(basic,10,none),(privileged,500,deny); process.max-file-descriptor=(basic,128,deny)' x-filesone line in file

   Задаются следующие элементы управления:

   • Базовый (basic) элемент управления, не влияющий на максимальное количество LWP в задаче.

   • Привилегированный элемент управления deny, управляющий максимальным количеством LWP на задачу. Этот элемент управления приводит к отклонению любой попытки создания LWP, в результате которой будет превышено максимальное количество, как показано в предыдущем примере Настройка максимального количества LWP для каждой задачи в проекте.

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

3. Просмотрите запись в файле одним из следующих способов:

   • Введите следующее:

     # projects -l . . . x-files projid : 100 comment: "" users : (none) groups : (none) attribs: process.max-file-descriptor=(basic,128,deny) task.max-lwps=(basic,10,none),(privileged,500,deny) one line in file

   • Введите следующее:

     # cat etc/project . . . x-files:100::::process.max-file-descriptor=(basic,128,deny); task.max-lwps=(basic,10,none),(privileged,500,deny) one line in file

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

Команда prctl используется для опроса и модификации элементов управления ресурсами, связанных с процессами, задачами или проектами, активными в системе. Для получения дополнительной информации см. справочную страницу prctl(1).

Использование команды prctl для вывода значений элементов управления ресурсами по умолчанию

Эту процедуру необходимо выполнять в системе, в которой не создавались и не изменялись элементы управления ресурсами. В файле /etc/system или в базе данных project должны находиться только значения, отличные от значений по умолчанию.

1. Команду prctl можно ввести для любого процесса, например для интерпретатора команд, выполняющегося в текущий момент.

   # prctl $$ process: 100337: -sh NAME PRIVILEGE VALUE FLAG ACTION RECIPIENT process.max-port-events privileged 65.5K - deny - system 2.15G max deny - process.crypto-buffer-limit system 16.0EB max deny - process.max-crypto-sessions system 18.4E max deny - process.add-crypto-sessions privileged 100 - deny - system 18.4E max deny - process.min-crypto-sessions privileged 20 - deny - system 18.4E max deny - process.max-msg-messages privileged 8.19K - deny - system 4.29G max deny - process.max-msg-qbytes privileged 64.0KB - deny - system 16.0EB max deny - process.max-sem-ops privileged 512 - deny - system 2.15G max deny - process.max-sem-nsems privileged 512 - deny - system 32.8K max deny - process.max-address-space privileged 16.0EB max deny - system 16.0EB max deny - process.max-file-descriptor basic 256 - deny 100337 privileged 65.5K - deny - system 2.15G max deny - process.max-core-size privileged 8.00EB max deny - system 8.00EB max deny - process.max-stack-size basic 8.00MB - deny 100337 privileged 8.00EB - deny - system 8.00EB max deny - process.max-data-size privileged 16.0EB max deny - system 16.0EB max deny - process.max-file-size privileged 8.00EB max deny,signal=XFSZ - system 8.00EB max deny - process.max-cpu-time privileged 18.4Es inf signal=XCPU - system 18.4Es inf none - task.max-cpu-time system 18.4Es inf none - task.max-lwps system 2.15G max deny - project.max-contracts privileged 10.0K - deny - system 2.15G max deny - project.max-device-locked-memory privileged 499MB - deny - system 16.0EB max deny - project.max-port-ids privileged 8.19K - deny - system 65.5K max deny - project.max-shm-memory privileged 1.95GB - deny - system 16.0EB max deny - project.max-shm-ids privileged 128 - deny - system 16.8M max deny - project.max-msg-ids privileged 128 - deny - system 16.8M max deny - project.max-sem-ids privileged 128 - deny - system 16.8M max deny - project.max-tasks system 2.15G max deny - project.max-lwps system 2.15G max deny - project.cpu-shares privileged 1 - none - system 65.5K max none - zone.max-lwps system 2.15G max deny - zone.cpu-shares privileged 1 - none - system 65.5K max none -

Использование команды prctl для отображения информации о выбранном элементе управления ресурсами

1. Эта команда позволяет вывести максимальный дескриптор файла для текущего работающего интерпретатора команд.

   # prctl -n process.max-file-descriptor $$ process: 110453: -sh NAME PRIVILEGE VALUE FLAG ACTION RECIPIENT process.max-file-descriptor basic 256 - deny 110453 privileged 65.5K - deny - system 2.15G max deny

Использование команды prctl для временного изменения значения

В этом примере команда prctl используется для временного добавления нового привилегированного значения, запрещающего использование более трех LWP на проект x-files. Результат можно сравнить с результатом Настройка максимального количества LWP для каждой задачи в проекте.

1. Перейдите в режим суперпользователя или воспользуйтесь эквивалентной ролью.

   Роли содержат подтвержденные полномочия и привилегированные команды. Для получения дополнительной информации о ролях см. Using the Solaris Management Tools With RBAC (Task Map) в System Administration Guide: Basic Administration.

2. Выполните команду newtask для присоединения к проекту x-files.

   # newtask -p x-files

3. Для проверки правильности присоединения к проекту можно воспользоваться командой id с параметром - p.

   # id -p uid=0(root) gid=1(other) projid=101(x-files)

4. Добавьте новое привилегированное значение для project.max-lwps , ограничивающее количество LWP значением 3.

   # prctl -n project.max-lwps -t privileged -v 3 -e deny -i project x-files

5. Проверьте результат.

   # prctl -n project.max-lwps -i project x-files process: 111108: csh NAME PRIVILEGE VALUE FLAG ACTION RECIPIENT project.max-lwps privileged 3 - deny - system 2.15G max deny -

Использование команды prctl для уменьшения значения элемента управления ресурсами

1. Перейдите в режим суперпользователя или воспользуйтесь эквивалентной ролью.

   Роли содержат подтвержденные полномочия и привилегированные команды. Для получения дополнительной информации о ролях см. Using the Solaris Management Tools With RBAC (Task Map) в System Administration Guide: Basic Administration.

2. Команда prctl с параметром -r используется для изменения самого низкого значения элемента управления ресурсами process.max-file-descriptor .

   # prctl -n process.max-file-descriptor -r -v 128 $$

Использование команды prctl для вывода, замены и проверки значений элементов управления для проекта

1. Перейдите в режим суперпользователя или воспользуйтесь эквивалентной ролью.

   Роли содержат подтвержденные полномочия и привилегированные команды. Для получения дополнительной информации о ролях см. Using the Solaris Management Tools With RBAC (Task Map) в System Administration Guide: Basic Administration.

2. Выведите значение project.cpu-shares для проекта group.staff.

   # prctl -n project.cpu-shares -i project group.staff project: 2: group.staff NAME PRIVILEGE VALUE FLAG ACTION RECIPIENT project.cpu-shares privileged 1 - none - system 65.5K max none

3. Замените текущее значение project.cpu-shares , равное 1, значением 10.

   # prctl -n project.cpu-shares -v 10 -r -i project group.staff

4. Выведите значение project.cpu-shares для проекта group.staff.

   # prctl -n project.cpu-shares -i project group.staff project: 2: group.staff NAME PRIVILEGE VALUE FLAG ACTION RECIPIENT project.cpu-shares privileged 10 - none - system 65.5K max none

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

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

Команда rctladm позволяет опрашивать и модифицировать глобальное состояние механизма элементов управления ресурсами во время выполнения. Для получения дополнительной информации см. справочную страницуrctladm(1M).

Например, команду rctladm с параметром -e можно использовать для включения глобального атрибута syslog для элемента управления ресурсами. При превышении значения элемента управления в журнал заносится уведомление на указанном уровне syslog. Для включения глобального атрибута syslog для process.max-file-descriptor используется следующая команда:

# rctladm -e syslog process.max-file-descriptor

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

# rctladm
process.max-port-events     syslog=off  [ deny count ]
process.max-msg-messages    syslog=off  [ deny count ]
process.max-msg-qbytes      syslog=off  [ deny bytes ]
process.max-sem-ops         syslog=off  [ deny count ]
process.max-sem-nsems       syslog=off  [ deny count ]
process.max-address-space   syslog=off  [ lowerable deny no-signal bytes ]
process.max-file-descriptor syslog=off  [ lowerable deny count ]
process.max-core-size       syslog=off  [ lowerable deny no-signal bytes ]
process.max-stack-size      syslog=off  [ lowerable deny no-signal bytes ]
.
.
.

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

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

Служебная программа ipcs используется для вывода информации по активным средствам взаимодействия процессов (IPC). Для получения дополнительной информации см. справочную страницу ipcs(1).

Вызов команды ipcs с параметром -J позволяет получить информацию о проекте, для ограничения которого выделен объект IPC.

# ipcs -J
    IPC status from <running system> as of Wed Mar 26 18:53:15 PDT 2003
T         ID      KEY        MODE       OWNER    GROUP    PROJECT
Message Queues:
Shared Memory:
m       3600      0       --rw-rw-rw-   uname    staff    x-files
m        201      0       --rw-rw-rw-   uname    staff    x-files
m       1802      0       --rw-rw-rw-   uname    staff    x-files
m        503      0       --rw-rw-rw-   uname    staff    x-files
m        304      0       --rw-rw-rw-   uname    staff    x-files
m        605      0       --rw-rw-rw-   uname    staff    x-files
m          6      0       --rw-rw-rw-   uname    staff    x-files
m        107      0       --rw-rw-rw-   uname    staff    x-files
Semaphores:
s          0      0       --rw-rw-rw-   uname    staff    x-files

Предупреждения по доступной мощности

Глобальное действие для элемента управления ресурсами позволяет получать уведомления о сущностях, сталкивающихся с чрезмерно низкими значениями элементов управления ресурсами.

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

Однако более простой подход заключается в размещении веб-сервера в задаче. Затем командой syslog можно задать глобальное действие, отправляющее уведомление при каждом превышении задачей запланированного количества LWP, соответствующего возможностям оборудования.

Для получения дополнительной информации см. справочную страницу sar(1).

Определение достаточности процессорной мощности, выделенной для веб-сервера

1. С помощью команды prctl установите привилегированный (принадлежащий суперпользователю) элемент управления ресурсами для задач, содержащих процесс httpd. Задайте для каждой задачи ограничение по количеству LWP, равное 40, и отключите все локальные действия.

   # prctl -n task.max-lwps -v 40 -t privileged -d all `pgrep httpd`

2. Активируйте глобальное действие системного журнала для элемента управления ресурсами task.max-lwps.

   # rctladm -e syslog task.max-lwps

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

   Если срабатывает, появится сообщение /var/adm/messages, подобное следующему:

   Jan 8 10:15:15 testmachine unix: [ID 859581 kern.notice] NOTICE: privileged rctl task.max-lwps exceeded by task 19

Глава 8 Планировщик долевого распределения (обзор)

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

В этой главе рассматриваются следующие темы:

• Введение в использование планировщика

• Определение долей ЦП

• Доли ЦП и состояние процесса

• Доля ЦП по сравнению с использованием ЦП

• Примеры долей ЦП

• Настройка FSS

• FSS и наборы процессоров

• Комбинирование FSS с другими классами планирования

• Настройка класса планирования в системе

• Класс планирования в системе с установленными зонами

• Команды, используемые с FSS

Вводную информацию по планировщику долевого распределения приведены в Глава 9Администрирование планировщика долевого распределения (задачи).

Введение в использование планировщика

Фундаментальная задача операционной системы заключается в арбитраже доступа процессов к ресурсам системы. Планировщик процессов, называемый также диспетчером, является частью ядра, управляющей распределением процессорных ресурсов по процессам. Планировщик поддерживает концепцию классов планирования. Каждый класс определяет политику планирования, используемую для планирования процессов внутри этого класса. Стандартный планировщик операционной системы Solaris – планировщик TS – пытается предоставить каждому процессу относительно равный доступ к доступным процессорам. Однако некоторым процессам может потребоваться больше ресурсов, чем другим.

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

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

FSS состоит из модуля ядра класса планирования и версий команд dispadmin(1M) и priocntl(1). Доли проекта, используемые FSS, указываются через свойство project.cpu-shares в базе данных project(4).

Если элемент управления ресурсами project.cpu-sharesиспользуется в системе с установленными зонами, см. Конфигурационные данные зоны, Элементы управления ресурсами, используемые в неглобальных зонах и Использование планировщика долевого распределения в системе Solaris с установленными зонами.

Определение долей ЦП

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

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

Процессы в проектах с нулевым количеством долей всегда выполняются с самым низким приоритетом в системе (0). Эти процессы выполняются, только если процессорные ресурсы не используются процессами с ненулевым количеством долей.

Доли ЦП и состояние процесса

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

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

Доля ЦП по сравнению с использованием ЦП

Распределение долей не аналогично степени использования. Проект, которому назначено 50 процентов ресурсов ЦП, может потреблять в среднем только 20 процентов. Более того, доли ограничивают использование процессора только при наличии конкуренции со стороны других проектов. Независимо от того, насколько мало ресурсов выделено проекту, ему достается 100 процентов вычислительной мощности, если он в системе один. Доступные циклы ЦП никогда не растрачиваются впустую. Они распределяются между проектами.

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

Примеры долей ЦП

Предположим, что в системе присутствуют два процессора и выполняются две зависящие от процессора параллельные рабочие нагрузки с названиями A и B соответственно. Каждая рабочая нагрузка выполняется как отдельный проект. Проекты настроены так, что проекту A назначено S_A долей, а проекту B назначено S _B долей.

В среднем, при традиционном планировании TS, каждой из рабочих нагрузок, выполняющихся в системе, выделяется одинаковое количество ресурсов ЦП. Каждая рабочая нагрузка получила бы 50 процентов от мощности системы.

Под управлением планировщика FSS с S _A=S_B этим проектам также выдается приблизительно равное количество ресурсов ЦП. Однако если проектам выделяется разное количество долей, их процессорные ресурсы распределяются по-иному.

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

Пример 1. Два зависящих от процессора процесса в каждом проекте

Если проекты A и B имеют по два зависящих от процессора процесса, и при этом S _A = 1, а S _B = 3, то общее число долей составляет 1 + 3 = 4. В такой конфигурации при достаточной потребности в процессорных ресурсах проектам A и B выделяется 25% и 75% ресурсов ЦП соответственно.

Пример 2. Конкуренция между проектами отсутствует

Если проекты A и B имеют только по одному зависящему от процессора процессу, и при этом S _A = 1, а S _B = 100, то общее число долей составляет 101. Ни один из проектов не может использовать более одного процессора, поскольку в каждом проекте только один выполняющийся процесс. Поскольку в этой конфигурации проекты не конкурируют за процессорные ресурсы, проектам A и B выделяется по 50 процентов всех ресурсов ЦП. В этой конфигурации значения долей ЦП не имеют значения. Распределение ресурсов для проектов такое же (50/50), даже в том случае, если обоим проектам назначены нулевые доли.

Пример 3. Один из проектов не может запуститься

Если проекты A и B имеют по два зависящих от процессора процесса, и при этом проекту A предоставлена 1 доля, а проекту B — 0 долей, проекту B вообще не выделяется процессорных ресурсов, а проект A получает все процессорные ресурсы. Процессы в B всегда выполняются с системным приоритетом 0. Это означает, что они никогда не будут выполняться, поскольку процессы проекта A всегда имеют более высокий приоритет.

Настройка FSS

Проекты и пользователи

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

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

Для получения дополнительной информации о базе данных project(4) и службе имен см. База данных project.

Настройка долей ЦП

Управление конфигурацией долей ЦП осуществляется службой имен в виде свойства базы данных project.

При создании первой задачи (или процесса), связанной с проектом, через библиотечную функцию setproject(3PROJECT) в ядро передается количество долей ЦП, определенных в виде элемента управления ресурсами project.cpu-shares в базе данных project . Проектам, для которых не определен элемент управления ресурсами project.cpu-shares, назначается одна доля.

В следующем примере данной записью в файле /etc/project для проекта x-files задается количество долей, равное 5:

x-files:100::::project.cpu-shares=(privileged,5,none)

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

Если требуется временно изменить количество долей, назначенных проекту, не изменяя атрибуты проекта в базе данных project, следует использовать команду prctl. Например, для изменения значения элемента управления ресурсами project.cpu-shares проекта x-files на 3 во время работы процессов, связанных с этим проектом, можно воспользоваться следующей командой:

# prctl -r -n project.cpu-shares -v 3 -i project x-files

Для получения дополнительной информации см. справочную страницу prctl(1).

-r

Замена текущего значения для указанного элемента управления ресурсами.

-n имя

Имя элемента управления ресурсами.

-v значение

Значение элемента управления ресурсами.

-i тип_идентификатора

Тип идентификатора следующего аргумента.

x-files

Объект для изменения. В этом экземпляре объектом является проект x-files.

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

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

Максимальное количество долей, которое можно назначить проекту, составляет 65535.

FSS и наборы процессоров

FSS можно использовать в сочетании с наборами процессоров, что позволит осуществлять более детализированное управление распределением процессорных ресурсов между процессами, выполняющимися на каждом наборе процессоров, по сравнению с использованием только наборов процессоров. С точки зрения планировщика FSS наборы процессоров рассматриваются как самостоятельные разделы, управляемые независимо от распределения ЦП.

На распределение ЦП проектов, выполняющихся в одном наборе процессоров, не влияют ни доли ЦП, ни деятельность проектов, выполняющихся на других наборах процессоров, так как проекты не конкурируют за одни и те же ресурсы. Проекты конкурируют друг с другом, только если они выполняются на одном наборе процессоров.

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

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

Разделам проектов, выполняющимся на разных наборах процессоров, могут быть выделены разные доли процессорных ресурсов. Распределение ЦП по каждому разделу проекта в наборе процессоров зависит только от распределения для других проектов, выполняющихся на том же самом наборе процессоров.

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

Пустые наборы процессоров (наборы без процессоров) или наборы процессоров без процессов, связанных с ними, не влияют на поведение планировщика FSS.

Примеры для FSS и наборов процессоров

Предположим, что на сервере с восьмью процессорами в проектах A, B и C выполняется несколько приложений, зависящих от ЦП. Проекту A выделяется одна доля, проекту B — две, а проекту C — три.

Проект A выполняется только на наборе процессоров 1. Проект B выполняется только на наборах процессоров 1 и 2. Проект C выполняется на наборах процессоров 1, 2 и 3. Предположим, каждый проект содержит достаточное число процессов, чтобы использовать все доступные ресурсы ЦП. Таким образом, за процессорные ресурсы в каждом наборе процессоров всегда существует конкуренция.

Общесистемное распределение процессорных ресурсов в такой системе показано в следующей таблице.

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

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

Комбинирование FSS с другими классами планирования

По умолчанию класс планирования FSS использует тот же диапазон приоритетов (от 0 до 59), что и классы планирования с разделением времени (TS), интерактивный класс (IA) и класс с фиксированным приоритетом (FX). Поэтому следует избегать совместного использования процессов с этими классами планирования в одном наборе процессоров. Комбинация процессов с классами FSS, TS, IA и FX может привести к непредвиденному поведению планирования.

Однако наличие наборов процессоров позволяет комбинировать TS, IA и FX с FSS в одной системе. Тем не менее все процессы, выполняющиеся на каждом из наборов процессоров, должны находиться в одном классе планирования во избежание конкуренции за один ЦП. Особенно следует избегать использования планировщика FX вместе с классом планирования FSS, за исключением случая использования наборов процессоров. Это позволяет предотвратить использование приложениями в классе FX приоритетов, достаточно высоких для отнятия ресурсов у приложений в классе FSS.

Процессы с классами планирования TS и IA можно комбинировать в одном наборе процессоров или в одной системе без наборов процессоров.

В системе Solaris также имеется планировщик реального времени (RT) для пользователей с полномочиями суперпользователя. По умолчанию класс планирования RT использует системные приоритеты из другого диапазона (обычно от 100 до 159), чем у FSS. Поскольку в RT и FSS используются непересекающиеся или, иначе говоря, не накладывающиеся друг на друга диапазоны приоритетов, FSS может сосуществовать с классом планирования RT в рамках одного набора процессоров. Однако класс планирования FSS не способен каким-либо образом управлять процессами, выполняющимися в классе RT.

Например, в четырехпроцессорной системе однопотоковый процесс RT может целиком потреблять один процессор, если процесс является зависящим от ЦП. Если в системе также работает FSS, обычные пользовательские процессы конкурируют за три оставшихся процессора, не используемые процессом RT. Следует отметить, что процесс RT не обязательно должен потреблять процессорные ресурсы непрерывно. Во время неактивности процесса RT все четыре процессора используются FSS.

Следующая команда позволяет определить, в каких классах планирования работают наборы процессоров, и убедиться в том, что для каждого набора процессоров настроено выполнение только процессов TS, IA, FX или FSS.

$ ps -ef -o pset,class | grep -v CLS | sort | uniq
1 FSS
1 SYS
2 TS
2 RT
3 FX

Настройка класса планирования в системе

Инструкции по настройке системного класса планирования по умолчанию приведены в Определение FSS в качестве класса планировщика по умолчанию, Класс планирования в зоне и dispadmin(1M). Инструкции по перемещению выполняемых процессов в другой класс планирования приведены в Настройка FSS и priocntl(1).

Класс планирования в системе с установленными зонами

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

В этом случае рекомендуется задать FSS как общесистемный класс планирования по умолчанию с помощью команды dispadmin. При этом процессорные ресурсы системы справедливо распределяются по всем зонам. Для получения дополнительной информации о классах планирования при использовании зон см. Класс планирования в зоне.

Для получения информации о перемещении выполняемых процессов в другой класс планирования без изменения класса планирования по умолчанию и без перезагрузки см. Таблица 26–5 и справочную страницу priocntl(1).

Команды, используемые с FSS

Команды, перечисленные в следующей таблице, обеспечивают основной административный интерфейс к планировщику долевого распределения.

Глава 9 Администрирование планировщика долевого распределения (задачи)

В этой главе описывается использование планировщика долевого распределения (FSS).

Краткое описание FSS приведены в Глава 8Планировщик долевого распределения (обзор). Для получения дополнительной информации о классах планирования при использовании зон см. Класс планирования в зоне.

Администрирование планировщика долевого распределения (карта задач)

Наблюдение за FSS

Для контроля использования ЦП активными проектами применяется команда prstat, описанная на справочной странице prstat(1M).

Для получения статистики потребления процессорных ресурсов в долгосрочной перспективе используются данные расширенного учета. См. Глава 4Расширенный учет (обзор).

Наблюдение за использованием ЦП в системе по проектам

1. Для контроля использования ЦП проектами, выполняющимися в системе, используется команда prstat с параметром -J.

   % prstat -J

Наблюдение за использованием ЦП проектами в наборах процессоров

1. Для контроля использования ЦП проектами в списке наборов процессоров можно воспользоваться следующей командой:

   % prstat -J -C pset-list

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

Настройка FSS

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

Следует отметить, что для перезапуска службы планировщика используется команда svcadm restart. Для получения дополнительной информации см. svcadm(1M).

Определение FSS в качестве класса планировщика по умолчанию

Для вступления в силу распределения долей ЦП FSS должен быть системным планировщиком по умолчанию.

Комбинация команд priocntl и dispadmin позволяет задать FSS в качестве планировщика по умолчанию как немедленно, так и после перезагрузки.

1. Перейдите в режим суперпользователя или воспользуйтесь эквивалентной ролью.

   Роли содержат подтвержденные полномочия и привилегированные команды. Для получения дополнительной информации о ролях см. Using the Solaris Management Tools With RBAC (Task Map) в System Administration Guide: Basic Administration.

2. Задайте FSS как системный планировщик по умолчанию.

   # dispadmin -d FSS

   Это изменение вступает в силу при следующей перезагрузке. После перезагрузки каждый процесс в системе выполняется в классе планирования FSS.

3. Эту конфигурацию можно принудительно применить немедленно, без перезагрузки.

   # priocntl -s -c FSS -i all

Перенос процессов из класса TS в класс FSS вручную

Процессы можно переносить вручную из одного класса планирования в другой без изменения класса планирования по умолчанию и без перезагрузки. Эта процедура позволяет переместить процессы из класса планирования TS в класс планирования FSS вручную.

1. Перейдите в режим суперпользователя или воспользуйтесь эквивалентной ролью.

   Роли содержат подтвержденные полномочия и привилегированные команды. Для получения дополнительной информации о ролях см. Using the Solaris Management Tools With RBAC (Task Map) в System Administration Guide: Basic Administration.

2. Переместите процесс init (PID 1) в класс планирования FSS.

   # priocntl -s -c FSS -i pid 1

3. Переместите все процессы из класса планирования TS в класс планирования FSS.

   # priocntl -s -c FSS -i class TS

   ---

   Примечание –

   После перезагрузки все процессы снова будут выполняться в классе планирования TS.

   ---

Перенос процессов из всех классов пользователей в класс FSS вручную

Может использоваться класс по умолчанию, отличный от TS. Например, в системе может работать оконная среда, использующая по умолчанию класс IA. Все процессы можно переместить вручную в класс планирования FSS без изменения класса планирования по умолчанию и без перезагрузки.

1. Перейдите в режим суперпользователя или воспользуйтесь эквивалентной ролью.

   Роли содержат подтвержденные полномочия и привилегированные команды. Для получения дополнительной информации о ролях см. Using the Solaris Management Tools With RBAC (Task Map) в System Administration Guide: Basic Administration.

2. Переместите процесс init (PID 1) в класс планирования FSS.

   # priocntl -s -c FSS -i pid 1

3. Переместите все процессы из текущих классов планирования в класс планирования FSS.

   # priocntl -s -c FSS -i all

   ---

   Примечание –

   После перезагрузки все процессы снова будут выполняться в классе планирования по умолчанию.

   ---

Перенос процессов проекта в класс FSS вручную

Процессы проекта можно переместить вручную из текущего класса планирования в класс планирования FSS.

1. Перейдите в режим суперпользователя или воспользуйтесь эквивалентной ролью.

   Роли содержат подтвержденные полномочия и привилегированные команды. Для получения дополнительной информации о ролях см. Using the Solaris Management Tools With RBAC (Task Map) в System Administration Guide: Basic Administration.

2. Переместите процессы, выполняющиеся в проекте с идентификатором 10, в класс планирования FSS.

   # priocntl -s -c FSS -i projid 10

   После перезагрузки процессы проекта снова будут выполняться в классе планирования по умолчанию.

Отладка параметров планировщика

Для просмотра или изменения параметров планировщика в работающей системе используется команда dispadmin. Так, команду dispadmin можно использовать для исследования и отладки значения шага квантования времени планировщика FSS. Шаг квантования времени – это время, в течение которого может выполняться поток до принудительного освобождения процессора.

Для отображения текущего шага квантования времени для планировщика FSS в работающей системе необходимо ввести следующую команду:

$ dispadmin -c FSS -g
#
# Fair Share Scheduler Configuration
#
RES=1000
#
# Time Quantum
#
QUANTUM=110

Если используется параметр -g, также можно использовать и параметр -r для указания разрешения, используемого для вывода значений шага квантования времени. Если разрешение не указано, то по умолчанию значения шага квантования времени отображаются в миллисекундах.

$ dispadmin -c FSS -g -r 100
#
# Fair Share Scheduler Configuration
#
RES=100
#
# Time Quantum
#
QUANTUM=11

Для настройки параметров планирования для класса планирования FSS используется команда dispadmin -s. Значения в файле файл должны иметь формат выходных данных параметра -g. Эти значения записываются поверх текущих значений в ядре. Введите следующие команды:

$ dispadmin -c FSS -s file

Глава 10 Управление физической памятью с помощью демона ограниченного выделения ресурсов (обзор)

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

Solaris 10 8/07: Если в системе имеются работающие зоны, для регулирования потребления физической памяти в неглобальных зонах используется демон rcapd в глобальной зоне. См. Глава 18Планирование и настройка неглобальных зон (задачи).

В этой главе рассматриваются следующие темы.

• Вводная информация по демону ограниченного выделения ресурсов

• Принцип действия ограниченного выделения ресурсов

• Атрибут ограничения использования физической памяти проектами

• Настройка rcapd

• Контроль использования ресурсов командой rcapstat

• Команды, используемые с rcapd

См. процедуры использования функции rcapd в Глава 11Администрирование демона ограниченного выделения ресурсов (задачи).

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

Solaris 10: Теперь командой projmod можно задать значение атрибута rcap.max-rss в файле /etc/project.

Solaris 10 11/06: Добавлена информация относительно включения и выключения демона ограниченного выделения ресурсов в форме службы в рамках механизма управления службами Solaris (SMF).

Полный список новых функций Solaris 10 и описание версий Solaris приведены в документе Solaris 10 What’s New.

Вводная информация по демону ограниченного выделения ресурсов

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

Демон ограниченного выделения ресурсов и связанные с ним утилиты предоставляют механизмы реализации и администрирования ограниченного выделения физической памяти.

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

Для получения информации о rcapdсм. справочную страницу rcapd(1M). Для получения информации о проектах и о базе данных project см. Глава 2Проекты и задачи (обзор) и справочную страницу project(4). Для получения информации об элементах управления ресурсами см. Глава 6Элементы управления ресурсами (обзор).

Принцип действия ограниченного выделения ресурсов

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

Физическая память разделяется системой виртуальной памяти на сегменты, называемые страницами. Страницы – фундаментальная единица физической памяти в подсистеме управления памятью Solaris. При чтении данных из файла в память система виртуальной памяти читает по одной странице за операцию, иначе говоря, происходит постраничное чтение файла. Для сокращения потребления ресурсов демон позволяет выполнить постраничный вывод, т. е. перемещение редко используемых страниц на устройство подкачки, представляющее собой область вне физической памяти.

Управление физической памятью осуществляется путем регулирования демоном размера резидентного набора рабочей нагрузки проекта по отношению к размеру его рабочего набора. Резидентный набор – это набор страниц, которые являются резидентными в физической памяти. Рабочий набор – это набор страниц, активно используемых рабочей нагрузкой в цикле ее обработки. Рабочий набор со временем изменяется в зависимости от режима работы процесса и от типа обрабатываемых данных. В идеальном случае каждая задача получает достаточное количество физической памяти для поддержания рабочего набора в резидентном состоянии. Однако для хранения рабочего набора может также использоваться вторичная дисковая память, позволяющая хранить данные, не вмещающиеся в физическую память.

В отдельно взятый момент времени может выполняться только один экземпляр rcapd.

Атрибут ограничения использования физической памяти проектами

Для установки ограничения ресурса физической памяти проекта необходимо определить размер резидентного набора (RSS) путем добавления этого атрибута к записи базы данных project:

rcap.max-rss

Общее количество физической памяти в байтах, доступное процессам в проекте.

Например, следующей строкой в файле /etc/project для проекта db задается ограничение RSS, равное 10 Гб.

db:100::db,root::rcap.max-rss=10737418240

Указанное значение может округляться до размера страницы.

Для установки атрибута rcap.max-rss в файле /etc/project можно использовать команду projmod:

# projmod -s -K rcap.max-rss=10GB db

После этого в файле /etc/project появляется следующая строка:

db:100::db,root::rcap.max-rss=10737418240

Настройка rcapd

Команду rcapadm можно использовать для настройки демона ограниченного выделения ресурсов. Имеются следующие возможности:

• установка порогового значения для принудительного ограничения;

• установка интервалов для операций, выполняемых rcapd;

• включение или отключение ограниченного выделения ресурсов;

• отображение текущего состояния настроенного демона ограниченного выделения ресурсов.

Для настройки демона необходимы полномочия суперпользователя или профиль управления процессами (Process Management) в списке профилей. Профиль управления процессами входит в роль управления процессами (Process Management) и в роль системного администратора (System Administrator).

Изменения конфигурации включаются в rcapd в соответствии с интервалом настройки (см. Интервалы операций rcapd) или по запросу, путем передачи сигнала SIGHUP (см. справочную страницу kill(1)).

Команда rcapadm без аргументов выводит текущее состояние демона ограниченного выделения ресурсов, если он настроен.

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

Использование демона ограниченного выделения ресурсов в системе с установленными зонами

Управление размером резидентного набора (RSS) зоны осуществляется путем настройки ресурса capped-memory при настройке зоны. Для получения дополнительной информации см. Solaris 10 8/07: Управление физической памятью и ресурс capped-memory. rcapd может выполняться внутри зоны, в том числе в глобальной зоне, для реализации в этой зоне ограничений по памяти.

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

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

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

Демон rcapd невозможно использовать в типизированной зоне lx. Однако для ограничения использования памяти в типизированной зоне может использоваться демон из глобальной зоны.

Порог принудительного ограничения памяти

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

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

• Постраничный вывод памяти выполняется для сокращения объема памяти, превышающего максимальное разрешенное значение для данной задачи.

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

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

Информацию по установке принудительного ограничения приведены в Установка порога принудительного ограничения памяти.

Определение ограничивающих значений

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

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

При определении ограничений для проектов необходимо учитывать следующие факторы.

Воздействие на систему ввода-вывода

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

Воздействие на нагрузку процессора

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

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

Другая часть процессорного времени демона затрачивается на реализацию ограничений при их превышении. Затраченное время находится в пропорциональной зависимости от количества задействованной виртуальной памяти. Необходимое процессорное время уменьшается или увеличивается в ответ на соответствующие изменения общего размера адресного пространства рабочей задачи. Эта информация отображается в столбце vm выходных данных команды rcapstat. Для получения дополнительной информации см. Контроль использования ресурсов командой rcapstat и справочную страницу rcapstat(1).

Создание отчетов по совместно используемой памяти

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

Данная оценка полезна при работе с базами данных и другими рабочими нагрузками, активно использующими общую память. Для рабочих нагрузок баз данных можно провести выборку использования памяти проектом для определения подходящего начального значения ограничения, используя результаты выполнения команды prstat с параметрами -J или -Z. Для получения дополнительных сведений см. справочную страницу prstat(1M).

Интервалы операций rcapd

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

Все интервалы указываются в секундах. Операции rcapd и стандартные значения их интервалов описаны в следующей таблице.

Инструкции по настройке интервалов приведены в Установка интервалов операций.

Определение интервалов сканирования rcapd

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

Определение интервалов выборки

Интервал выборки, настроенный командой rcapadm, представляет собой минимальный интервал времени ожидания rcapd между выборкой показателей потребления памяти рабочей нагрузкой и принудительным ограничением в случае превышения. В случае уменьшения этого интервала частота применения ограничений демоном rcapd обычно возрастает, что может привести к увеличению объема ввода-вывода вследствие подкачки страниц. Однако более короткий интервал выборки может также снизить воздействие внезапного скачка в потреблении физической памяти определенной рабочей нагрузкой на другие задачи. Интервал между операциями выборки, в течение которого память потребляется рабочей нагрузкой без ограничений, и, возможно, отбирается память у других ограниченных нагрузок, сужается.

Если интервал выборки, указанный для команды rcapstat, меньше интервала, указанного для команды rcapd c rcapadm, выходные данные для некоторых интервалов могут быть нулевыми. Это вызвано тем, что частота обновления статистики rcapd меньше интервала, указанного командой rcapadm. Интервал, указанный командой rcapadm , не зависит от интервала выборки, используемого командой rcapstat.

Контроль использования ресурсов командой rcapstat

Команда rcapstat позволяет контролировать использование ресурсов проектами, для которых установлены ограничения по памяти. Пример отчета rcapstat cм. в Создание отчетов командой rcapstat.

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

интервал

Интервал выборки в секундах. По умолчанию используется интервал, равный 5 секундам.

число

Число повторений статистики. По умолчанию rcapstat выводит статистику до поступления сигнала прерывания или до выхода процесса rcapd.

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

В следующей таблице описаны заголовки столбцов в отчете rcapstat.

Команды, используемые с rcapd

Глава 11 Администрирование демона ограниченного выделения ресурсов (задачи)

В этой главе содержатся процедуры настройки и использования демона ограниченного выделения ресурсов rcapd.

Обзор демона rcapd приведены в Глава 10Управление физической памятью с помощью демона ограниченного выделения ресурсов (обзор).

Настройка и использование демона ограниченного выделения ресурсов (карта задач)

Управление демоном ограниченного выделения ресурсов командой rcapadm

В этом разделе приведены процедуры настройки демона ограниченного выделения ресурсов командой rcapadm. Для получения дополнительной информации см. раздел Настройка rcapd и справочную страницу rcapadm(1M). Также рассматривается настройка временного ограничения выделения ресурсов с помощью команды rcapadm

Команда rcapadm без аргументов выводит текущее состояние демона ограниченного выделения ресурсов, если он настроен.

Установка порога принудительного ограничения памяти

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

Минимальное значение (оно же значение по умолчанию) равно 0, т. е. ограничения применяются всегда. Приведенная ниже процедура позволяет задать другое минимальное значение.

1. Перейдите в режим суперпользователя или воспользуйтесь ролью, включающей в себя профиль управления процессами (Process Management).

   Профиль управления процессами входит в роль системного администратора (System Administrator). Для получения информации о создании роли и назначении роли пользователю см. раздел "Управление RBAC (карта задач)" в документе Руководство по системному администрированию: службы безопасности.

2. Для установки другого значения использования памяти, при котором должно применяться ограничение памяти, используется параметр -c команды rcapadm.

   # rcapadm -c percent

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

См. также

Инструкции по просмотру текущего потребления физической памяти и порога принудительного ограничения приведены в Создание отчетов по использованию памяти и порогу принудительного ограничения памяти.

Установка интервалов операций

В разделе Интервалы операций rcapd приводится информация об интервалах периодических операций, выполняемых демоном rcapd. Приведенная ниже процедура позволяет задать интервалы операций командой rcapadm.

1. Перейдите в режим суперпользователя или воспользуйтесь ролью, включающей в себя профиль управления процессами (Process Management).

   Профиль управления процессами входит в роль системного администратора (System Administrator). Для получения информации о создании роли и назначении роли пользователю см. раздел "Управление RBAC (карта задач)" в документе Руководство по системному администрированию: службы безопасности.

2. Для установки значений интервалов используется параметр -i.

   # rcapadm -i interval=value,...,interval=value

   ---

   Примечание –

   Все значения интервалов указываются в секундах.

   ---

Включение ограниченного выделения ресурсов

Существует три способа включения ограниченного выделения ресурсов в системе. При включении ограниченного выделения ресурсов в файле /etc/rcap.conf выставляются значения по умолчанию.

1. Перейдите в режим суперпользователя или воспользуйтесь ролью, включающей в себя профиль управления процессами (Process Management).

   Профиль управления процессами входит в роль системного администратора (System Administrator). Для получения информации о создании роли и назначении роли пользователю см. раздел "Управление RBAC (карта задач)" в документе Руководство по системному администрированию: службы безопасности.

2. Демон ограниченного выделения ресурсов включается одним из следующих способов:

   • Включение ограниченного выделения ресурсов командой svcadm.

     # svcadm enable rcap

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

     # rcapadm -E

   • Для включения демона ограниченного выделения ресурсов при каждой загрузке без немедленного запуска необходимо также указать параметр -n:

     # rcapadm -n -E

Отключение демона ограниченного выделения ресурсов

Существует три способа отключения ограниченного выделения ресурсов в системе.

1. Перейдите в режим суперпользователя или воспользуйтесь ролью, включающей в себя профиль управления процессами (Process Management).

   Профиль управления процессами входит в роль системного администратора (System Administrator). Для получения информации о создании роли и назначении роли пользователю см. раздел "Управление RBAC (карта задач)" в документе Руководство по системному администрированию: службы безопасности.

2. Демон ограниченного выделения ресурсов отключается одним из следующих способов:

   • Отключение ограниченного выделения ресурсов командой svcadm.

     # svcadm disable rcap

   • Для отключения демона ограниченного выделения ресурсов с немедленной остановкой и отменой запуска при загрузке системы необходимо ввести следующую команду:

     # rcapadm -D

   • Для отключения демона ограниченного выделения ресурсов без немедленной остановки следует также указать параметр -n:

     # rcapadm -n -D

   ---

   Совет –

   Безопасное отключение демона ограниченного выделения ресурсов

   ---

   Для безопасного отключения демона rcapd используется команда svcadm или rcapadm с параметром -D. В случае остановки демона командой kill (см. справочную страницу kill(1)) процессы могут остаться в остановленном состоянии до их перезапуска вручную. Для возобновления работы процесса используется команда prun. Для получения дополнительной информации см. справочную страницу prun(1).

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

Эта процедура предназначена для выделения максимального объема памяти, доступного для потребления указанной зоной. Значение остается действительным до ближайшей перезагрузки. Для настройки постоянно действующего ограничения используется команда zonecfg

1. Перейдите в режим суперпользователя или воспользуйтесь ролью, включающей в себя профиль управления процессами (Process Management).

   Профиль управления процессами входит в роль системного администратора (System Administrator).

2. Настройте для зоны my-zone ограничение памяти в размере 512 МБ.

   # rcapadm -z testzone -m 512M

Создание отчетов командой rcapstat

Для создания отчетов по статистике ограниченного выделения ресурсов используется команда rcapstat. Создание отчетов командой rcapstat описано в разделе Контроль использования ресурсов командой rcapstat . В этом разделе также описываются заголовки столбцов отчета. Эта информация также представлена на справочной странице rcapstat(1).

В следующих подразделах приводятся примеры создания отчетов в различных целях.

Создание отчетов об ограниченном использовании ресурсов и о проектах

В этом примере ограничения определены для двух проектов, связанных с двумя пользователями. Ограничение для user1 равно 50 Мб, а для user2 – 10 Мб.

Следующая команда создает пять отчетов с 5-секундным интервалом выборки.

user1machine% rcapstat 5 5
    id project  nproc     vm    rss   cap    at avgat    pg avgpg
112270   user1     24   123M    35M   50M   50M    0K 3312K    0K
 78194   user2      1  2368K  1856K   10M    0K    0K    0K    0K
    id project  nproc     vm    rss   cap    at avgat    pg avgpg
112270   user1     24   123M    35M   50M    0K    0K    0K    0K
 78194   user2      1  2368K  1856K   10M    0K    0K    0K    0K
    id project  nproc     vm    rss   cap    at avgat    pg avgpg
112270   user1     24   123M    35M   50M    0K    0K    0K    0K
 78194   user2      1  2368K  1928K   10M    0K    0K    0K    0K
    id project  nproc     vm    rss   cap    at avgat    pg avgpg
112270   user1     24   123M    35M   50M    0K    0K    0K    0K
 78194   user2      1  2368K  1928K   10M    0K    0K    0K    0K
    id project  nproc     vm    rss   cap    at avgat    pg avgpg
112270   user1     24   123M    35M   50M    0K    0K    0K    0K
 78194   user2      1  2368K  1928K   10M    0K    0K    0K    0K 

Первые три строки результата составляют первый отчет, содержащий информацию об ограничении и о двух рассматриваемых проектах, а также статистику подкачки страниц с момента запуска rcapd. В столбцах at и pg содержится положительное число для user1 и нуль для user2; это означает, что в определенный момент в истории демона user1 превысил ограничение, а в случае user2 этого не произошло.

В последующих отчетах особой активности не наблюдается.

Контроль RSS проекта

В следующем примере показан проект user1, RSS которого превосходит ограничение.

Следующая команда создает пять отчетов с 5-секундным интервалом выборки.

user1machine% rcapstat 5 5

    id project  nproc    vm   rss   cap    at avgat     pg  avgpg
376565   user1      3 6249M 6144M 6144M  690M  220M  5528K  2764K
376565   user1      3 6249M 6144M 6144M    0M  131M  4912K  1637K
376565   user1      3 6249M 6171M 6144M   27M  147M  6048K  2016K
376565   user1      3 6249M 6146M 6144M 4872M  174M  4368K  1456K
376565   user1      3 6249M 6156M 6144M   12M  161M  3376K  1125K

Три процесса проекта user1 активно используют физическую память. Положительные значения в столбце pg указывают, что rcapd постоянно выполняет подкачку страниц памяти, пытаясь реализовать ограничение путем снижения потребления физической памяти процессами проекта. Однако демону rcapd не удается удержать RSS ниже порогового значения. На это указывают переменчивые значения rss, не отражающие соответствующего снижения. Сразу же после выполнения постраничного вывода памяти она снова используется рабочей нагрузкой, и счетчик RSS снова увеличивается. Это означает, что активно используется вся резидентная память проекта, и размер рабочего набора (WSS) превышает ограничение. Таким образом, для поддержания ограничения демону rcapd приходится выполнять постраничный вывод части рабочего набора. В этих условиях в системе будет по-прежнему наблюдаться высокая частота ошибок отсутствия страниц и связанная с этим высокая нагрузка на ввод/вывод, пока не будет выполнено одно из перечисленных ниже действий:

• уменьшение WSS;

• повышение значения ограничения;

• изменение приложением режима доступа к памяти.

В этой ситуации сокращение интервала выборки может привести к снижению расхождения между значением RSS и значением ограничения путем более частой выборки рабочей нагрузки и реализации ограничений демоном rcapd.

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

Определение размера рабочего набора проекта

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

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

user1machine% rcapstat 5 5
    id project  nproc    vm   rss   cap    at avgat     pg  avgpg
376565   user1      3 6249M 6144M 6144M  690M    0K   689M     0K
376565   user1      3 6249M 6144M 6144M    0K    0K     0K     0K
376565   user1      3 6249M 6171M 6144M   27M    0K    27M     0K
376565   user1      3 6249M 6146M 6144M 4872K    0K  4816K     0K
376565   user1      3 6249M 6156M 6144M   12M    0K    12M     0K
376565   user1      3 6249M 6150M 6144M 5848K    0K  5816K     0K
376565   user1      3 6249M 6155M 6144M   11M    0K    11M     0K
376565   user1      3 6249M 6150M   10G   32K    0K    32K     0K
376565   user1      3 6249M 6214M   10G    0K    0K     0K     0K
376565   user1      3 6249M 6247M   10G    0K    0K     0K     0K
376565   user1      3 6249M 6247M   10G    0K    0K     0K     0K
376565   user1      3 6249M 6247M   10G    0K    0K     0K     0K
376565   user1      3 6249M 6247M   10G    0K    0K     0K     0K
376565   user1      3 6249M 6247M   10G    0K    0K     0K     0K
376565   user1      3 6249M 6247M   10G    0K    0K     0K     0K

В середине цикла ограничение для проекта user1 было увеличено с 6 ГБ до 10 ГБ. Это увеличение позволяет прекратить принудительное ограничение и нарастить размер резидентного набора, ограниченный только другими процессами и объемом памяти в компьютере. Столбец rss может стабилизироваться на размере рабочего набора проекта (WSS), в этом примере – 6247M. Это минимальное значение ограничения, позволяющее процессам проекта работать без постоянных ошибок отсутствия страниц.

Несмотря на то что для user1 установлено ограничение 6 Гб, в каждом 5-секундном интервале выборки RSS снижается, а ввод-вывод растет по мере постраничного вывода демоном rcapd части памяти рабочей нагрузки. Вскоре после завершения постраничного вывода задача, требующая наличия этих страниц для своей работы, выполняет обратный постраничный ввод. Цикл повторяется, пока ограничение не увеличивается до 10 Гб примерно в середине примера. RSS затем стабилизируется на 6,1 Гб. Поскольку RSS рабочей нагрузки теперь не превышает ограничение, подкачки страниц не происходит. Ввод-вывод, связанный с подкачкой страниц, также прекращается. Таким образом, для работы проекта в момент наблюдения требуется 6,1 Гб.

Также см. справочные страницы vmstat(1M) и iostat(1M).

Создание отчетов по использованию памяти и порогу принудительного ограничения памяти

Параметр -g команды rcapstat может использоваться для создания следующих отчетов:

• текущее использование физической памяти как процент от физической памяти, установленной в системе;

• Системный порог принудительного ограничения памяти, заданный командой rcapadm;

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

# rcapstat -g
    id project   nproc    vm   rss   cap    at avgat   pg  avgpg
376565    rcap       0    0K    0K   10G    0K    0K   0K     0K
physical memory utilization: 55%   cap enforcement threshold: 0%
    id project   nproc    vm   rss   cap    at avgat   pg  avgpg
376565    rcap       0    0K    0K   10G    0K    0K   0K     0K
physical memory utilization: 55%   cap enforcement threshold: 0%

Глава 12 Пулы ресурсов (обзор)

В этой главе рассматриваются следующие функциональные возможности:

• пулы ресурсов, используемые для распределения ресурсов компьютера;

• динамические пулы ресурсов (DRP), используемые для динамического регулирования распределения ресурсов каждого пула в соответствии с общесистемными целями.

Начиная с Solaris 10 11/06, пулы ресурсов и динамические пулы ресурсов являются службами в механизме управления службами Solaris (SMF). Каждая из этих служб включается отдельно.

В этой главе рассматриваются следующие темы:

• Введение в пулы ресурсов

• Введение в динамические пулы ресурсов

• Включение и выключение пулов ресурсов и динамических пулов ресурсов

• Использование пулов ресурсов в зонах

• Рекомендации по использованию пулов

• Архитектура пулов ресурсов

• Реализация пулов в системе

• Атрибут project.pool

• SPARC: Операции динамической перенастройки и пулы ресурсов

• Создание конфигураций пулов

• Непосредственное управление динамической конфигурацией

• Обзор poold

• Управление динамическими пулами ресурсов

• Ограничения и целевые показатели конфигураций

• Настраиваемые функции poold

• Принцип действия динамического распределения ресурсов

• Наблюдение за механизмом пулов и степени использования ресурсов командой poolstat

• Команды, используемые с механизмом пулов ресурсов

См. процедуры использования этих функциональных возможностей в Глава 13Создание и администрирование пулов ресурсов (задачи).

Новые функции и возможности пулов ресурсов и динамических пулов ресурсов

Solaris 10: Пулы ресурсов теперь обеспечивают механизм регулирования распределения ресурсов каждого пула в ответ на системные события и на изменение нагрузки приложений. Динамические пулы ресурсов позволяют упростить и сократить количество решений, которые должны приниматься администратором. Регулирование проводится автоматически, причем сохраняются целевые показатели производительности системы, установленные администратором.

Теперь командой projmod можно задать значение атрибута project.pool в файле /etc/project.

Полный список новых функций Solaris 10 и описание версий Solaris приведены в Solaris 10 What’s New.

Solaris 10 11/06: Пулы ресурсов и динамические пулы ресурсов теперь являются службами SMF.

Введение в пулы ресурсов

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

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

Рисунок 12–1 Архитектура пулов ресурсов

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

Группирование разделов в пулы позволяет получить метку-манипулятор для связывания с отмеченными рабочими нагрузками. С каждой записью проекта в файле /etc/project может быть связан один пул, указываемый с помощью атрибута project.pool.

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

Свойство pool.default пула по умолчанию имеет значение true. Свойство pset.default набора процессоров по умолчанию имеет значение true. Таким образом обеспечивается возможность определения пула и набора процессоров по умолчанию даже в случае изменения их имен.

Механизм пулов, определяемых пользователем, предназначен в основном для использования на крупных машинах с количеством ЦП более четырех. Однако эта функциональная возможность может быть реализована и в небольших системах. В таких системах можно создать пулы, совместно использующие некритические разделы ресурсов. Эти пулы разделяются только по критическим ресурсам.

Введение в динамические пулы ресурсов

Динамические пулы ресурсов обеспечивают механизм динамического регулирования распределения ресурсов каждого пула в ответ на системные события и изменение нагрузки приложений. Динамические пулы ресурсов позволяют упростить и сократить количество решений, которые должны приниматься администратором. Регулирование проводится автоматически, причем сохраняются целевые показатели производительности системы, установленные администратором. Изменения, вносимые в конфигурацию, заносятся в журнал. Эти функции в основном реализуются через контроллер ресурсов poold – системный демон, который всегда должен быть активен при работе с динамическим распределением ресурсов. Демон poold периодически исследует нагрузку на систему и определяет, требуется ли вмешательство администратора для обеспечения оптимальной производительности системы в отношении потребления ресурсов. Конфигурация poold содержится в конфигурации libpool. Для получения дополнительной информации о poold см. справочную страницу poold(1M).

Включение и выключение пулов ресурсов и динамических пулов ресурсов

Информацию по включению и выключению пулов ресурсов и динамических пулов ресурсов приведены в Включение и отключение механизма пулов.

Использование пулов ресурсов в зонах

Solaris 10 8/07: В качестве альтернативы связыванию зоны с настроенным пулом ресурсов можно создать командой zonecfg временный пул, действующий во время работы зоны. Для получения дополнительной информации см. Solaris 10 8/07: Ресурс dedicated-cpu.

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

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

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

Средство poolstat, выполняемая в неглобальной зоне, выводит информацию только о том пуле, который связан с зоной. Команда pooladm, запущенная без аргументов в неглобальной зоне, отображает информацию только о пуле, связанном с зоной.

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

Рекомендации по использованию пулов

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

Пакетный вычислительный сервер

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

Сервер приложений или сервер базы данных

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

Включение приложений по фазам

Формирование ожиданий пользователей.

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

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

Сервер со сложным разделением времени

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

Разделение пользователей на группы, связанные с разными пулами, и применение планировщика долевого распределения (FSS) позволяет отрегулировать распределение процессоров с учетом требований приоритетных групп пользователей. Это назначение может основываться на роли пользователя, стратегиях гибкого управления ресурсами на основе данных учета и т.д.

Рабочие нагрузки, подверженные сезонному изменению

Пулы ресурсов можно использовать для адаптации к меняющимся потребностям.

Потребности рабочих нагрузок могут испытывать предсказуемые изменения в течение длительных периодов времени, таких как месячные, квартальные или годичные циклы. Если система подвержена подобным сдвигам, можно организовать поочередную смену нескольких конфигураций ресурсов вызовом команды pooladm из задания cron. См. Архитектура пулов ресурсов.

Приложения реального времени

Пул реального времени создается с использованием планировщика RT и соответствующих ресурсов процессора.

Использование системы

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

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

Архитектура пулов ресурсов

В файле конфигурации /etc/pooladm.conf описывается статическая настройка пулов. Статическая конфигурация – это представление требуемого администратором способа настройки системы в отношении функциональных возможностей пулов ресурсов. Допускается альтернативное имя файла.

Если архитектура пулов ресурсов реализуется с помощью механизма управления обслуживанием (SMF) или командой pooladm - e, то при наличии файла /etc/pooladm.conf к системе применяется содержащаяся в нем конфигурация.

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

• косвенно – путем применения файла статической конфигурации;

• непосредственно – командой poolcfg с параметром -d.

Может существовать несколько файлов статической конфигурации пулов, которые активируются в разных случаях. Переключение между несколькими конфигурациями пулов осуществляется путем вызова команды pooladm из задания cron. Для получения дополнительной информации об утилите cron см. справочную страницу cron(1M).

По умолчанию архитектура пулов ресурсов не активна. Для создания или изменения динамической конфигурации пулы ресурсов необходимо активировать. Даже если структура пулов ресурсов отключена, управление файлами статической конфигурации можно осуществлять с помощью команд poolcfg и libpool. Создать файлы статической конфигурации при неактивном механизме пулов невозможно. Для получения дополнительной информации о файле конфигурации см. Создание конфигураций пулов.

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

• pooladm(1M)

• poolbind(1M)

• poolcfg(1M)

• poold(1M)

• poolstat(1M)

• libpool(3LIB)

Содержимое файла /etc/pooladm.conf

Все конфигурации пулов ресурсов, включая динамическую конфигурацию, могут содержать следующие элементы.

system

Свойства, воздействующие на общее поведение системы.

pool

Определение пула ресурсов.

pset

Определение набора процессоров.

cpu

Определение процессора.

Все эти элементы обладают свойствами, которыми можно управлять в целях изменения состояния и поведения архитектуры пулов ресурсов. Например, свойство пула pool.importance указывает относительную важность данного пула. Это свойство используется для разрешения потенциальных конфликтов из-за ресурсов. Для получения дополнительной информации см. libpool(3LIB).

Свойства пулов

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

Например, следующий комментарий означает, что данный набор процессоров (pset) связан с базой данных Datatree.

Datatree,pset.dbname=warehouse

Для получения дополнительной информации о типах свойств см. Свойства poold.

Некоторые специальные свойства зарезервированы для внутреннего использования, и их невозможно установить или удалить. Для получения дополнительной информации см. справочную страницу libpool(3LIB).

Реализация пулов в системе

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

• При загрузке программного обеспечения Solaris сценарий init проверяет, существует ли файл /etc/pooladm.conf. Если этот файл существует и механизм пулов активирован, вызывается pooladm, который определяет эту конфигурацию пулов как активную. Создается динамическая конфигурация, отражающая организацию согласно /etc/pooladm.conf, и ресурсы компьютера распределяются соответствующим образом.

• Во время работы системы Solaris конфигурацию пулов можно либо активировать, если она еще не активна, либо изменить командой pooladm. По умолчанию команда pooladm работает с файлом /etc/pooladm.conf. Однако при необходимости можно указать альтернативное расположение и имя файла, который должен использоваться для обновления конфигурации пулов.

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

Для настройки пулов ресурсов необходимы полномочия суперпользователя или профиль управления процессами (Process Management) в списке профилей. Профиль управления процессами входит в роль системного администратора (System Administrator).

Вместе с механизмом динамических пулов ресурсов запускается контроллер ресурсов poold.

Атрибут project.pool

Атрибут project.pool добавляется к записи проекта в файле /etc/project для связывания с этой записью отдельного пула. Новые рабочие нагрузки, запускаемые в проекте, привязываются к соответствующему пулу. Для получения дополнительной информации см. Глава 2Проекты и задачи (обзор).

Например, команду projmod можно использовать для установки атрибута project.pool для проекта sales в файле /etc/project:

# projmod -a -K project.pool=mypool sales

SPARC: Операции динамической перенастройки и пулы ресурсов

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

Если операция DR может быть выполнена без нарушения допустимости текущей конфигурации пулов, обновляется частный файл конфигурации. Недопустимая конфигурация – это конфигурация, не поддерживаемая доступными ресурсами.

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

При использовании динамических пулов ресурсов следует помнить о возможности вывода раздела из-под контроля активного демона poold. Для получения дополнительной информации см. Определение дефицита ресурсов.

Создание конфигураций пулов

Описание создаваемых в системе пулов содержится в файле конфигурации. В этом файле описываются настраиваемые элементы.

• system

• pool

• pset

• cpu

Для получения дополнительной информации о настраиваемых элементах см. poolcfg(1M).

При включенных пулах структурированный файл /etc/pooladm.conf создается одним из двух способов.

• Командой pooladm с параметром - s, которая выполняет процедуру обнаружения ресурсов в текущей системе и помещает результаты в файл конфигурации.

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

• Также можно создать новую конфигурацию пулов командой poolcfg с параметром - c и подкомандами discover или create system имя.

  Эти параметры сохранены для обеспечения обратной совместимости с предыдущей версией.

Для изменения файла /etc/pooladm.conf используются команды poolcfg или libpool. Этот файл не следует редактировать непосредственно.

Непосредственное управление динамической конфигурацией

Типами процессорных ресурсов в динамической конфигурации можно управлять непосредственно с помощью команды poolcfg с параметром -d. Для передачи ресурсов используются два метода:

• общий запрос на передачу всех доступных обнаруженных ресурсов между наборами;

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

См. пример в Перенос ресурсов.

Следует отметить, что перенос ресурсов может вызвать выполнение действий демоном poold. Для получения дополнительной информации см. Обзор poold.

Обзор poold

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

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

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

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

Управление динамическими пулами ресурсов

Управление службой DRP осуществляется механизмом управления службами (SMF) под идентификатором svc:/system/pools/dynamic.

Административные действия в отношении этой службы, например включение, выключение или запрос перезапуска, можно выполнять командой svcadm. Запрос состояния службы можно выполнить с помощью команды svcs Для получения дополнительной информации см. справочные страницы svcs(1) и svcadm(1M).

Интерфейс SMF является рекомендуемым методом управления DRP, однако для обратной совместимости могут использоваться методы, перечисленные ниже.

• Если динамическое распределение ресурсов не требуется, poold можно остановить сигналом SIGQUIT или SIGTERM. Оба сигнала приводят к корректному завершению работы poold.

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

Ограничения и целевые показатели конфигураций

При изменении конфигурации контроллер ресурсов poold действует в соответствии с предоставленными ему директивами. Они указываются в виде ряда ограничений и целевых показателей. Эти спецификации используются poold для определения относительной целесообразности вариантов настройки по сравнению с существующей конфигурацией. Затем poold изменяет распределение ресурсов текущей конфигурации и генерирует новые конфигурации-кандидаты.

Ограничения в конфигурации

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

• минимальное и максимальное выделение ЦП;

• прикрепленные компоненты, которые запрещается исключать из набора.

Для получения дополнительной информации о свойствах пулов см. справочную страницу libpool(3LIB) и Свойства пулов.

Ограничения посредством свойств pset.min и pset.max

Эти два свойства ограничивают минимальное и максимальное количество процессоров, которые можно выделить в набор процессоров. Дополнительную информацию об этих свойствах приведены в Таблица 12–1.

Ресурсы из раздела ресурсов доступны для выделения другим разделам ресурсов в том же экземпляре Solaris в рамках этих ограничений. Доступ к ресурсу обеспечивается путем привязки к пулу, связанному с набором ресурсов. Привязка выполняется при регистрации или вручную администратором с полномочиями PRIV_SYS_RES_CONFIG.

Ограничения посредством свойства cpu.pinned

Свойство cpu-pinned указывает, что определенный процессор не должен покидать набор процессоров, в котором он расположен, в результате действий DPR. Это свойство libpool можно использовать для максимизации использования кэша определенным приложением, выполняющимся внутри набора процессоров.

Дополнительную информацию об этом свойстве приведены в Таблица 12–1.

Ограничения посредством свойства pool.importance

Свойство pool.importance описывает относительную важность пула в соответствии с определением, заданным администратором.

Целевые показатели конфигурации

Целевые показатели задаются аналогично ограничениям. Полный перечень целевых показателей представлен в Таблица 12–1.

Существуют две категории целевых показателей.

Показатели, зависящие от рабочей нагрузки

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

Показатели, не зависящие от рабочей нагрузки

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

Можно определить три типа целевых показателей.

Целевые показатели хранятся в строках свойств в конфигурации libpool. Используются следующие имена свойств:

• system.poold.objectives

• pset.poold.objectives

Для целевых показателей используется следующий синтаксис:

• objectives = objective [; objective]*

• objective = [n:] keyword [op] [value]

Ко всем целевым показателям можно присоединить дополнительный префикс важности. Важность используется в качестве множителя для целевого показателя и, таким образом, повышает значимость вклада этого показателя в функцию анализа. Диапазон допустимых значений – от 0 до INT64_MAX (9223372036854775807). Если не указано иное, используется значение важности по умолчанию, равное 1.

Некоторые типы элементов поддерживают несколько типов целевых показателей. Примером такого элемента может служить pset. Для подобных элементов можно задавать несколько типов целевых показателей. Можно также определить несколько показателей использования для одного элемента pset.

См. примеры использования в Определение целевых показателей конфигурации.

Целевой показатель wt-load

Целевой показатель wt-load отдает предпочтение конфигурациям, в которых распределение ресурсов сопоставляется с использованием ресурсов. В случае активности этого целевого показателя набору ресурсов, использующему больше ресурсов, выделяется больше ресурсов. Название wt-load расшифровывается как взвешенная нагрузка.

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

Целевой показатель locality

Целевой показатель locality влияет на воздействие, оказываемое локальностью, которая определяется по данным группы местоположений (lgroup), на выбранную конфигурацию. Локальность также можно определить как задержку. Группа lgroup описывает ресурсы памяти и ЦП. Группа lgroup используется в Solaris для определения расстояния между ресурсами в единицах времени. Для получения дополнительной информации о выделении группы местоположения см. раздел Locality Groups Overview в Programming Interfaces Guide.

Этому целевому показателю может соответствовать одно из трех значений:

tight

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

loose

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

none

При выборе данного значения локальность не влияет на предпочтительность конфигурации. Это значение задается для показателя locality по умолчанию.

Как правило, для целевого показателя locality следует устанавливать значение tight. Однако в целях максимизации полосы пропускания памяти или минимизации воздействия операций DR на набор ресурсов для этого показателя можно установить значение loose или оставить значение по умолчанию none.

Целевой показатель utilization

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

Этот показатель задается с помощью знаков операций и значений. Для этого используются следующие знаки операций:

<

Знак операции "меньше чем" указывает, что данное значение соответствует максимальному целевому значению.

>

Знак операции "больше чем" указывает, что данное значение соответствует минимальному целевому значению.

~

Знак операции "about" означает, что данное значение представляет собой целевое значение, для которого возможны некоторые колебания.

Для набора процессоров (pset) можно задать только один показатель "utilization" со знаком операции каждого типа.

• Если задан знак операции ~, ввести знаки операций < и > невозможно.

• Если заданы знаки операций < и >, невозможным становится указание знака операции ~. Следует отметить, что настройки знаков операций < и > не могут противоречить друг другу.

Совместное использование знаков операций < и > позволяет задать диапазон. Значения проверяются на допустимость во избежание их перекрывания.

Пример целевых показателей конфигурации

В следующем примере демону poold необходимо оценить следующие целевые показатели набора процессоров:

• Показатель utilization должен иметь значение между 30 и 80 процентами.

• Показатель locality для набора процессоров должен быть максимальным.

• Для этих показателей устанавливается важность по умолчанию, равная 1.

Пример 12–1 Пример целевых показателей poold

pset.poold.objectives "utilization > 30; utilization < 80; locality tight"

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

Свойства poold

Существуют четыре категории свойств:

• Конфигурация

• Ограничение

• Целевой показатель

• Параметр целевого показателя

Настраиваемые функции poold

Настройке подлежат следующие аспекты поведения демона:

• интервал наблюдения;

• уровень журналирования;

• место журналирования.

Эти параметры задаются в конфигурации пулов. Уровнем журналирования также можно управлять из командной строки вызовом демона poold.

Интервал наблюдения poold

Значение свойства system.poold.monitor-interval указывается в миллисекундах.

Информация журналирования poold

Журналирование позволяет регистрировать информацию трех категорий. Это следующие категории:

• Конфигурация

• Наблюдение

• Оптимизация

Имя свойства system.poold.log-level используется для указания параметра журналирования. Если это свойство не указано, используется уровень журналирования по умолчанию – NOTICE. Уровни параметра формируют иерархию. При уровне журналирования DEBUG демон poold регистрирует все сообщения. Уровень INFO соответствует среднему уровню информации, удобному для большинства администраторов.

Для указания уровня информации, записываемой в журнал, можно воспользоваться командой poold с параметром -l в командной строке.

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

• ALERT

• CRIT

• ERR

• WARNING

• NOTICE

• INFO

• DEBUG

Уровни параметра непосредственно соответствуют их эквивалентам syslog. Для получения дополнительной информации об использовании syslog см. Место журналирования.

Для получения дополнительной информации о настройке журналирования poold см. Настройки уровня журналирования poold.

Журналирование конфигурационной информации

Возможна генерация сообщений следующих типов:

ALERT

Проблемы при доступе к конфигурации libpool или иной непредвиденный отказ механизма libpool. Подобные проблемы вызывают завершение работы демона и требуют немедленного внимания администратора.

CRIT

Проблемы вследствие непредвиденных отказов. Подобные проблемы вызывают завершение работы демона и требуют немедленного внимания администратора.

ERR

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

WARNING

Предупреждения, связанные с установкой параметров конфигурации, которые, будучи технически корректными, могут не подходить для данной среды выполнения. В качестве примера можно привести маркировку всех процессорных ресурсов как прикрепленных, что приводит к невозможности перемещения ресурсов ЦП между наборами процессоров демоном poold.

DEBUG

Сообщения, содержащие подробную информацию, требуемую при отладке конфигурации. Эта информация, как правило, не используется администраторами.

Наблюдение за журналированием

Возможна генерация сообщений следующих типов:

CRIT

Проблемы из-за непредвиденных отказов наблюдения. Подобные проблемы вызывают завершение работы демона и требуют немедленного внимания администратора.

ERR

Проблемы из-за непредвиденных ошибок наблюдения. Для исправления подобных ошибок может потребоваться административное вмешательство.

NOTICE

Сообщения о достижении границ, задаваемых элементами управления ресурсами.

INFO

Сообщения о статистике использования ресурсов.

DEBUG

Сообщения, содержащие подробную информацию, требуемую при отладке наблюдения. Эта информация, как правило, не используется администраторами.

Журналирование оптимизации

Возможна генерация сообщений следующих типов:

WARNING

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

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

NOTICE

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

INFO

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

DEBUG

Сообщения, содержащие подробную информацию, требуемую для отладки оптимизации. Эта информация, как правило, не используется администраторами.

Место журналирования

Для указания местоположения для вывода в журнал демоном poold используется свойство system.poold.log-location. Для команд poold можно указать местоположение SYSLOG (см. syslog(3C)).

Если это свойство не указано, в качестве местоположения по умолчанию для журнального вывода poold используется /var/log/pool/poold.

При вызове poold из командной строки это свойство не используется. Журнальные записи выводятся в stderr вызывающего терминала.

Управление журналированием с помощью logadm

Если активен демон poold, в файле logadm.conf содержится запись, позволяющая управлять файлом по умолчанию /var/log/pool/poold. Эта запись имеет следующий вид:

/var/log/pool/poold -N -s 512k

См. справочные страницы logadm(1M) и logadm.conf(4).

Принцип действия динамического распределения ресурсов

В этом разделе рассматривается процесс динамического выделения ресурсов демоном poold и влияющие на него факторы.

Доступные ресурсы

Доступными считаются все ресурсы, которые могут использоваться в области действия процесса poold. Область действия элемента управления – не шире, чем отдельный экземпляр Solaris.

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

Определение доступных ресурсов

Все системные ресурсы, доступные для потребления приложениями, входят в пулы ресурсов.

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

Например, на машине с четырьмя процессорами и двумя наборами процессоров может применяться следующая схема настройки:

pset 0: 0 1

pset 1: 2 3

Где 0, 1, 2 и 3 после двоеточия соответствуют идентификаторам ЦП. Следует отметить, что в эти два набора процессоров входят все четыре ЦП.

В том же компьютере не может существовать следующая конфигурация:

pset 0: 0 1

pset 1: 1 2 3

Такая настройка невозможна, поскольку ЦП 1 может одновременно входить только в один pset.

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

Демон poold выполняет процедуру обнаружения доступных ресурсов путем опроса активной конфигурации пулов для поиска разделов. Все ресурсы внутри всех разделов суммируются для определения общего объема доступных ресурсов по каждому контролируемому типу ресурсов.

Этот объем ресурсов выступает в качестве базового показателя, используемого демоном poold. Однако на этот показатель накладываются ограничения, ограничивающие гибкость poold в отношении распределения. Для получения информации о доступных ограничениях см. Ограничения в конфигурации.

Определение дефицита ресурсов

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

Определение использования ресурсов

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

Например, в случае наборов процессоров все измерения выполняются для всех процессоров в определенном наборе. Степень использования ресурсов позволяет определить пропорцию времени, в течение которого используется ресурс, по интервалу выборки. Степень использования ресурсов выражается в процентах от 0 до 100.

Определение нарушений в элементах управления

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

Раздел, не выполняющий заданные пользователем целевые показатели, представляет собой нарушение по элементу управления. Существуют два типа таких нарушений – синхронное и асинхронное.

• Синхронное нарушение обнаруживается демоном в ходе наблюдения за рабочими нагрузки.

• Асинхронное нарушение происходит независимо от действий демона по наблюдению.

Асинхронные нарушения вызываются следующими событиями:

• добавление или удаление ресурсов из области действия управления;

• перенастройка области действия управления;

• перезапуск контроллера ресурсов poold.

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

Определение мер по исправлению ситуации

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

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

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

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

Наблюдение за механизмом пулов и степени использования ресурсов командой poolstat

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

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

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

Для получения дополнительной информации о poolstat см. справочную страницу poolstat(1M). Для получения информации о задачах и использовании poolstat см. Вывод статистических отчетов по ресурсам, связанным с пулами, с помощью команды poolstat.

Выходные данные poolstat

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

Используются следующие заголовки столбцов:

id

Идентификатор пула.

pool

Имя пула.

rid

Идентификатор набора ресурсов.

rset

Имя набора ресурсов.

type

Тип набора ресурсов.

min

Минимальный размер набора ресурсов.

max

Максимальный размер набора ресурсов.

size

Текущий размер набора ресурсов.

used

Мера текущего использования набора ресурсов.

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

load

Абсолютное представление нагрузки набора ресурсов.

Для получения дополнительной информации об этом свойстве см. справочную страницу libpool(3LIB).

Выходные данные poolstat можно настроить путем определения следующих элементов:

• Порядок столбцов

• Выводимые заголовки

Настройка интервалов операций poolstat

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

интервал

Настройка интервалов для периодических операций, выполняемых poolstat. Все интервалы указываются в секундах.

число

Число повторений статистики. По умолчанию статистика poolstat выводится один раз.

Если значения интервал и число не указаны, данные статистики выводятся один раз. Если значение interval указано, а count не указано, то статистика выводится бесконечно.

Команды, используемые с механизмом пулов ресурсов

Команды, указанные в следующей таблице, обеспечивают главный административный интерфейс для механизма пулов. Для получения информации по использованию этих команд в системе с установленными зонами см. Использование пулов ресурсов в зонах.

Библиотекой libpool предоставляется API (см. справочную страницуlibpool(3LIB)). Эта библиотека может использоваться программами для управления конфигурациями пулов.

Глава 13 Создание и администрирование пулов ресурсов (задачи)

В этой главе описываются процедуры создания и администрирования пулов ресурсов.

Для получения вводной информации о пулах ресурсов см. Глава 12Пулы ресурсов (обзор).

Администрирование динамических пулов ресурсов (карта задач)

Включение и отключение механизма пулов

Начиная с Solaris 10 11/06, службы пулов ресурсов и динамических пулов ресурсов можно включать и выключать с помощью команды svcadm, описанной на справочной странице svcadm(1M).

Команда pooladm, описанная на справочной странице pooladm(1M), позволяет выполнять следующие действия:

• включение механизма пулов для обеспечения возможности манипулирования пулами;

• отключение механизма пулов для запрета манипулирования пулами.

Если при обновлении системы архитектура пулов ресурсов включена, и существует файл /etc/pooladm.conf, включается служба пулов, и к системе применяется конфигурация из данного файла.

Solaris 10 11/06 и более поздние версии: включение службы пулов ресурсов командой svcadm

1. Перейдите в режим суперпользователя или воспользуйтесь ролью, включающей в себя профиль управления процессами (Process Management).

   Профиль управления процессами входит в роль системного администратора (System Administrator). Для получения дополнительной информации о ролях см. Using the Solaris Management Tools With RBAC (Task Map) в System Administration Guide: Basic Administration.

2. Включите службу пулов ресурсов.

   # svcadm enable system/pools:default

Solaris 10 11/06 и более поздние версии: отключение службы пулов ресурсов командой svcadm

1. Перейдите в режим суперпользователя или воспользуйтесь ролью, включающей в себя профиль управления процессами (Process Management).

   Профиль управления процессами входит в роль системного администратора (System Administrator). Для получения дополнительной информации о ролях см. Using the Solaris Management Tools With RBAC (Task Map) в System Administration Guide: Basic Administration.

2. Отключите службу пулов ресурсов.

   # svcadm disable system/pools:default

Solaris 10 11/06 и более поздние версии: включение службы динамических пулов ресурсов командой svcadm

1. Перейдите в режим суперпользователя или воспользуйтесь ролью, включающей в себя профиль управления службами (Service Management).

   Роли содержат полномочия и привилегированные команды. Информацию относительно создания роли и ее назначения пользователю приведены в Configuring RBAC (Task Map) в System Administration Guide: Security ServicesManaging RBAC (Task Map) руководства Руководство по системному администрированию: службы безопасности.

2. Включите службу динамических пулов ресурсов.

   # svcadm enable system/pools/dynamic:default

Пример 13–1 Зависимость службы динамических пулов ресурсов от службы пулов ресурсов

Как показывает этот пример, перед запуском динамических пулов ресурсов (DRP) следует сначала включить пулы ресурсов.

Между пулами ресурсов и динамическими пулами ресурсов существует зависимость. Служба DRP теперь зависит от пулов ресурсов. Существует возможность включения и отключения DRP отдельно от пулов ресурсов.

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

# svcs *pool*
STATE          STIME    FMRI
disabled       10:32:26 svc:/system/pools/dynamic:default
disabled       10:32:26 svc:/system/pools:default

Включите механизм динамических пулов ресурсов:

# svcadm enable svc:/system/pools/dynamic:default
# svcs -a | grep pool
disabled       10:39:00 svc:/system/pools:default
offline        10:39:12 svc:/system/pools/dynamic:default

Следует отметить, что служба DRP по-прежнему не активирована.

Для определения причины неактивности службы DRP используется параметр -x команды svcs:

# svcs -x *pool*
svc:/system/pools:default (resource pools framework)
 State: disabled since Wed 25 Jan 2006 10:39:00 AM GMT
Reason: Disabled by an administrator.
   See: http://sun.com/msg/SMF-8000-05
   See: libpool(3LIB)
   See: pooladm(1M)
   See: poolbind(1M)
   See: poolcfg(1M)
   See: poolstat(1M)
   See: /var/svc/log/system-pools:default.log
Impact: 1 dependent service is not running.  (Use -v for list.)

svc:/system/pools/dynamic:default (dynamic resource pools)
 State: offline since Wed 25 Jan 2006 10:39:12 AM GMT
Reason: Service svc:/system/pools:default is disabled.
   See: http://sun.com/msg/SMF-8000-GE
   See: poold(1M)
   See: /var/svc/log/system-pools-dynamic:default.log
Impact: This service is not running.

Включите службу пулов ресурсов для подготовки к запуску службы DRP:

# svcadm enable svc:/system/pools:default

В результате выполнения команды svcs *pool* выводится следующая информация:

# svcs *pool*
STATE          STIME    FMRI
online         10:40:27 svc:/system/pools:default
online         10:40:27 svc:/system/pools/dynamic:default

Пример 13–2 Влияние отключения службы пулов ресурсов на динамические пулы ресурсов

Если обе службы работают, и отключается служба пулов ресурсов:

# svcadm disable svc:/system/pools:default 

В результате выполнения команды svcs *pool* выводится следующая информация:

# svcs *pool*
STATE          STIME    FMRI
disabled       10:41:05 svc:/system/pools:default
online         10:40:27 svc:/system/pools/dynamic:default
# svcs *pool*
STATE          STIME    FMRI
disabled       10:41:05 svc:/system/pools:default
online         10:40:27 svc:/system/pools/dynamic:default

Однако, в конечном счете, служба DRP переходит в состояние offline, поскольку служба пулов ресурсов отключена:

# svcs *pool*
STATE          STIME    FMRI
disabled       10:41:05 svc:/system/pools:default
offline        10:41:12 svc:/system/pools/dynamic:default

Выясните причину неактивности службы DRP:

# svcs -x *pool*
svc:/system/pools:default (resource pools framework)
 State: disabled since Wed 25 Jan 2006 10:41:05 AM GMT
Reason: Disabled by an administrator.
   See: http://sun.com/msg/SMF-8000-05
   See: libpool(3LIB)
   See: pooladm(1M)
   See: poolbind(1M)
   See: poolcfg(1M)
   See: poolstat(1M)
   See: /var/svc/log/system-pools:default.log
Impact: 1 dependent service is not running.  (Use -v for list.)

svc:/system/pools/dynamic:default (dynamic resource pools)
 State: offline since Wed 25 Jan 2006 10:41:12 AM GMT
Reason: Service svc:/system/pools:default is disabled.
   See: http://sun.com/msg/SMF-8000-GE
   See: poold(1M)
   See: /var/svc/log/system-pools-dynamic:default.log
Impact: This service is not running.

Для работы DRP требуется запуск пулов ресурсов. Пулы ресурсов можно запустить, например, командой pooladm с параметром -e:

# pooladm -e

Теперь в результате выполнения команды svcs *pool* выводится следующая информация:

# svcs *pool*
STATE          STIME    FMRI
online         10:42:23 svc:/system/pools:default
online         10:42:24 svc:/system/pools/dynamic:default

Solaris 10 11/06 и более поздние версии: отключение службы динамических пулов ресурсов командой svcadm

1. Перейдите в режим суперпользователя или воспользуйтесь ролью, включающей в себя профиль управления процессами (Process Management).

   Профиль управления процессами входит в роль системного администратора (System Administrator). Для получения дополнительной информации о ролях см. Using the Solaris Management Tools With RBAC (Task Map) в System Administration Guide: Basic Administration.

2. Отключите службу динамических пулов ресурсов.

   # svcadm disable system/pools/dynamic:default

Включение пулов ресурсов командой pooladm

1. Перейдите в режим суперпользователя или воспользуйтесь ролью, включающей в себя профиль управления процессами (Process Management).

   Профиль управления процессами входит в роль системного администратора (System Administrator). Для получения дополнительной информации о ролях см. Using the Solaris Management Tools With RBAC (Task Map) в System Administration Guide: Basic Administration.

2. Включите механизм управления пулами.

   # pooladm -e

Отключения пулов ресурсов командой pooladm

1. Перейдите в режим суперпользователя или воспользуйтесь ролью, включающей в себя профиль управления процессами (Process Management).

   Профиль управления процессами входит в роль системного администратора (System Administrator). Для получения дополнительной информации о ролях см. Using the Solaris Management Tools With RBAC (Task Map) в System Administration Guide: Basic Administration.

2. Отключите механизм управления пулами.

   # pooladm -d

Настройка пулов

Создание статической конфигурации

С помощью команды -s с параметром /usr/sbin/pooladm создайте файл статической конфигурации, совпадающей с текущей динамической конфигурацией. Если не указано другое имя файла, используется местоположение по умолчанию /etc/pooladm.conf .

Зафиксируйте конфигурацию командой pooladm с параметром -c. После этого статическую конфигурацию следует привести в соответствие с динамической конфигурацией командой pooladm с параметром -s.

Новые функциональные возможности команды pooladm -s, являются предпочтительными по сравнению с ранее использовавшимися функциональными возможностями команды poolcfg -c discover для создания новой конфигурации, совпадающей с динамической конфигурацией.

Перед началом работы

Включите пулы в системе.

1. Перейдите в режим суперпользователя или воспользуйтесь ролью, включающей в себя профиль управления процессами (Process Management).

   Профиль управления процессами входит в роль системного администратора (System Administrator). Для получения дополнительной информации о ролях см. Using the Solaris Management Tools With RBAC (Task Map) в System Administration Guide: Basic Administration.

2. Обновите файл статической конфигурации в соответствии с текущей динамической конфигурацией.

   # pooladm -s

3. Выведите содержимое файла конфигурации в удобной для чтения форме.

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

   # poolcfg -c info system tester string system.comment int system.version 1 boolean system.bind-default true int system.poold.pid 177916 pool pool_default int pool.sys_id 0 boolean pool.active true boolean pool.default true int pool.importance 1 string pool.comment pset pset_default pset pset_default int pset.sys_id -1 boolean pset.default true uint pset.min 1 uint pset.max 65536 string pset.units population uint pset.load 10 uint pset.size 4 string pset.comment boolean testnullchanged true cpu int cpu.sys_id 3 string cpu.comment string cpu.status on-line cpu int cpu.sys_id 2 string cpu.comment string cpu.status on-line cpu int cpu.sys_id 1 string cpu.comment string cpu.status on-line cpu int cpu.sys_id 0 string cpu.comment string cpu.status on-line

4. Зафиксируйте конфигурацию в /etc/pooladm.conf .

   # pooladm -c

5. (Дополнительно) Для копирования динамической конфигурации в файл статической /tmp/backup используется следующая команда:

   # pooladm -s /tmp/backup

Изменение конфигурации

Для расширения конфигурации создайте набор процессоров с названием pset_batch и пул с названием pool_batch. Затем свяжите пул и набор процессоров.

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

1. Перейдите в режим суперпользователя или воспользуйтесь ролью, включающей в себя профиль управления процессами (Process Management).

   Профиль управления процессами входит в роль системного администратора (System Administrator). Для получения дополнительной информации о ролях см. Using the Solaris Management Tools With RBAC (Task Map) в System Administration Guide: Basic Administration.

2. Создайте набор процессоров pset_batch.

   # poolcfg -c 'create pset pset_batch (uint pset.min = 2; uint pset.max = 10)'

3. Создайте пул pool_batch.

   # poolcfg -c 'create pool pool_batch'

4. Свяжите пул с набором процессоров.

   # poolcfg -c 'associate pool pool_batch (pset pset_batch)'

5. Проверьте измененную конфигурацию.

   # poolcfg -c info system tester string system.comment kernel state int system.version 1 boolean system.bind-default true int system.poold.pid 177916 pool pool_default int pool.sys_id 0 boolean pool.active true boolean pool.default true int pool.importance 1 string pool.comment pset pset_default pset pset_default int pset.sys_id -1 boolean pset.default true uint pset.min 1 uint pset.max 65536 string pset.units population uint pset.load 10 uint pset.size 4 string pset.comment boolean testnullchanged true cpu int cpu.sys_id 3 string cpu.comment string cpu.status on-line cpu int cpu.sys_id 2 string cpu.comment string cpu.status on-line cpu int cpu.sys_id 1 string cpu.comment string cpu.status on-line cpu int cpu.sys_id 0 string cpu.comment string cpu.status on-line pool pool_batch boolean pool.default false boolean pool.active true int pool.importance 1 string pool.comment pset pset_batch pset pset_batch int pset.sys_id -2 string pset.units population boolean pset.default true uint pset.max 10 uint pset.min 2 string pset.comment boolean pset.escapable false uint pset.load 0 uint pset.size 0 cpu int cpu.sys_id 5 string cpu.comment string cpu.status on-line cpu int cpu.sys_id 4 string cpu.comment string cpu.status on-line

6. Зафиксируйте конфигурацию в /etc/pooladm.conf .

   # pooladm -c

7. (Дополнительно) Для копирования динамической конфигурации в файл статической конфигурации /tmp/backup используется следующая команда:

   # pooladm -s /tmp/backup

Связывание пула с классом планирования

Если пул связывается с классом планирования, указанный планировщик используется для всех процессов, привязанных к пулу. Для этого в свойстве pool.scheduler указывается имя планировщика. В этом примере пул pool_batch связывается с планировщиком долевого распределения (FSS).

1. Перейдите в режим суперпользователя или воспользуйтесь ролью, включающей в себя профиль управления процессами (Process Management).

   Профиль управления процессами входит в роль системного администратора (System Administrator). Информацию относительно создания роли и назначения роли пользователю приведены в разделе "Managing RBAC (Task Map)" руководства Руководство по системному администрированию: службы безопасности.

2. Измените пул pool_batch и свяжите его с FSS.

   # poolcfg -c 'modify pool pool_batch (string pool.scheduler="FSS")'

3. Проверьте измененную конфигурацию.

   # poolcfg -c info system tester string system.comment int system.version 1 boolean system.bind-default true int system.poold.pid 177916 pool pool_default int pool.sys_id 0 boolean pool.active true boolean pool.default true int pool.importance 1 string pool.comment pset pset_default pset pset_default int pset.sys_id -1 boolean pset.default true uint pset.min 1 uint pset.max 65536 string pset.units population uint pset.load 10 uint pset.size 4 string pset.comment boolean testnullchanged true cpu int cpu.sys_id 3 string cpu.comment string cpu.status on-line cpu int cpu.sys_id 2 string cpu.comment string cpu.status on-line cpu int cpu.sys_id 1 string cpu.comment string cpu.status on-line cpu int cpu.sys_id 0 string cpu.comment string cpu.status on-line pool pool_batch boolean pool.default false boolean pool.active true int pool.importance 1 string pool.comment string pool.scheduler FSS pset batch pset pset_batch int pset.sys_id -2 string pset.units population boolean pset.default true uint pset.max 10 uint pset.min 2 string pset.comment boolean pset.escapable false uint pset.load 0 uint pset.size 0 cpu int cpu.sys_id 5 string cpu.comment string cpu.status on-line cpu int cpu.sys_id 4 string cpu.comment string cpu.status on-line

4. Зафиксируйте конфигурацию в /etc/pooladm.conf :

   # pooladm -c

5. (Дополнительно) Для копирования динамической конфигурации в файл статической /tmp/backup используется следующая команда:

   # pooladm -s /tmp/backup

Настройка ограничений конфигурации

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

В следующих примерах cpuid является целым числом.

1. Перейдите в режим суперпользователя или воспользуйтесь ролью, включающей в себя профиль управления процессами (Process Management).

   Профиль управления процессами входит в роль системного администратора (System Administrator). Для получения дополнительной информации о ролях см. Using the Solaris Management Tools With RBAC (Task Map) в System Administration Guide: Basic Administration.

2. Измените свойство cpu.pinned в статической или динамической конфигурации.

   • Измените конфигурацию начальной загрузки (статическую):

     # poolcfg -c 'modify cpu <cpuid> (boolean cpu.pinned = true)'

   • Измените текущую (динамическую) конфигурацию без изменения конфигурации начальной загрузки:

     # poolcfg -dc 'modify cpu <cpuid> (boolean cpu.pinned = true)'

Определение целевых показателей конфигурации

Для poold можно задать целевые показатели, которые будут учитываться при принятии корректирующих мер.

В следующей процедуре значение целевого показателя wt-load заставляет демон poold сопоставлять распределение ресурсов с их использованием. Целевой показатель locality отключен, что упростит достижение указанной цели.

1. Перейдите в режим суперпользователя или воспользуйтесь ролью, включающей в себя профиль управления процессами (Process Management).

   Профиль управления процессами входит в роль системного администратора (System Administrator). Для получения дополнительной информации о ролях см. Using the Solaris Management Tools With RBAC (Task Map) в System Administration Guide: Basic Administration.

2. Измените системный параметр tester, чтобы присвоить более высокий приоритет целевому показателю wt-load.

   # poolcfg -c 'modify system tester (string system.poold.objectives="wt-load")'

3. Отключите целевой показатель locality для набора процессоров по умолчанию.

   # poolcfg -c 'modify pset pset_default (string pset.poold.objectives="locality none")'one line

4. Отключите целевой показатель locality для набора процессоров pset_batch.

   # poolcfg -c 'modify pset pset_batch (string pset.poold.objectives="locality none")'one line

5. Проверьте измененную конфигурацию.

   # poolcfg -c info system tester string system.comment int system.version 1 boolean system.bind-default true int system.poold.pid 177916 string system.poold.objectives wt-load pool pool_default int pool.sys_id 0 boolean pool.active true boolean pool.default true int pool.importance 1 string pool.comment pset pset_default pset pset_default int pset.sys_id -1 boolean pset.default true uint pset.min 1 uint pset.max 65536 string pset.units population uint pset.load 10 uint pset.size 4 string pset.comment boolean testnullchanged true string pset.poold.objectives locality none cpu int cpu.sys_id 3 string cpu.comment string cpu.status on-line cpu int cpu.sys_id 2 string cpu.comment string cpu.status on-line cpu int cpu.sys_id 1 string cpu.comment string cpu.status on-line cpu int cpu.sys_id 0 string cpu.comment string cpu.status on-line pool pool_batch boolean pool.default false boolean pool.active true int pool.importance 1 string pool.comment string pool.scheduler FSS pset batch pset pset_batch int pset.sys_id -2 string pset.units population boolean pset.default true uint pset.max 10 uint pset.min 2 string pset.comment boolean pset.escapable false uint pset.load 0 uint pset.size 0 string pset.poold.objectives locality none cpu int cpu.sys_id 5 string cpu.comment string cpu.status on-line cpu int cpu.sys_id 4 string cpu.comment string cpu.status on-line

6. Зафиксируйте конфигурацию в /etc/pooladm.conf .

   # pooladm -c

7. (Дополнительно) Для копирования динамической конфигурации в файл статической /tmp/backup используется следующая команда:

   # pooladm -s /tmp/backup

Настройки уровня журналирования poold

Уровень регистрационной информации, генерируемой демоном poold, задается в виде свойства system.poold.log-level в конфигурации poold. Конфигурация poold содержится в конфигурации libpool. Для получения дополнительной информации см. Информация журналирования poold и справочные страницы poolcfg(1M) и libpool(3LIB).

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

1. Перейдите в режим суперпользователя или воспользуйтесь ролью, включающей в себя профиль управления процессами (Process Management).

   Профиль управления процессами входит в роль системного администратора (System Administrator). Для получения дополнительной информации о ролях см. Using the Solaris Management Tools With RBAC (Task Map) в System Administration Guide: Basic Administration.

2. Уровень журналирования настраивается командой poold с параметром-l и дополнительным параметром (например, INFO).

   # /usr/lib/pool/poold -l INFO

   Для получения информации о доступных параметрах см. Информация журналирования poold. Значение по умолчанию для уровня журналирования – NOTICE.

Использование командных файлов совместно с командой poolcfg

Команда poolcfg с параметром -f может получать входные данные из текстового файла, содержащего аргументы подкоманды poolcfg с параметром -c. Этот метод удобен при необходимости выполнения ряда операций. При обработке нескольких команд конфигурация обновляется только в случае успешности каждой из них. В случае крупных или сложных конфигураций этот прием может оказаться более удобным, чем вызов подкоманд по отдельности.

Следует отметить, что символ # в командных файлах означает, что остальная часть строки является комментарием.

1. Создайте входной файл poolcmds.txt .

   $ cat > poolcmds.txt create system tester create pset pset_batch (uint pset.min = 2; uint pset.max = 10) create pool pool_batch associate pool pool_batch (pset pset_batch)

2. Перейдите в режим суперпользователя или воспользуйтесь ролью, включающей в себя профиль управления процессами (Process Management).

   Профиль управления процессами входит в роль системного администратора (System Administrator). Информацию относительно создания роли и назначения роли пользователю приведены в разделе "Managing RBAC" руководства Руководство по системному администрированию: службы безопасности.

3. Выполните команду:

   # /usr/sbin/poolcfg -f poolcmds.txt

Перенос ресурсов

Для переноса ресурсов в ядре используется аргумент подкоманды transfer параметра -c команды poolcfg с параметром -d. Параметр -d означает, что команда работает непосредственно с ядром и не получает входные данные из файла.

Следующая процедура позволяет переместить два ЦП из набора процессоров pset1 в набор процессоров pset2 в ядре.

Перенос процессоров между наборами процессоров

1. Перейдите в режим суперпользователя или воспользуйтесь ролью, включающей в себя профиль управления процессами (Process Management).

   Профиль управления процессами входит в роль системного администратора (System Administrator). Для получения дополнительной информации о ролях см. Using the Solaris Management Tools With RBAC (Task Map) в System Administration Guide: Basic Administration.

2. Переместите два ЦП из pset1 в pset2.

   Элементы выражения from и to могут указываться в любом порядке. Поддерживается только одна пара to и from на команду.

   # poolcfg -dc 'transfer 2 from pset pset1 to pset2'

Пример 13–3 Альтернативный метод переноса ЦП между наборами процессоров

Если требуется выполнить перенос конкретных идентификаторов типа ресурса, можно воспользоваться альтернативным синтаксисом. Например, следующая команда присваивает два процессора с идентификаторами 0 и 2 набору процессоров pset_large:

# poolcfg -dc "transfer to pset pset_large (cpu 0; cpu 2)"

Поиск и устранение отказов

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

Активация и удаление конфигураций пулов

Для активации определенной конфигурации пулов или удаления конфигурации пулов, активной в текущий момент, используется команда pooladm. Для получения дополнительной информации об этой команде см. справочную страницу pooladm(1M).

Активация конфигурации пулов

Для активации конфигурации из файла конфигурации по умолчанию /etc/pooladm.conf используется команда pooladm с параметром -c – "применить конфигурацию".

1. Перейдите в режим суперпользователя или воспользуйтесь ролью, включающей в себя профиль управления процессами (Process Management).

   Профиль управления процессами входит в роль системного администратора (System Administrator). Для получения дополнительной информации о ролях см. Using the Solaris Management Tools With RBAC (Task Map) в System Administration Guide: Basic Administration.

2. Зафиксируйте конфигурацию в /etc/pooladm.conf .

   # pooladm -c

3. (Дополнительно) Скопируйте динамическую конфигурацию в файл статической конфигурации, например /tmp/backup.

   # pooladm -s /tmp/backup

Проверка допустимости конфигурации перед сохранением ее параметров

Для выяснения результатов проверки допустимости можно использовать параметр -n с параметром -c. Фактического сохранения параметров конфигурации не происходит.

Следующая команда используется для проверки допустимости конфигурации, содержащейся в файле /home/admin/newconfig. Выводятся сообщения обо всех возникающих состояниях ошибки, однако сама конфигурация не изменяется.

1. Перейдите в режим суперпользователя или воспользуйтесь ролью, включающей в себя профиль управления процессами (Process Management).

   Профиль управления процессами входит в роль системного администратора (System Administrator). Для получения дополнительной информации о ролях см. Using the Solaris Management Tools With RBAC (Task Map) в System Administration Guide: Basic Administration.

2. Перед сохранением параметров конфигурации ее следует проверить на допустимость.

   # pooladm -n -c /home/admin/newconfig

Удаление конфигурации пулов

Для удаления текущей активной конфигурации и возврата всех связанных ресурсов, например наборов процессоров, к их состоянию по умолчанию используется параметр -x – "удалить конфигурацию".

1. Перейдите в режим суперпользователя или воспользуйтесь ролью, включающей в себя профиль управления процессами (Process Management).

   Профиль управления процессами входит в роль системного администратора (System Administrator). Для получения дополнительной информации о ролях см. Using the Solaris Management Tools With RBAC (Task Map) в System Administration Guide: Basic Administration.

2. Удалите текущую активную конфигурацию.

   # pooladm -x

   Параметр - x команды pooladm позволяет удалить из динамической конфигурации все элементы, заданные пользователем. Все ресурсы возвращаются в состояние по умолчанию, и все привязки пулов заменяются привязкой к пулу по умолчанию.

Комбинирование классов планирования внутри набора процессоров

Допускается комбинирование процессов с классами планирования TS и IA в одном наборе процессоров. Комбинирование других классов планирования внутри одного набора процессоров может привести к непредсказуемым последствиям. Если в результате выполнения команды pooladm -x в рамках одного набора процессоров оказываются процессы с разными классами планирования, вынести выполняющиеся процессы в другой класс планирования можно командой priocntl. См. Перенос процессов из класса TS в класс FSS вручную. Также см. справочную страницу priocntl(1).

Установка атрибутов пулов и связывание с пулом

Для связывания пула ресурсов с проектом служит атрибут project.pool.

Связывание выполняющихся процессов осуществляется двумя способами.

• Связать определенный процесс с именованным пулом ресурсов можно командой poolbind, описанной в poolbind(1M).

• Определить привязку к пулу для нового сеанса регистрации или для задачи, запущенной по команде newtask, можно с помощью атрибута project.pool в базе данных project. См. справочные страницы newtask(1), projmod(1M) и project(4).

Связывание процессов с пулом

В следующей процедуре используется команда poolbind с параметром -p , позволяющая вручную связать процесс (в данном случае текущую оболочку) с пулом ohare.

1. Перейдите в режим суперпользователя или воспользуйтесь ролью, включающей в себя профиль управления процессами (Process Management).

   Профиль управления процессами входит в роль системного администратора (System Administrator). Для получения дополнительной информации о ролях см. Using the Solaris Management Tools With RBAC (Task Map) в System Administration Guide: Basic Administration.

2. Свяжите процесс с пулом вручную:

   # poolbind -p ohare $$

3. Проверьте привязку процесса к пулу командой poolbind с параметром -q.

   $ poolbind -q $$ 155509 ohare

   Выводится идентификатор процесса и привязка к пулу.

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

Для привязки задач или проектов к пулу используется команда poolbind с параметром -i. В следующем примере все процессы в проекте airmiles связываются с пулом laguardia.

1. Перейдите в режим суперпользователя или воспользуйтесь ролью, включающей в себя профиль управления процессами (Process Management).

   Профиль управления процессами входит в роль системного администратора (System Administrator). Для получения дополнительной информации о ролях см. Using the Solaris Management Tools With RBAC (Task Map) в System Administration Guide: Basic Administration.

2. Свяжите все процессы в проекте airmiles с пулом laguardia.

   # poolbind -i project -p laguardia airmiles

Установка атрибута project.pool

Атрибут project.pool позволяет выполнить привязку процессов проекта к пулу ресурсов.

1. Перейдите в режим суперпользователя или воспользуйтесь ролью, включающей в себя профиль управления процессами (Process Management).

   Профиль управления процессами входит в роль системного администратора (System Administrator). Для получения дополнительной информации о ролях см. Using the Solaris Management Tools With RBAC (Task Map) в System Administration Guide: Basic Administration.

2. Добавьте атрибут project.pool к каждой записи в базе данных project.

   # projmod -a -K project.pool=poolname project

Использование атрибутов project для привязки процесса к другому пулу

Предположим, существует конфигурация с двумя пулами – studio и backstage. В файле /etc/project содержатся следующие данные:

user.paul:1024::::project.pool=studio
user.george:1024::::project.pool=studio
user.ringo:1024::::project.pool=backstage
passes:1027::paul::project.pool=backstage

В этой конфигурации процессы, запущенные пользователем paul, по умолчанию связываются с пулом studio.

Пользователь paul может изменять привязку к пулу для запускаемых им проектов. Пользователь paul может также выполнять привязку к пулу backstage командой newtask в рамках проекта passes.