В этом разделе предоставлено введение в диспетчер ресурсов Solaris 10, который позволяет контролировать использование доступных системных ресурсов приложениями.
Функциональные возможности управления ресурсами являются компонентом среды SolarisTM Container. Управление ресурсами позволяет регулировать использование доступных системных ресурсов приложениями. Имеются следующие возможности:
распределение вычислительных ресурсов, например процессорного времени;
Наблюдение за использованием выделенных ресурсов и регулирование распределения по мере необходимости;
генерация данных расширенного учета для анализа, биллинга и планирования пропускной способности.
В этой главе рассматриваются следующие темы:
Современные вычислительные среды должны гибко реагировать на изменчивые рабочие нагрузки, создаваемые в системе разнообразными приложениями. Рабочая нагрузка – это совокупность всех процессов приложения или группы приложений. Если функции управления ресурсами не используются, операционная система Solaris реагирует на запросы рабочих нагрузок путем динамической адаптации к новым запросам приложений. Эта стандартная реакция обычно предоставляет всем приложениям, работающим в системе, равный доступ к ресурсам. Функции управления ресурсами Solaris позволяют реализовать дифференцированный подход к рабочим нагрузкам. Имеются следующие возможности:
ограничение доступа к определенному ресурсу;
предоставление ресурсов рабочим нагрузкам на основе приоритетов;
изоляция рабочих нагрузок друг от друга.
Способность минимизации падения производительности по всем рабочим нагрузкам вместе со средствами наблюдения, использования и потребления ресурсов достигается за счет управления ресурсами. Управление ресурсами реализуется через ряд алгоритмов. Эти алгоритмы используются для обработки ряда запросов ресурсов, создаваемых приложениями в ходе выполнения.
Средства управления ресурсами позволяют изменить поведение операционной системы по умолчанию в отношении разных рабочих нагрузок. Поведением называется прежде всего ряд решений, принимаемых алгоритмами операционной системы при выдаче приложением одного или нескольких запросов на получение ресурсов. Средства управления ресурсами предоставляют следующие возможности:
отказ в предоставлении ресурсов или предпочтение одного приложения другому для более широкого спектра приложений, чем было бы возможно в противном случае;
коллективная обработка определенных распределений вместо использования изолированных механизмов.
Реализация системной конфигурации, использующей средства управления ресурсами, может служить нескольким целям. Имеются следующие возможности:
предотвращение недифференцированного потребления ресурсов приложениями;
изменение приоритета приложения на основании внешних событий;
балансирование гарантий ресурсов для набора приложений в целях максимального использования системы.
При планировании конфигурации с управлением ресурсами необходимо учесть следующие ключевые аспекты:
определение рабочих нагрузок, конкурирующих в системе;
разграничение неконфликтуюших рабочих нагрузок и рабочих нагрузок с требованиями по производительности, противоречащими требованиям основных рабочих нагрузок.
После определения сотрудничающих и конфликтующих рабочих нагрузок можно создать конфигурацию ресурсов, максимально соответствующую целям обслуживания пользователей в рамках возможностей системы.
Эффективное управление ресурсами реализуется в системе Solaris благодаря механизмам управления, механизмам уведомления и механизмам наблюдения. Многие из этих возможностей предоставляются через расширения существующих механизмов, например файловой системы proc(4), наборов процессоров и классов планирования. Другие возможности относятся исключительно к управлению ресурсами. Описание этих возможностей приводится в последующих главах.
Ресурс – это любой аспект вычислительной системы, которым можно управлять в целях изменения поведения приложений. Таким образом, ресурс – это возможность, запрашиваемая приложением явным или неявным образом. Если надежно написанное приложение сталкивается с отклонением запроса или ограничением этой возможности, его выполнение замедляется.
Классификация ресурсов, в отличие от идентификации ресурсов, может проводиться по ряду осей. В качестве осей можно выбрать следующие: явные или неявные требования, основанные на времени, например процессорное время, или независимые от времени, например назначенные доли ЦП и т.д.
Как правило, управление ресурсами на основе планировщика применяется к ресурсам, неявно запрашиваемым приложением. Например, для продолжения выполнения приложение неявно запрашивает дополнительное процессорное время. Для записи данных в сетевой сокет приложение неявно запрашивает полосу пропускания. На совокупное потребление неявно запрашиваемого ресурса можно наложить ограничения.
Могут предоставляться дополнительные интерфейсы, позволяющие реализовать явное согласование уровней обслуживания ЦП или полосы пропускания. Управление явно запрашиваемыми ресурсами, например запросами на создание дополнительных потоков, можно осуществлять посредством ограничений.
В операционной системе Solaris доступны три типа механизмов управления – ограничения, планирование и распределение.
Ограничения позволяют администратору или разработчику приложений ограничить потребление определенных ресурсов рабочими нагрузками. Наличие известных пределов упрощает процесс моделирования сценариев потребления ресурсов. Эти пределы также могут использоваться для управления неблагополучными приложениями, которые в противном случае привели бы к снижению производительности или доступности системы из-за нерегулируемых запросов на выделение ресурсов.
Использование ограничений ведет к усложнению среды с точки зрения приложений. Взаимосвязь между приложением и системой может измениться вплоть до полной невозможности дальнейшего функционирования приложения. Один из подходов, способных смягчить этот риск, состоит в постепенном сужении ограничений для приложений с неизвестным поведением в отношении ресурсов. Механизм ограничения обеспечивается функцией элементов управления ресурсами, рассматриваемой в Глава 6Элементы управления ресурсами (обзор). Более новые приложения могут создаваться с учетом соответствующих ограничений по ресурсам, однако реализация данной возможности зависит от авторов приложения.
Под планированием понимается формирование последовательности принимаемых решений по распределению ресурсов с определенными интервалами. Решения принимаются на основании предсказуемого алгоритма. Если приложение не потребляет выделенные ему ресурсы, эти ресурсы остаются доступными для других приложений. Управление ресурсами на основе планирования позволяет полностью использовать конфигурацию с неполным распределением, обеспечивая при этом управляемость приложений в сценарии с полным или чрезмерным распределением. Интерпретация термина "управляемость" зависит от лежащего в основе алгоритма. В некоторых случаях алгоритм планирования может гарантировать определенный уровень доступности ресурса для всех приложений. Доступом приложений к ресурсам ЦП управляет настраиваемый планировщик долевого распределения (FSS), описанный в Глава 8Планировщик долевого распределения (обзор).
Распределение используется для привязывания рабочей нагрузки к подмножеству доступных системных ресурсов. Эта привязка позволяет гарантировать доступность для этой рабочей нагрузки известного количества ресурсов. Описанные в Глава 12Пулы ресурсов (обзор) пулы ресурсов позволяют ограничить выполнение рабочих нагрузок определенными подмножествами компьютера.
Конфигурации, в которых используется распределение, позволяют избежать чрезмерного выделения системных ресурсов. Однако это может привести к снижению способности достигать высокой степени использования системы. Зарезервированная группа ресурсов, например процессоры, недоступна для использования другой рабочей нагрузкой во время неактивности рабочей нагрузки, связанной с этими ресурсами.
Часть конфигурации управления ресурсами можно разместить в сетевой службе имен. Эта возможность позволяет администраторам применять ограничения по ресурсам не индивидуально, а к целому набору компьютеров. Связанные задачи можно снабдить общим идентификатором, что позволит отслеживать совокупное потребление ресурсов по данным учета.
Более подробное описание параметров управления ресурсами и идентификаторов, ориентированных на рабочие нагрузки, приведены в Глава 2Проекты и задачи (обзор). Подсистема расширенного учета, связывающая эти идентификаторы с потреблением ресурсов приложениями, описана в Глава 4Расширенный учет (обзор).
Для дальнейшего совершенствования прикладной среды функции управления ресурсами можно использовать совместно с зонами Solaris. Взаимодействие между этими функциями и зонами описано в соответствующих разделах настоящего руководства.
Управление ресурсами следует использовать для обеспечения требуемого времени отклика приложений.
Управление ресурсами также может способствовать повышению степени использования ресурсов. Расположение потребностей в ресурсах по категориям и приоритетам позволяет эффективно использовать резервную мощность в периоды с умеренной нагрузкой, что в свою очередь позволяет устранить необходимость в дополнительных вычислительных мощностях. Также удается избегнуть траты ресурсов впустую из-за изменчивого характера нагрузки.
Управление ресурсами в первую очередь должно применяться для сред, в которых ряд приложений консолидируется на одном сервере.
Стоимость и сложность управления многочисленными машинами заставляет обратиться к консолидации нескольких приложений на более крупных серверах с большей масштабируемостью. Вместо выполнения каждой рабочей нагрузки на отдельной системе с полным доступом к ресурсам этой системы, рабочие нагрузки можно сегрегировать внутри самой системы с помощью управления ресурсами. Управление ресурсами позволяет снизить общую стоимость владения за счет выполнения и контроля ряда разных приложений в одной системе Solaris.
При необходимости предоставления интернет- и прикладных сервисов управление ресурсами может обеспечить следующие возможности:
Размещение нескольких веб-серверов на одной машине. Можно управлять потреблением ресурсов для каждого веб-сайта и защитить каждый сайт от потенциального превышения использования ресурсов другими сайтами.
Предотвращение исчерпания ресурсов ЦП неисправным сценарием общего шлюзового интерфейса (CGI).
Предотвращение утечки всей доступной виртуальной памяти из-за некорректно работающего приложения.
Предотвращение воздействия на приложения клиентов со стороны приложений других клиентов, выполняющихся на том же сайте.
Предоставление дифференцированных уровней или классов обслуживания на одной машине.
Получение учетной информации для биллинга.
Функции управления ресурсами следует использовать в любой системе с широкой и разнообразной пользовательской базой, например в образовательных учреждениях. Если приходится иметь дело с комбинацией разных рабочих нагрузок, для программного обеспечения можно настроить приоритетное отношение к определенным проектам.
Например, в крупных брокерских фирмах трейдерам периодически требуется быстрый доступ для выполнения запросов или расчетов. Другие пользователи системы, однако, пользуются более ровными рабочими нагрузками. Если проектам трейдеров выделить больше вычислительной мощности, они получат требуемую высокую скорость реакции системы.
Управление ресурсами также подходит для поддержки систем на базе "тонких клиентов". Эти платформы предоставляют консолям, не поддерживающим состояние, кадровые буферы и устройства ввода, например смарт-карты. Фактические вычисления выполняются на общем сервере, в результате чего реализуется среда с разделением времени. Функции управления ресурсами могут применяться для изолирования пользователей на сервере. В таком случае пользователь, генерирующий избыточную нагрузку, не сможет монополизировать аппаратные ресурсы и существенно повлиять на других пользователей, работающих в системе.
Следующая карта задач представляет собой общий обзор действий, выполняемых при настройке управления ресурсами в системе.
Задача |
Описание |
Инструкции |
---|---|---|
Идентификация рабочих нагрузок в системе и их категоризация по проектам |
Создание записей проектов в файле /etc/project, в карте NIS или в службе каталогов LDAP. | |
Расположение рабочих нагрузок в системе по приоритетам |
Определение важнейших приложений. Эти рабочие нагрузки могут иметь более высокий приоритет при доступе к ресурсам. |
См. цели обслуживания пользователей. |
Наблюдение за работой системы в реальном времени |
Для просмотра текущего потребления ресурсов рабочими нагрузками, выполняющимися в системе, можно воспользоваться средствами производительности. Затем можно оценить, требуется ли ограничить доступ к определенному ресурсу или изолировать одни рабочие нагрузки от других. |
См. справочные страницы Наблюдение на уровне системы и cpustat(1M), iostat(1M), mpstat(1M), prstat(1M), sar(1) и vmstat(1M) |
Внесение временных изменений в рабочие нагрузки, выполняющиеся в системе |
Для определения значений, которые можно изменить, см. описание доступных в системе Solaris элементов управления ресурсами. Эти значения можно обновить из командной строки во время работы задачи или процесса. |
Доступные элементы управления ресурсами, Глобальные и локальные действия со значениями элементов управления ресурсами, Временное обновление значений элементов управления ресурсами в работающей системе и справочные страницы rctladm(1M) и prctl(1). |
Настройка элементов управления ресурсами и атрибутов проекта для каждой записи проекта в базе данных project или в базе данных проектов службы имен. |
Каждая запись проекта в файле /etc/project или в базе данных проекта службы имен может содержать один или несколько элементов управления ресурсами или атрибутов. Элементы управления ресурсами позволяют ограничить задачи и процессы, присоединенные к данному проекту. С каждым пороговым значением, заданным для элемента управления ресурсами, можно связать одно или несколько действий, выполняемых при достижении этого значения. Элементы управления ресурсами могут настраиваться через интерфейс командной строки. Некоторые параметры конфигурации также можно настроить с помощью Solaris Management Console. |
См. База данных project, Формат локального файла /etc/project, Доступные элементы управления ресурсами, Глобальные и локальные действия со значениями элементов управления ресурсами и Глава 8Планировщик долевого распределения (обзор) |
Установка верхнего предела потребления ресурса физической памяти наборами процессов, присоединенных к проекту |
Демон ограниченного выделения ресурсов реализует ограничение по физической памяти, определенное для атрибута rcap.max-rss проекта в файле /etc/project. |
База данных project и Глава 10Управление физической памятью с помощью демона ограниченного выделения ресурсов (обзор) |
Создание пулов ресурсов |
Пулы ресурсов предоставляют способ разделения системных ресурсов, например процессоров, и поддержки этих разделов при перезагрузке. К каждой записи в файле project.pool можно добавить один атрибут /etc/project. | |
Назначение планировщика долевого распределения (FSS) системным планировщиком по умолчанию |
Для этого следует убедиться в том, что все пользовательские процессы в однопроцессорной системе или в наборе процессоров принадлежат к одному классу планирования. |
См. Настройка FSS и справочную страницу dispadmin(1M) |
Активация расширенного учета для наблюдения и регистрации потребления ресурсов для отдельных задач или процессов |
Данные расширенного учета используются для оценки текущих элементов управления ресурсами и планирования требований к мощности для будущих рабочих нагрузок. Данные учета позволяют отслеживать совокупное использование ресурсов по всей системе. Для получения полной статистики использования для связанных рабочих нагрузок, охватывающих несколько систем, на нескольких машинах должно использоваться одно и то же имя проекта. |
См. Активация расширенного учета для процессов, задач и потоков и справочную страницу acctadm(1M) |
(Дополнительно) Если в конфигурацию требуется внести дополнительные изменения, значения можно изменить из командной строки. Изменение значений может осуществляться во время работы задачи или процесса. |
Изменения существующих задач могут применяться на временной основе без перезапуска проекта. Сначала следует добиться достаточной производительности путем установки требуемых значений. Затем следует обновить текущие значения в файле /etc/project или в базе данных проекта службы имен. |
См. Временное обновление значений элементов управления ресурсами в работающей системе и справочные страницы rctladm(1M) и prctl(1) |
(Дополнительно) Получение данных расширенного учета |
Регистрация записей расширенного учета для активных процессов и задач. Полученные файлы можно использовать в целях планирования, гибкого управления ресурсами и биллинга. Существует также интерфейс Perl (Practical Extraction and Report Language) для libexacct, позволяющий разрабатывать собственные сценарии для создания отчетов и извлечения данных. |
См. справочную страницу wracct(1M) и Интерфейс Perl к libexacct |
В этой главе рассматриваются средства управления ресурсами Solaris, связанные с проектами и задачами. Проекты и задачи используются для отметки рабочих нагрузок и их отделения друг от друга.
В этой главе рассматриваются следующие темы:
Для получения информации по использованию средств управления проектами и задачами см. Глава 3Администрирование проектов и задач.
В версии Solaris 10 были добавлены следующие усовершенствования:
Добавлена поддержка кратных единиц и модификаторов единиц в элементах и командах управления ресурсами.
Усовершенствована проверка допустимости и упрощено манипулирование полями атрибутов проекта.
Пересмотрен формат вывода и добавлены новые параметры для команд prctl и projects
Добавлена возможность установки проекта пользователя по умолчанию командой useradd и изменения информации командами usermod и passmgmt
В дополнение к информации, приведенной в этой главе и в Глава 6Элементы управления ресурсами (обзор), см. следующие справочные страницы:
В 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). Для определения проекта по умолчанию выполняется ряд последовательных действий. Если проект по умолчанию не обнаруживается, вход пользователя в систему или запрос запуска процесса отклоняется.
Затем для определения проекта пользователя по умолчанию последовательно выполняются следующие действия:
Если в расширенной базе данных атрибутов пользователей /etc/user_attr для пользователя определена запись с атрибутом project, то в качестве проекта по умолчанию используется значение атрибута project. См. справочную страницу user_attr(4).
Если в базе данных project присутствует проект с именем user.идентификатор_пользователя, то по умолчанию используется этот проект. Для получения дополнительной информации см. справочную страницу project(4).
Если в базе данных project присутствует проект с именем group.имя_группы, где имя_группы соответствует группе по умолчанию для данного пользователя, как указано в файле passwd, то по умолчанию используется этот проект. Для получения информации о файле passwd см. справочную страницу passwd(4).
Если в базе данных project присутствует особый проект default, то этот проект используется по умолчанию.
Эта логика обеспечивается библиотечной функцией getdefaultproj(). Для получения дополнительной информации см. справочную страницу getprojent(3PROJECT).
Для установки атрибутов пользователей в локальных файлах используются перечисленные ниже команды с параметром -K и парой ключ=значение:
Изменение пользовательской информации.
Настройка проекта по умолчанию для пользователя.
Изменение пользовательской информации.
Могут использоваться следующие локальные файлы:
/etc/group
/etc/passwd
/etc/project
/etc/shadow
/etc/user_attr
Если для дополнения локального файла дополнительными записями используется сетевая служба имен, такая как NIS, информация, предоставляемая сетевой службой имен, не может изменяться этими командами. Однако эти команды производят сверку следующих данных с информацией из внешней базы данных службы имен:
уникальность имени пользователя (или роли),
уникальность идентификатора пользователя,
существование указанных имен групп.
Для получения дополнительной информации см. справочные страницы passmgmt(1M), useradd(1M), usermod(1M) и user_attr(4).
Данные о проектах могут храниться в локальном файле, в карте проектов сетевой информационной службы (NIS), либо в службе каталогов протокола LDAP. Файл /etc/project или служба имен используются подключаемым модулем аутентификации (PAM) для связывания пользователя с проектом по умолчанию при входе в систему, а также при всех запросах на управление учетными записями.
Обновления записей в базе данных проектов, будь то файл /etc/project или представление базы данных в сетевой службе имен, не применяются к проектам, активным в текущий момент. Обновления применяются к новым задачам, присоединяющимся к проекту, при использовании команд login или newtask. Для получения дополнительной информации см. справочные страницы login(1) и newtask(1).
К операциям, изменяющим или задающим идентификаторы, относятся вход в систему, вызов команд 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).
Если в качестве источника базы данных project в файле nsswitch.conf выбрано значение files, процесс регистрации выполняет поиск информации о проекте в файле /etc/project. Для получения дополнительной информации см. справочные страницы projects(1) и project(4).
В файле project для каждого проекта, распознаваемого системой, содержится по одной строке следующей формы:
projname:projid:comment:user-list:group-list:attributes |
Поля определены следующим образом:
Имя проекта. Имя должно представлять собой строку, содержащую алфавитно-цифровые символы, знаки подчеркивания (_), дефисы (-) и точки (.). Символ точки зарезервирован для проектов, имеющих особую значимость для операционной системы, и может использоваться только в именах проектов по умолчанию для пользователей. projname не может содержать двоеточия (: ) и символы разрыва строки.
Уникальный числовой идентификатор проекта (PROJID) внутри системы. Максимальное значение поля projid – UID_MAX (2147483647).
Описание проекта.
Разделенный запятыми список пользователей, которым разрешено участие в проекте.
В этом поле могут использоваться групповые символы. Знак звездочки (*) разрешает всем пользователям присоединяться к проекту. Символ восклицательного знака, после которого находится символ звездочки (!*), исключает всех пользователей из проекта. Символ восклицательного знака (!), после которого указывается имя пользователя, исключает из проекта указанного пользователя.
Разделенный запятыми список групп пользователей, которым разрешено участие в проекте.
В этом поле могут использоваться групповые символы. Знак звездочки (*) разрешает всем группам присоединяться к проекту. Символ восклицательного знака, после которого находится символ звездочки (!*), исключает все группы из проекта. Символ восклицательного знака (!), после которого указывается имя группы, исключает из проекта указанную группу.
Разделенный точками с запятыми список пар "имя-значение", например элементов управления ресурсами (см. Глава 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, в файле /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, в файле /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).
Каждая успешная регистрация в проекте приводит к созданию новой задачи, содержащей процесс регистрации. Задача – совокупность процессов, представляющая собой набор работ во времени. Задачу также можно рассматривать как компонент рабочей нагрузки. Каждой задаче автоматически присваивается идентификатор.
Каждый процесс участвует в одной задаче, а каждая задача связана с одним проектом.
Для задач также поддерживаются все операции над группами процессов, например, доставка сигнала. Задачу можно связать с набором процессоров и назначить приоритет и класс планирования задачи, в результате чего изменятся все текущие и будущие процессы задачи.
Задача создается при каждом присоединении проекта. Задачи создаются следующими действиями, командами и функциями:
вход в систему
cron
newtask
setproject
su
Одним из следующих методов можно создать т.н. финализированную задачу. Это означает, что все дальнейшие попытки создания новых задач будут неуспешными.
Можно использовать команду newtask с параметром - F.
Для проекта в базе данных task.final службы имен можно установить атрибут project. Все задачи, создаваемые в данном проекте командой setproject, будут иметь флаг TASK_FINAL.
Для получения дополнительной информации см. справочные страницы login(1), newtask(1), cron(1M), su(1M) и setproject(3PROJECT).
Для получения учетных данных по процессам может использоваться подсистема расширенного учета. Данные агрегируются на уровне задачи.
Команды, показанные в следующей таблице, обеспечивают главный административный интерфейс к средствам проектов и задач.
Ссылка на справочную страницу |
Описание |
---|---|
Вывод членства пользователей в проектах. Вывод списка проектов из базы данных project. Выводится информация по данным проектам. Если имена проектов не указаны, информация отображается по всем проектам. Для получения более подробных данных следует выполнить команду projects с параметром -l. |
|
Выполнение оболочки пользователя по умолчанию или указанной команды, причем выполняемая команда помещается в новую задачу, подчиненную указанному проекту. Команду newtask также можно использовать для изменения привязки выполняемого процесса к задаче или проекту. Параметр -F используется для создания финализированной задачи. |
|
Обновление информации в файлах паролей. Параметр -K ключ=значение позволяет добавлять или изменять атрибуты пользователей в локальных файлах. |
|
Добавление новой записи проекта в файл /etc/project. Команда projadd позволяет создать запись проекта только в локальной системе. Команда projadd не может изменять информацию, предоставляемую сетевой службой имен. Используется для редактирования файлов проекта, отличных от файла по умолчанию – /etc/project . Выполняется проверка синтаксиса для файла project. Атрибуты проекта проверяются на допустимость и редактируются. Предусмотрена поддержка кратных величин. |
|
Изменение информации для проекта в локальной системе. Команда projmod не может изменять информацию, предоставляемую сетевой службой имен. Однако по этой команде выполняется сверка названия и идентификатора проекта с внешней службой имен в целях проверки уникальности. Используется для редактирования файлов проекта, отличных от файла по умолчанию – /etc/project . Выполняется проверка синтаксиса для файла project. Атрибуты проекта проверяются на допустимость и редактируются. Команда может использоваться для добавления новых атрибутов, для добавления значений к атрибуту или для удаления атрибута. Предусмотрена поддержка кратных величин. Начиная с Solaris версии 10 5/08 для применения значений элементов управления ресурсами из базы данных проектов к текущему проекту может использоваться параметр -A. Существующие значения, которые не совпадают со значениями, определенными в файле project (например, значения, заданные вручную посредством команды prctl) удаляются. |
|
Удаление проекта из локальной системы. Команда projdel не позволяет изменять информацию, предоставляемую сетевой службой имен. |
|
Добавление определений проектов по умолчанию в локальные файлы. Параметр -K ключ=значение позволяет добавлять или заменять атрибуты пользователей. |
|
Удаление учетной записи пользователя из локального файла. |
|
Изменение регистрационных данных пользователя в системе. Параметр -K ключ=значение позволяет добавлять или заменять атрибуты пользователей. |
В этой главе рассматривается использование проектов и задач для управления ресурсами Solaris.
Рассматриваются следующие темы:
Краткое описание средств проектов и задач приведены в Глава 2Проекты и задачи (обзор).
Если эти средства используются в системе Solaris с установленными зонами, то через интерфейсы системных вызовов, получающие на входе идентификаторы процессов и выполняемые в неглобальной зоне, видны только процессы в той же зоне.
Задача |
Описание |
Инструкции |
---|---|---|
Просмотр примеров команд и параметров, используемых с проектами и задачами |
Вывод идентификаторов задач и проектов, а также разнообразной статистики по выполняющимся в настоящее время процессам и проектам. | |
Определение проекта |
Добавление записи проекта к файлу /etc/project и изменение значений для этой записи. | |
Удаление проекта |
Удаление записи проекта из файла /etc/project. | |
Проверка допустимости файла project или базы данных проектов. |
Проверка синтаксиса файла /etc/project или сверка названия и идентификатора проекта с внешней службой имен в целях проверки уникальности. | |
Получение информации о членстве в проекте |
Вывод текущего членства вызывающего процесса в проекте. | |
Создание новой задачи |
Создание новой задачи в определенном проекте командой newtask. | |
Связывание выполняемого процесса с другой задачей и проектом |
Связывание номера процесса с новым идентификатором задачи в указанном проекте. | |
Добавление атрибутов проектов и работа с ними |
Добавление, редактирование, проверка допустимости и удаление атрибутов проектов командами административного управления базами данных проектов. |
В этом разделе приводятся примеры команд и параметров, используемых с проектами и задачами.
По команде ps с параметром -o отображаются идентификаторы задач и проектов. Например, для просмотра идентификатора проекта используется следующая команда:
# ps -o user,pid,uid,projid USER PID UID PROJID jtd 89430 124 4113 |
Команда id с параметром -pпозволяет в дополнение к идентификаторам пользователя и группы вывести текущий идентификатор проекта. Если указывается операнд user, то отображается проект, связанный с нормальной учетной записью этого пользователя:
# id -p uid=124(jtd) gid=10(staff) projid=4113(booksite) |
Если необходимо выполнить сопоставление только процессов с идентификаторами проектов из определенного списка, можно воспользоваться командами pgrep и pkill с параметром -J:
# pgrep -J projidlist # pkill -J projidlist |
Если необходимо отобразить сопоставление только для процессов, идентификаторы задач которых входят в определенный список, можно воспользоваться командами pgrep и pkill с параметром -T:
# pgrep -T taskidlist # pkill -T taskidlist |
Команда 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 использует функцию settaskid, что позволяет обеспечить выполнение каждого задания cron, at и batch в отдельной задаче, с соответствующим проектом по умолчанию для пользователя, отправляющего его на выполнение. Команды at и batch также сохраняют текущий идентификатор проекта, что позволяет обеспечить восстановление идентификатора проекта при выполнении задания at.
Команда su присоединяется к проекту по умолчанию целевого пользователя путем создания новой задачи в порядке симуляции входа в систему.
Для переключения проекта пользователя по умолчанию с помощью команды su введите:
# su user |
В этом примере показано добавление записи проекта командой projadd и изменение этой записи командой projmod.
Перейдите в режим суперпользователя или воспользуйтесь эквивалентной ролью.
Роли содержат подтвержденные полномочия и привилегированные команды. Для получения дополнительной информации о ролях см. раздел Using the Solaris Management Tools With RBAC (Task Map) в System Administration Guide: Basic Administration.
Отобразите файл /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: |
Добавьте проект с именем booksite. Назначьте проект пользователю с именем mark и укажите идентификатор проекта 4113.
# projadd -U mark -p 4113 booksite |
Снова просмотрите файл /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: |
Добавьте в поле комментария описание проекта.
# projmod -c `Book Auction Project' booksite |
Просмотрите изменения в файле /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: |
Инструкции по связыванию проектов, задач и процессов с пулом приведены в Установка атрибутов пулов и связывание с пулом.
В этом примере показан способ удаления проекта командой projdel.
Перейдите в режим суперпользователя или воспользуйтесь эквивалентной ролью.
Роли содержат подтвержденные полномочия и привилегированные команды. Для получения дополнительной информации о ролях см. раздел Using the Solaris Management Tools With RBAC (Task Map) в System Administration Guide: Basic Administration.
Удалите проект booksite командой projdel.
# projdel booksite |
Просмотрите файл /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: |
Войдите в систему как пользователь mark и введите команду projects для просмотра проектов, назначенных этому пользователю.
# su - mark # projects default |
При отсутствии параметров редактирования команда 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) |
Войдите в систему как участник целевого проекта booksite.
Создайте новую задачу в проекте booksite с помощью команды newtask с параметром - v (подробный режим) для получения системного идентификатора задачи.
machine% newtask -v -p booksite 16 |
По команде newtask в указанном проекте создается новая задача, и в эту задачу помещается интерпретатор команд пользователя по умолчанию.
Просмотрите текущие данные по членству вызывающего процесса в проекте следующей командой.
machine% id -p uid=100(mark) gid=1(other) projid=4113(booksite) |
Процесс теперь является членом нового проекта.
В этом примере показано связывание выполняемого процесса с другой задачей и с новым проектом. Для этого необходимо либо стать суперпользователем, либо быть владельцем процесса и членом нового проекта.
Перейдите в режим суперпользователя или воспользуйтесь эквивалентной ролью.
Роли содержат подтвержденные полномочия и привилегированные команды. Для получения дополнительной информации о ролях см. раздел Using the Solaris Management Tools With RBAC (Task Map) в System Administration Guide: Basic Administration.
Если текущий пользователь является владельцем процесса или членом нового проекта, этот этап можно пропустить.
Определите идентификатор процесса book_catalog.
# pgrep book_catalog 8100 |
Свяжите процесс 8100 с новым идентификатором задачи в проекте booksite.
# newtask -v -p booksite -c 8100 17 |
Параметр -c указывает, что команда newtask должна быть выполнена в отношении существующего именованного процесса.
Проверьте связь идентификаторов задачи и процесса.
# pgrep -T 17 8100 |
Для редактирования атрибутов проекта используются команды администрирования базы данных проектов projadd и projmod.
Параметр -K позволяет указать альтернативный список атрибутов. Атрибуты разграничиваются символом точки с запятой (;). Если параметр -K используется с параметром -a, атрибут или значение атрибута добавляется. Если параметр -K используется с параметром -r, атрибут или значение атрибута удаляется. Если параметр -K используется с параметром - s, выполняется замена атрибута или значения атрибута.
Для добавления значений к атрибуту проекта используется команда projmod с параметрами -a и - K. Если атрибут не существует, он создается.
Перейдите в режим суперпользователя или воспользуйтесь эквивалентной ролью.
Роли содержат подтвержденные полномочия и привилегированные команды. Для получения дополнительной информации о ролях см. раздел Using the Solaris Management Tools With RBAC (Task Map) в System Administration Guide: Basic Administration.
Добавьте атрибут элемента управления ресурсами без значений task.max-lwps в проект myproject. Задача, вступающая в проект, оперирует только системным значением для этого атрибута.
# projmod -a -K task.max-lwps myproject |
Затем можно добавить значение для task.max-lwps в проекте myproject. Значение состоит из уровня полномочий, порогового значения и действия в случае достижения этого порогового значения.
# projmod -a -K "task.max-lwps=(priv,100,deny)" myproject |
Поскольку элементы управления ресурсами могут иметь несколько значений, той же командой к списку существующих значений можно добавить дополнительные значения.
# 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) |
Перейдите в режим суперпользователя или воспользуйтесь эквивалентной ролью.
Роли содержат подтвержденные полномочия и привилегированные команды. Для получения дополнительной информации о ролях см. раздел Using the Solaris Management Tools With RBAC (Task Map) в System Administration Guide: Basic Administration.
Для удаления значения атрибута из элемента управления ресурсами 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.
Перейдите в режим суперпользователя или воспользуйтесь эквивалентной ролью.
Роли содержат подтвержденные полномочия и привилегированные команды. Для получения дополнительной информации о ролях см. раздел Using the Solaris Management Tools With RBAC (Task Map) в System Administration Guide: Basic Administration.
Удалите атрибут task.max-lwps и все его значения из проекта myproject:
# projmod -r -K task.max-lwps myproject |
Для подстановки другого значения атрибута task.max-lwps в проекте myproject используется команда projmod с параметрами -s и -K. Если атрибут не существует, он создается.
Перейдите в режим суперпользователя или воспользуйтесь эквивалентной ролью.
Роли содержат подтвержденные полномочия и привилегированные команды. Для получения дополнительной информации о ролях см. раздел Using the Solaris Management Tools With RBAC (Task Map) в System Administration Guide: Basic Administration.
Замените текущие значения 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) |
Перейдите в режим суперпользователя или воспользуйтесь эквивалентной ролью.
Роли содержат подтвержденные полномочия и привилегированные команды. Для получения дополнительной информации о ролях см. раздел Using the Solaris Management Tools With RBAC (Task Map) в System Administration Guide: Basic Administration.
Для удаления текущих значений task.max-lwps из проекта myproject введите следующую команду:
# projmod -s -K task.max-lwps myproject |
Контроль потребления ресурсов каждой задачей достигается путем классификации и разделения задач с помощью средств работы с процессами и задачами, описанными в Глава 2Проекты и задачи (обзор). Для регистрации подробной статистики потребления ресурсов по процессам и по задачам используется подсистема расширенного учета.
В этой главе рассматриваются следующие темы.
Вводная информация по использованию расширенного учета приведена в Активация расширенного учета для процессов, задач и потоков.
Добавлена возможность генерации данных 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Проекты и задачи (обзор).
Формат расширенного учета существенно более гибок с точки зрения расширения по сравнению со старым форматом учета системных ресурсов SunOSTM (см. What is System Accounting? в System Administration Guide: Advanced Administration). Расширенный учет позволяет добавлять и удалять метрики учета в системе – как при переходе с одной версии на другую, так и во время нормальной работы системы.
Допускается одновременное использование расширенного учета и программного обеспечения учета системных ресурсов старого образца.
Программы, допускающие создание записей exacct, служат двум целям:
возможность создания сторонних файлов exacct;
возможность создания записей маркировки, внедряемых в учетный файл ядра системным вызовом putacct (см. getacct(2)).
Системный вызов putacct также доступен из интерфейса Perl.
Формат допускает регистрацию различных форм учетных записей, причем изменения не обязательно должны представлять собой явные изменения версии. Качественные приложения, в которых используются данные учета, должны игнорировать непонятные им записи.
Для преобразования и создания файлов в формате exacct используется библиотека libexacct. Эта библиотека является единственным поддерживаемым интерфейсом к файлам формата exacct.
Системные вызовы getacct, putacct и wracct не применимы к потокам. Если настроен потоковый учет IPQoS, ядро создает записи потока и записывает их в файл.
При работе в глобальной зоне подсистема расширенного учета выполняет сбор и выдачу информации для всей системы (включая неглобальные зоны). Потребление ресурсов также может задаваться для отдельных зон глобальным администратором. Для получения дополнительной информации см. Расширенный учет в системе Solaris с установленными зонами.
Текущая конфигурация расширенного учета содержится в файле /etc/acctadm.conf. Этот файл редактируется через интерфейс acctadm ; непосредственное редактирование пользователем не допускается.
Стандартным расположением данных расширенного учета является каталог /var/adm/exacct. Для указания другого места назначения для файлов данных учета процессов и задач используется команда acctadm. Для получения дополнительной информации см. acctadm(1M).
Справочная информация по командам |
Описание |
---|---|
Изменение различных атрибутов подсистемы расширенного учета, остановка и запуск расширенного учета, а также выбор атрибутов учета, которые требуется отслеживать для процессов, задач и потоков. |
|
Регистрация записей расширенного учета для активных процессов и задач. |
|
Вывод ранее введенных команд. Команда lastcomm принимает на входе либо стандартные данные процесса учета, либо данные процесса расширенного учета. |
Информацию по командам, связанным с задачами и проектами, приведены в Примеры команд и их параметров. Информацию по учету потоков IPQoS приведены в ipqosconf(1M).
Интерфейс 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 подразделяются на два типа:
элементы, представляющие собой одиночные значения данных (скаляры);
группы, представляющие собой списки элементов.
В следующей таблице дается краткая характеристика каждого из модулей.
Модуль (не должен содержать пробелов) |
Описание |
Дополнительная информация |
---|---|---|
Sun::Solaris::Project |
Этот модуль предоставляет функции для доступа к функциям манипулирования проектами getprojid(2), endprojent(3PROJECT) , fgetprojent(3PROJECT), getdefaultproj(3PROJECT), getprojbyid(3PROJECT), getprojbyname(3PROJECT), getprojent(3PROJECT), getprojidbyname(3PROJECT), inproj(3PROJECT), project_walk(3PROJECT), setproject(3PROJECT) и setprojent(3PROJECT). |
Project(3PERL) |
Sun::Solaris::Task |
Этот модуль предоставляет функции для доступа к функциям манипулирования задачами gettaskid(2) и settaskid(2). |
Task(3PERL) |
Sun::Solaris::Exacct |
Это модуль верхнего уровня exacct. Этот модуль предоставляет функции для доступа к системным вызовам, связанным с exacct getacct(2), putacct(2) и wracct(2). Этот модуль также предоставляет функции для доступа к средствам библиотеки libexacct(3LIB) ea_error(3EXACCT). Также в этом модуле содержатся константы для всех макросов exacct EO_*, EW_*, EXR_*, P_* и TASK_*. |
Exacct(3PERL) |
Sun::Solaris::Exacct:: Catalog |
В этом модуле содержатся объектно-ориентированные методы для доступа к битовым полям тега каталога exacct. Модуль также используется для доступа к константам для макросов EXC_*, EXD_* и EXD_*. |
Exacct::Catalog(3PERL) |
Sun::Solaris::Exacct:: File |
Этот модуль предоставляет объектно-ориентированные методы для доступа к функциям учетного файла libexacct ea_open(3EXACCT), ea_close(3EXACCT), ea_get_creator(3EXACCT), ea_get_hostname(3EXACCT), ea_next_object(3EXACCT), ea_previous_object(3EXACCT) и ea_write_object(3EXACCT). |
Exacct::File(3PERL) |
Sun::Solaris::Exacct:: Object |
Этот модуль предоставляет объектно-ориентированные методы для доступа к отдельным объектам учетного файла exacct. Объект exacct представляется в виде непрозрачной ссылки, создаваемой (bless) в соответствующем подклассе Sun::Solaris::Exacct::Object . Этот модуль далее подразделяется на типы объектов Item (элемент) и Group (группа). На этом уровне имеются методы для доступа к функциям ea_match_object_catalog(3EXACCT) и ea_attach_to_object(3EXACCT). |
Exacct::Object(3PERL) |
Sun::Solaris::Exacct:: Object::Item |
Этот модуль предоставляет объектно-ориентированные методы для доступа к отдельным элементам учетного файла exacct. Объекты этого типа являются наследниками Sun::Solaris::Exacct::Object. |
Exacct::Object::Item(3PERL) |
Sun::Solaris::Exacct:: Object::Group |
Этот модуль предоставляет объектно-ориентированные методы для доступа к отдельным группам учетного файла exacct. Объекты этого типа являются наследниками Sun::Solaris::Exacct::Object. Эти объекты предоставляют доступ к функции ea_attach_to_group(3EXACCT). Элементы, содержащиеся внутри группы, представляются в виде массива Perl. |
Exacct::Object::Group(3PERL) |
Sun::Solaris::Kstat |
Этот модуль предоставляет увязанный с Perl интерфейс хеширования для средства kstat. Примером использования этого модуля может служить /bin/kstat, написанный на Perl. |
Kstat(3PERL) |
Примеры использования модулей, описанных в предыдущей таблице, приведены в Использование интерфейса Perl для libexacct.
В этой главе описывается администрирование подсистемы расширенного учета.
Краткое описание подсистемы расширенного учета приведены в Глава 4Расширенный учет (обзор).
Задача |
Описание |
Инструкции |
---|---|---|
Активация подсистемы расширенного учета |
Расширенный учет используется для контроля потребления ресурсов каждым проектом, выполняющимся в системе. Подсистема расширенного учета позволяет регистрировать данные истории для задач, процессов и потоков. |
Активация расширенного учета для процессов, задач и потоков, Активация расширенного учета при помощи сценария запуска |
Отображение состояния расширенного учета |
Позволяет выяснить состояние подсистемы расширенного учета. | |
Просмотр доступных ресурсов учета |
Позволяет просмотреть ресурсы учета, доступные в системе. | |
Деактивация функциональности учета для процессов, задач потоков |
Выключение функциональных возможностей расширенного учета. | |
Использование интерфейса Perl к подсистеме расширенного учета |
Интерфейс Perl используется для разработки собственных сценариев создания отчетов и извлечения данных. |
Для активации расширенного учета задач, процессов и потоков используется команда acctadm. Дополнительный последний параметр команды acctadm указывает, должна ли команда воздействовать на компоненты подсистемы расширенного учета для процессов, системных задач или потоков.
Перейдите в режим суперпользователя или воспользуйтесь эквивалентной ролью.
Роли содержат подтвержденные полномочия и привилегированные команды. Для получения дополнительной информации о ролях см. Using the Solaris Management Tools With RBAC (Task Map) в System Administration Guide: Basic Administration.
Активируйте расширенный учет для процессов.
# acctadm -e extended -f /var/adm/exacct/proc process |
Активируйте расширенный учет для задач.
# acctadm -e extended,mstate -f /var/adm/exacct/task task |
Активируйте расширенный учет для потоков.
# 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.
Перейдите в режим суперпользователя или воспользуйтесь эквивалентной ролью.
Роли содержат подтвержденные полномочия и привилегированные команды. Для получения дополнительной информации о ролях см. Using the Solaris Management Tools With RBAC (Task Map) в System Administration Guide: Basic Administration.
Отключите учет для процессов.
# acctadm -x process |
Отключите учет для задач.
# acctadm -x task |
Отключите учет для потоков.
# acctadm -x flow |
Проверьте отключение учета для задач, процессов и потоков.
# 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 |
Для рекурсивного вывода содержимого объекта 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; |
Следующий сценарий на 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() над файлом, созданным в Создание новой записи группы с записью в файле.
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 |
После определения потребления ресурсов рабочими задачами в системе в соответствии с Глава 4Расширенный учет (обзор) можно задать ограничения по использованию ресурсов. Ограничения позволяют предотвратить чрезмерное потребление ресурсов рабочими нагрузками. В качестве механизма ограничения используются элементы управления ресурсами.
В этой главе рассматриваются следующие темы:
Для получения информации об администрировании элементов управления ресурсами см.Глава 7Администрирование элементов управления ресурсами (задачи).
Набор элементов управления ресурсами, приведенный ниже, заменяет собой настраиваемые средства взаимодействия процессов (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).
Таблица 6–1 Стандартные элементы управления ресурсами
Имя элемента управления |
Описание |
Единица по умолчанию |
---|---|---|
project.cpu-cap |
Solaris 10 8/07:абсолютное ограничение по количеству ресурсов ЦП, потребляемых проектом. Значение 100 означает, что в качестве project.cpu-cap задано 100% одного ЦП. Значение 125 соответствует 125%, т.к. 100% – это один полностью загруженный ЦП в системе при использовании ограничений по ЦП. |
Количество (число ЦП) |
project.cpu-shares |
Число долей ЦП, выделенных данному проекту планировщиком долевого распределения (FSS) (см. FSS(7)). |
Количество (доли) |
project.max-crypto-memory |
Общий объем памяти ядра, который может использоваться libpkcs11 для аппаратного ускорения криптографических операций. На основании этого элемента управления ресурсами определяются ограничения буферов ядра и связанных с сеансом структур. |
Размер (байты) |
project.max-locked-memory |
Общее количество разрешенной физической блокированной памяти. Если пользователю назначается priv_proc_lock_memory, следует рассмотреть возможность установки также и этого элемента управления ресурсами для предотвращения блокирования пользователем всей памяти. Solaris 10 8/07: Следует отметить, что в Solaris 10 8/07 этот элемент управления ресурсами заменяет изъятый элемент project.max-device-locked-memory. |
Размер (байты) |
project.max-port-ids |
Максимальное допустимое количество портов событий. |
Количество (число портов событий) |
project.max-sem-ids |
Максимальное количество идентификаторов семафоров, разрешенное для этого проекта. |
Количество (идентифика- торы семафоров) |
project.max-shm-ids |
Максимальное количество идентификаторов совместно используемой памяти, разрешенное для этого проекта. |
Количество (идентифика- торы совместно используемой памяти) |
project.max-msg-ids |
Максимальное количество идентификаторов очереди сообщений, разрешенное для этого проекта. |
Количество (идентифика- торы очередей сообщений) |
project.max-shm-memory |
Общий объем совместно используемой памяти System V, разрешенный для этого проекта. |
Размер (байты) |
project.max-lwps |
Максимальное количество LWP, одновременно доступных этому проекту. |
Количество (LWP) |
project.max-tasks |
Максимальное количество задач, разрешенных для этого проекта. |
Количество (число задач) |
project.max-contracts |
Максимальное количество контрактов, разрешенных для этого проекта. |
Количество (контрактов) |
task.max-cpu-time |
Максимальное процессорное время, доступное процессам этой задачи. |
Время (секунды) |
task.max-lwps |
Максимальное количество LWP, одновременно доступных процессам этой задачи. |
Количество (LWP) |
process.max-cpu-time |
Максимальное процессорное время, доступное этому процессу. |
Время (секунды) |
process.max-file-descriptor |
Максимальный индекс дескриптора файла, доступный этому процессу. |
Индекс (максимальный дескриптор файла) |
process.max-file-size |
Максимальное смещение в файле, доступное данному проекту для записи. |
Размер (байты) |
process.max-core-size |
Максимальный размер файла дампа оперативной памяти, создаваемого этим процессом. |
Размер (байты) |
process.max-data-size |
Максимальный размер кучи, доступной этому процессу. |
Размер (байты) |
process.max-stack-size |
Максимальный сегмент памяти стека, доступный этому процессу. |
Размер (байты) |
process.max-address-space |
Максимальный размер адресного пространства, полученный суммированием размеров сегментов, доступных данному процессу. |
Размер (байты) |
process.max-port-events |
Максимально допустимое количество событий для каждого порта события. |
Количество (число событий) |
process.max-sem-nsems |
Максимальное количество идентификаторов семафоров, разрешенных для набора семафоров. |
Количество (семафоров в наборе) |
process.max-sem-ops |
Максимальное количество операций семафора, разрешенных для одного вызова semop (значение, скопированное из элемента управления ресурсами в момент времени semget()). |
Количество (число операций) |
process.max-msg-qbytes |
Максимальное количество байт сообщений в очереди сообщений (значение, скопированное из элемента управления ресурсами в момент времени msgget()). |
Размер (байты) |
process.max-msg-messages |
Максимальное количество сообщений в очереди сообщений (значение, скопированное из элемента управления ресурсами в момент времени msgget()). |
Количество (число сообщений) |
Таким образом можно отобразить значения по умолчанию для элементов управления ресурсами в системе, в которой элементы управления ресурсами не задавались и не изменялись. В подобной системе в /etc/system или в базе данных project отсутствуют записи, отличные от значений по умолчанию. Для вывода значений используется команда prctl.
Элементы управления ресурсами всей зоны позволяют ограничить суммарное потребление ресурсов всеми экземплярами процессов внутри зоны. Параметры управления ресурсами для всей зоны можно установить с помощью глобальных имен свойств, описанных в Установка элементов управления ресурсами всей зоны и Настройка зоны.
Таблица 6–2 Элементы управления ресурсами всей зоны
Имя элемента управления |
Описание |
Единица по умолчанию |
---|---|---|
zone.cpu-cap |
Solaris 10 5/08: Абсолютное ограничение по количеству ресурсов ЦП, потребляемых неглобальной зоной. Значение 100 означает, что в качестве project.cpu-cap задано 100% одного ЦП. Значение 125 соответствует 125%, т.к. 100% – это один полностью загруженный ЦП в системе при использовании ограничений по ЦП. |
Количество (число ЦП) |
zone.cpu-shares |
Количество процессорных долей в соответствии с планировщиком долевого распределения (FSS) для этой зоны. |
Количество (доли) |
zone.max-locked-memory |
Общее количество доступной зоне физической блокированной памяти. Если зоне назначается priv_proc_lock_memory, следует рассмотреть возможность задания также и этого элемента управления ресурсами для предотвращения блокирования зоной всей памяти. |
Размер (байты) |
zone.max-lwps |
Максимальное количество LWP, одновременно доступных этой зоне. |
Количество (LWP) |
zone.max-msg-ids |
Максимальное количество идентификаторов очередей сообщений, разрешенное для этой зоны. |
Количество (идентифика- торы очередей сообщений) |
zone.max-sem-ids |
Максимальное количество идентификаторов семафоров, разрешенных для этой зоны. |
Количество (идентифика- торы семафоров) |
zone.max-shm-ids |
Максимальное количество идентификаторов совместно используемой памяти, разрешенных для этой зоны. |
Количество (идентифика- торы совместно используемой памяти) |
zone.max-shm-memory |
Общий объем совместно используемой памяти System V, разрешенный для этой зоны. |
Размер (байты) |
zone.max-swap |
Общий объем подкачки, доступный для потребления при отображении адресного пространства пользовательских процессов и файловых систем tmpfs в этой зоне. |
Размер (байты) |
Для получения информации о настройке элементов управления ресурсами для всей зоны см. Свойства типов ресурса и Настройка зоны. Информацию по использованию элементов управления ресурсами для всей зоны в типизированных зонах lx приведены в Настройка, проверка и сохранение параметров типизированной зоны lx.
Следует отметить, что общезоновый элемент управления ресурсами можно применить и к глобальной зоне. Для получения дополнительной информации см. Глава 17Настройка неглобальной зоны (обзор) и Использование планировщика долевого распределения в системе Solaris с установленными зонами.
Для всех элементов управления ресурсами определяются глобальные флаги, идентифицирующие типы элементов управления ресурсами. Флаги используются для передачи базовой информации приложениям, например команде prctl. Эта информация используется приложениями для определения следующих значений:
строки единиц измерения, подходящих для каждого элемента управления ресурсами;
правильного масштаба для интерпретации масштабируемых значений.
Доступны следующие глобальные флаги:
Глобальный флаг |
Строка типа элемента управления ресурсами |
Модификатор |
Шкала |
---|---|---|---|
RCTL_GLOBAL_BYTES |
bytes |
B |
1 |
|
KB |
210 |
|
|
MB |
220 |
|
|
GB |
230 |
|
|
TB |
240 |
|
|
PB |
250 |
|
|
EB |
260 |
|
RCTL_GLOBAL_SECONDS |
seconds |
s |
1 |
|
Ks |
103 |
|
|
Ms |
106 |
|
|
Gs |
109 |
|
|
Ts |
1012 |
|
|
Ps |
1015 |
|
|
Es |
1018 |
|
RCTL_GLOBAL_COUNT |
count |
none |
1 |
|
K |
103 |
|
|
M |
106 |
|
|
G |
109 |
|
|
T |
1012 |
|
|
P |
1015 |
|
|
E |
1018 |
С элементами управления ресурсами могут использоваться кратные единицы. В следующем примере демонстрируется пороговое значение в кратных единицах:
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=. Эти три действия используются следующим образом:
Действия в отношении запросов ресурсов в объемах, превышающих пороговое значение, не производятся. Это действие удобно использовать для наблюдения использования ресурса без воздействия на ход выполнения приложений. Также можно задать глобальное сообщение, информирующее о превышении элемента управления ресурсами, но не затрагивающее процесс, превысивший порог.
Отклонение запросов ресурсов в объеме, превышающем пороговое значение. Например, элемент управления ресурсами task.max-lwps с действием deny приводит к отказу системного вызова fork, если новый процесс попробует превысить управляющее значение. См. справочную страницу fork(2).
Для случаев превышения элемента управления ресурсами можно задать глобальное действие, сводящееся к выдаче сигнального сообщения. Сигнал передается процессу при превышении порогового значения. Если процесс продолжает потреблять дополнительные ресурсы, новые сигналы не выдаются. Список доступных сигналов приведен в Таблица 6–3.
Не все действия можно применить к каждому элементу управления ресурсами. Например, процесс не может превысить количество долей ЦП, назначенных проекту, членом которого он является. Поэтому действие deny для элемента управления ресурсами project.cpu-shares не допускается.
Вследствие ограничений, связанных с реализацией, глобальные свойства каждого элемента управления могут ограничивать диапазон доступных действий, которые могут быть заданы для порогового значения. См. справочную страницу rctladm(1M). Список доступных сигнальных действий приведен в следующей таблице. Для получения дополнительной информации о сигналах см. справочную страницу signal(3HEAD).
Таблица 6–3 Сигналы, доступные для значений элементов управления ресурсами
Сигнал |
Описание |
Примечания |
---|---|---|
SIGABRT |
Завершение процесса. |
|
SIGHUP |
Передача сигнала опускания трубки. Возникает при пропадании несущей в открытой линии. Сигнал передается в группу процессов, управляющих терминалом. |
|
SIGTERM |
Завершение процесса. Сигнал завершения, отправляемый программным обеспечением. |
|
SIGKILL |
Завершение процесса и закрытие (kill) программы. |
|
SIGSTOP |
Остановка процесса. Сигнал управления заданиями. |
|
SIGXRES |
Превышение предела элемента управления ресурсами. Генерируется механизмом элементов управления ресурсами. |
|
SIGXFSZ |
Завершение процесса. Превышение предела размера файла. |
Доступен только для элементов управления ресурсами со свойством RCTL_GLOBAL_FILE_SIZE (process.max-file-size). Для получения дополнительной информации см.rctlblk_set_value(3C). |
SIGXCPU |
Завершение процесса. Превышение ограничения по процессорному времени. |
Доступен только для элементов управления ресурсами со свойством RCTL_GLOBAL_CPUTIME (process.max-cpu-time). Для получения дополнительной информации см.rctlblk_set_value(3C). |
С каждым элементом управления ресурсами в системе связан определенный набор свойств. Этот набор свойств определяется как набор флагов, связанных со всеми управляемыми экземплярами данного ресурса. Глобальные флаги не подлежат изменению, однако могут быть считаны с помощью системных вызовов 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 ] |
Глобальные флаги имеют следующие значения.
Для снижения привилегированных значений для данного элемента управления не требуются полномочия суперпользователя.
Даже в случае превышения пороговых значений доступ к ресурсу никогда не запрещается.
По достижении пороговых значений для этого ресурса возможна передача SIGXCPU.
Значение времени для элемента управления ресурсами.
Значения элемента управления ресурсами с типом полномочий basicзадать невозможно. Установка значений допускается только для привилегированных элементов управления ресурсами.
Задать локальные сигнальные действия для значений элементов управления ресурсами невозможно.
Для этого элемента управления ресурсами невозможно определить глобальное действие сообщения syslog.
Отклонение запросов на ресурс при превышении пороговых значений.
Значение счетчика (целое число) для элемента управления ресурсами.
Единица измерения для элемента управления ресурсами.
Для отображения локальных значений и действий для элемента управления ресурсами используется команда 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.
Нередко потребление ресурсов процессами неизвестно. Для получения дополнительной информации можно воспользоваться глобальными действиями элементов управления ресурсами, доступными по команде 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. Можно добавлять как базовые, так и привилегированные значения. Также имеется возможность изменения связанных действий. По умолчанию для всех операций настройки предполагается базовый тип, однако процессы и пользователи с полномочиями суперпользователя также могут изменять привилегированные элементы управления ресурсами. Изменение элементов управления ресурсами системы не допускается.
В приведенной ниже таблице перечислены команды, используемые с элементами управления ресурсами.
Справочная информация по командам |
Описание |
---|---|
Позволяет определить, какие объекты IPC вносят вклад в использование ресурсов проектом. |
|
Позволяет проводить опрос и модификацию средств элементов управления ресурсами в локальной области действия. |
|
Позволяет проводить опрос и модификацию средств элементов управления ресурсами в глобальной области действия. |
На справочной странице resource_controls(5) описаны элементы управления ресурсами, доступные в базе данных project, включая единицы измерения и коэффициенты масштабирования.
В этой главе описывается администрирование элементов управления ресурсами.
Краткое описание механизма элементов управления ресурсами приведены в Глава 6Элементы управления ресурсами (обзор).
Задача |
Описание |
Инструкции |
---|---|---|
Настройка элементов управления ресурсами |
Элементы управления ресурсами для проектов настраиваются в файле /etc/project. | |
Получение или пересмотр значений элементов управления ресурсов для активных процессов, задач или проектов в локальной области действия. |
Опрос или изменение в рабочем режиме элементов управления ресурсами, связанных с активным процессом, задачей или проектом. | |
Просмотр или обновление глобального состояния элементов управления ресурсами в работающей системе |
Просмотр глобального состояния журналирования каждого элемента управления ресурсами по всей системе. Кроме того, настройка уровня журналирования syslog при превышении значений элементов управления. | |
Отчет о состоянии активных средств взаимодействия процессов (IPC) |
Отображение информации об активных средствах взаимодействия процессов (IPC). Определение объектов IPC, вносящих вклад в потребление ресурсов проектом. | |
Определение достаточности процессорной мощности, выделенной для веб-сервера |
Настройка глобального действия для элемента управления ресурсами. Это действие позволяет получать извещение о любой сущности, для которой установлено слишком низкое значение элемента управления ресурсами. |
Определение достаточности процессорной мощности, выделенной для веб-сервера |
Эта процедура позволяет добавить проект с названием x-files в файл /etc/project и установить максимальное количество LWP для задач, создаваемых в проекте.
Перейдите в режим суперпользователя или воспользуйтесь эквивалентной ролью.
Роли содержат подтвержденные полномочия и привилегированные команды. Для получения дополнительной информации о ролях см. Using the Solaris Management Tools With RBAC (Task Map) в System Administration Guide: Basic Administration.
Создайте проект с названием x-files, используя команду projadd с параметром -K. Для всех задач, создаваемых в проекте, устанавливается максимальное количество LWP, равное 3 .
# projadd -K 'task.max-lwps=(privileged,3,deny)' x-files |
Просмотрите запись в файле /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) |
После выполнения этих действий при создании суперпользователем новой задачи в проекте 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 может содержать параметры для ряда элементов управления ресурсами по каждому проекту, а также несколько пороговых значений для каждого элемента управления. Пороговые значения определяются в выражениях действия, разделяемых запятыми в случае указания нескольких значений.
Перейдите в режим суперпользователя или воспользуйтесь эквивалентной ролью.
Роли содержат подтвержденные полномочия и привилегированные команды. Для получения дополнительной информации о ролях см. Using the Solaris Management Tools With RBAC (Task Map) в System Administration Guide: Basic Administration.
Настройте элементы управления ресурсами для проекта 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, превышающего максимальное значение.
Просмотрите запись в файле одним из следующих способов:
Введите следующее:
# 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(1).
Эту процедуру необходимо выполнять в системе, в которой не создавались и не изменялись элементы управления ресурсами. В файле /etc/system или в базе данных project должны находиться только значения, отличные от значений по умолчанию.
Команду 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 -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 используется для временного добавления нового привилегированного значения, запрещающего использование более трех LWP на проект x-files. Результат можно сравнить с результатом Настройка максимального количества LWP для каждой задачи в проекте.
Перейдите в режим суперпользователя или воспользуйтесь эквивалентной ролью.
Роли содержат подтвержденные полномочия и привилегированные команды. Для получения дополнительной информации о ролях см. Using the Solaris Management Tools With RBAC (Task Map) в System Administration Guide: Basic Administration.
Выполните команду newtask для присоединения к проекту x-files.
# newtask -p x-files |
Для проверки правильности присоединения к проекту можно воспользоваться командой id с параметром - p.
# id -p uid=0(root) gid=1(other) projid=101(x-files) |
Добавьте новое привилегированное значение для project.max-lwps , ограничивающее количество LWP значением 3.
# prctl -n project.max-lwps -t privileged -v 3 -e deny -i project x-files |
Проверьте результат.
# 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 - |
Перейдите в режим суперпользователя или воспользуйтесь эквивалентной ролью.
Роли содержат подтвержденные полномочия и привилегированные команды. Для получения дополнительной информации о ролях см. Using the Solaris Management Tools With RBAC (Task Map) в System Administration Guide: Basic Administration.
Команда prctl с параметром -r используется для изменения самого низкого значения элемента управления ресурсами process.max-file-descriptor .
# prctl -n process.max-file-descriptor -r -v 128 $$ |
Перейдите в режим суперпользователя или воспользуйтесь эквивалентной ролью.
Роли содержат подтвержденные полномочия и привилегированные команды. Для получения дополнительной информации о ролях см. Using the Solaris Management Tools With RBAC (Task Map) в System Administration Guide: Basic Administration.
Выведите значение 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 |
Замените текущее значение project.cpu-shares , равное 1, значением 10.
# prctl -n project.cpu-shares -v 10 -r -i project group.staff |
Выведите значение 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(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 используется для вывода информации по активным средствам взаимодействия процессов (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).
С помощью команды prctl установите привилегированный (принадлежащий суперпользователю) элемент управления ресурсами для задач, содержащих процесс httpd. Задайте для каждой задачи ограничение по количеству LWP, равное 40, и отключите все локальные действия.
# prctl -n task.max-lwps -v 40 -t privileged -d all `pgrep httpd` |
Активируйте глобальное действие системного журнала для элемента управления ресурсами task.max-lwps.
# rctladm -e syslog task.max-lwps |
Проверьте, срабатывает ли элемент управления ресурсами под рабочей нагрузкой.
Если срабатывает, появится сообщение /var/adm/messages, подобное следующему:
Jan 8 10:15:15 testmachine unix: [ID 859581 kern.notice] NOTICE: privileged rctl task.max-lwps exceeded by task 19 |
Анализ данных рабочей нагрузки может показать, что одна из нагрузок или групп монополизирует процессорные ресурсы. Если эти рабочие нагрузки не нарушают ограничения по использованию процессорных ресурсов, можно изменить политику распределения процессорного времени в системе. Класс планирования долевого распределения, описанный в этой главе, позволяет распределять процессорное время на основании долей в отличие от схемы приоритета класса планирования с распределением времени (TS).
В этой главе рассматриваются следующие темы:
Вводную информацию по планировщику долевого распределения приведены в Глава 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 назначено SA долей, а проекту B назначено S B долей.
В среднем, при традиционном планировании TS, каждой из рабочих нагрузок, выполняющихся в системе, выделяется одинаковое количество ресурсов ЦП. Каждая рабочая нагрузка получила бы 50 процентов от мощности системы.
Под управлением планировщика FSS с S A=SB этим проектам также выдается приблизительно равное количество ресурсов ЦП. Однако если проектам выделяется разное количество долей, их процессорные ресурсы распределяются по-иному.
Следующими тремя примерами можно проиллюстрировать применение долей в разных конфигурациях. Эти примеры показывают, что доли математически точно представляют степень использования, только если интенсивность использования равна объему доступных ресурсов или превышает его.
Если проекты A и B имеют по два зависящих от процессора процесса, и при этом S A = 1, а S B = 3, то общее число долей составляет 1 + 3 = 4. В такой конфигурации при достаточной потребности в процессорных ресурсах проектам A и B выделяется 25% и 75% ресурсов ЦП соответственно.
Если проекты A и B имеют только по одному зависящему от процессора процессу, и при этом S A = 1, а S B = 100, то общее число долей составляет 101. Ни один из проектов не может использовать более одного процессора, поскольку в каждом проекте только один выполняющийся процесс. Поскольку в этой конфигурации проекты не конкурируют за процессорные ресурсы, проектам A и B выделяется по 50 процентов всех ресурсов ЦП. В этой конфигурации значения долей ЦП не имеют значения. Распределение ресурсов для проектов такое же (50/50), даже в том случае, если обоим проектам назначены нулевые доли.
Если проекты A и B имеют по два зависящих от процессора процесса, и при этом проекту A предоставлена 1 доля, а проекту B — 0 долей, проекту B вообще не выделяется процессорных ресурсов, а проект A получает все процессорные ресурсы. Процессы в B всегда выполняются с системным приоритетом 0. Это означает, что они никогда не будут выполняться, поскольку процессы проекта A всегда имеют более высокий приоритет.
Проекты – это контейнеры рабочих нагрузок в планировщике 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).
Замена текущего значения для указанного элемента управления ресурсами.
Имя элемента управления ресурсами.
Значение элемента управления ресурсами.
Тип идентификатора следующего аргумента.
Объект для изменения. В этом экземпляре объектом является проект x-files.
Проект system с идентификатором проекта 0 включает в себя все системные демоны, запущенные сценариями инициализации при начальной загрузке. Проект system можно рассматривать как проект с бесконечным количеством долей. Это означает, что проект system всегда планируется первым, независимо от количества долей, выделенных другим проектам. Если процесс system не должен получать неограниченное число долей, количество долей для него можно указать в базе данных project.
Как указано выше, процессы, принадлежащие проектам с нулевыми долями, всегда получают нулевой системный приоритет. Проекты с одной или несколькими долями работают с приоритетами, равными одному или выше. Таким образом, проекты с нулевыми долями планируются только при наличии достаточных процессорных ресурсов, не потребляемых проектами с ненулевыми долями.
Максимальное количество долей, которое можно назначить проекту, составляет 65535.
FSS можно использовать в сочетании с наборами процессоров, что позволит осуществлять более детализированное управление распределением процессорных ресурсов между процессами, выполняющимися на каждом наборе процессоров, по сравнению с использованием только наборов процессоров. С точки зрения планировщика FSS наборы процессоров рассматриваются как самостоятельные разделы, управляемые независимо от распределения ЦП.
На распределение ЦП проектов, выполняющихся в одном наборе процессоров, не влияют ни доли ЦП, ни деятельность проектов, выполняющихся на других наборах процессоров, так как проекты не конкурируют за одни и те же ресурсы. Проекты конкурируют друг с другом, только если они выполняются на одном наборе процессоров.
Доли выделяются проектам в общесистемном масштабе. Независимо от набора процессоров, на котором выполняется проект, каждой его части выделяется одинаковое количество долей.
При использовании наборов процессоров выделение ЦП проектам вычисляется для активных проектов, выполняющихся в каждом наборе процессоров.
Разделам проектов, выполняющимся на разных наборах процессоров, могут быть выделены разные доли процессорных ресурсов. Распределение ЦП по каждому разделу проекта в наборе процессоров зависит только от распределения для других проектов, выполняющихся на том же самом наборе процессоров.
Производительность и доступность приложений, выполняющихся в рамках своих наборов процессоров, не зависит от ввода новых наборов процессоров. На приложения также не влияют изменения, внесенные в распределение долей для проектов, выполняющихся на других наборах процессоров.
Пустые наборы процессоров (наборы без процессоров) или наборы процессоров без процессов, связанных с ними, не влияют на поведение планировщика FSS.
Предположим, что на сервере с восьмью процессорами в проектах A, B и C выполняется несколько приложений, зависящих от ЦП. Проекту A выделяется одна доля, проекту B — две, а проекту C — три.
Проект A выполняется только на наборе процессоров 1. Проект B выполняется только на наборах процессоров 1 и 2. Проект C выполняется на наборах процессоров 1, 2 и 3. Предположим, каждый проект содержит достаточное число процессов, чтобы использовать все доступные ресурсы ЦП. Таким образом, за процессорные ресурсы в каждом наборе процессоров всегда существует конкуренция.
Общесистемное распределение процессорных ресурсов в такой системе показано в следующей таблице.
Проект |
Распределение |
---|---|
Проект A |
4% = (1/6 X 2/8)pset1 |
Проект B |
28% = (2/6 X 2/8)pset1+ (2/5 * 4/8)pset2 |
Проект C |
67% = (3/6 X 2/8)pset1+ (3/5 X 4/8)pset2+ (3/3 X 2/8)pset3 |
Эти процентные значения не совпадают с соответствующими долями ЦП, выделенными проектам. Однако внутри каждого набора процессоров отношения выделенных процессорных ресурсов на каждый проект пропорциональны соответствующим долям.
В той же самой системе без наборов процессоров распределение ресурсов ЦП было бы другим, как показано в следующей таблице.
Проект |
Распределение |
---|---|
Проект A |
16,66% = (1/6) |
Проект B |
33,33% = (2/6) |
Проект C |
50% = (3/6) |
По умолчанию класс планирования 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. |
|
Вывод описания планировщика долевого распределения (FSS). |
В этой главе описывается использование планировщика долевого распределения (FSS).
Краткое описание FSS приведены в Глава 8Планировщик долевого распределения (обзор). Для получения дополнительной информации о классах планирования при использовании зон см. Класс планирования в зоне.
Задача |
Описание |
Информация |
---|---|---|
Наблюдение за использованием ЦП |
Наблюдение за использованием ЦП проектами, а также проектов в наборах процессоров. | |
Настройка класса планировщика по умолчанию |
Определение планировщика, например, FSS, в качестве системного планировщика по умолчанию. | |
Перемещение выполняемых процессов из одного класса планирования в другой, например, в класс FSS |
Перенос процессов вручную из одного класса планирования в другой без изменения класса планирования по умолчанию и без перезагрузки. | |
Перемещение всех выполняемых процессов во всех классах планирования в другой класс планирования, например, в класс FSS |
Перенос процессов вручную из всех классов планирования в другой класс планирования без изменения класса планирования по умолчанию и без перезагрузки. |
Перенос процессов из всех классов пользователей в класс FSS вручную |
Перемещение процессов проекта в другой класс планирования, например, в класс FSS |
Перенос процессов проекта вручную из текущего класса планирования в другой класс планирования. | |
Исследование и отладка параметров FSS |
Отладка значения шага квантования времени планировщика. Шаг квантования времени – это время, в течение которого может выполняться поток до принудительного освобождения процессора. |
Для контроля использования ЦП активными проектами применяется команда prstat, описанная на справочной странице prstat(1M).
Для получения статистики потребления процессорных ресурсов в долгосрочной перспективе используются данные расширенного учета. См. Глава 4Расширенный учет (обзор).
Для контроля использования ЦП проектами, выполняющимися в системе, используется команда prstat с параметром -J.
% prstat -J |
Для контроля использования ЦП проектами в списке наборов процессоров можно воспользоваться следующей командой:
% prstat -J -C pset-list |
где список_наборов – список идентификаторов наборов процессоров, разделенных запятыми.
Для настройки FSS используются те же команды, что и для других классов планирования в системе Solaris. Настраивается класс планировщика, регулируемые параметры планировщика, а также свойства отдельных процессов.
Следует отметить, что для перезапуска службы планировщика используется команда svcadm restart. Для получения дополнительной информации см. svcadm(1M).
Для вступления в силу распределения долей ЦП FSS должен быть системным планировщиком по умолчанию.
Комбинация команд priocntl и dispadmin позволяет задать FSS в качестве планировщика по умолчанию как немедленно, так и после перезагрузки.
Перейдите в режим суперпользователя или воспользуйтесь эквивалентной ролью.
Роли содержат подтвержденные полномочия и привилегированные команды. Для получения дополнительной информации о ролях см. Using the Solaris Management Tools With RBAC (Task Map) в System Administration Guide: Basic Administration.
Задайте FSS как системный планировщик по умолчанию.
# dispadmin -d FSS |
Это изменение вступает в силу при следующей перезагрузке. После перезагрузки каждый процесс в системе выполняется в классе планирования FSS.
Эту конфигурацию можно принудительно применить немедленно, без перезагрузки.
# priocntl -s -c FSS -i all |
Процессы можно переносить вручную из одного класса планирования в другой без изменения класса планирования по умолчанию и без перезагрузки. Эта процедура позволяет переместить процессы из класса планирования TS в класс планирования FSS вручную.
Перейдите в режим суперпользователя или воспользуйтесь эквивалентной ролью.
Роли содержат подтвержденные полномочия и привилегированные команды. Для получения дополнительной информации о ролях см. Using the Solaris Management Tools With RBAC (Task Map) в System Administration Guide: Basic Administration.
Переместите процесс init (PID 1) в класс планирования FSS.
# priocntl -s -c FSS -i pid 1 |
Переместите все процессы из класса планирования TS в класс планирования FSS.
# priocntl -s -c FSS -i class TS |
После перезагрузки все процессы снова будут выполняться в классе планирования TS.
Может использоваться класс по умолчанию, отличный от TS. Например, в системе может работать оконная среда, использующая по умолчанию класс IA. Все процессы можно переместить вручную в класс планирования FSS без изменения класса планирования по умолчанию и без перезагрузки.
Перейдите в режим суперпользователя или воспользуйтесь эквивалентной ролью.
Роли содержат подтвержденные полномочия и привилегированные команды. Для получения дополнительной информации о ролях см. Using the Solaris Management Tools With RBAC (Task Map) в System Administration Guide: Basic Administration.
Переместите процесс init (PID 1) в класс планирования FSS.
# priocntl -s -c FSS -i pid 1 |
Переместите все процессы из текущих классов планирования в класс планирования FSS.
# priocntl -s -c FSS -i all |
После перезагрузки все процессы снова будут выполняться в классе планирования по умолчанию.
Процессы проекта можно переместить вручную из текущего класса планирования в класс планирования FSS.
Перейдите в режим суперпользователя или воспользуйтесь эквивалентной ролью.
Роли содержат подтвержденные полномочия и привилегированные команды. Для получения дополнительной информации о ролях см. Using the Solaris Management Tools With RBAC (Task Map) в System Administration Guide: Basic Administration.
Переместите процессы, выполняющиеся в проекте с идентификатором 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 |
Демон ограниченного выделения ресурсов rcapd позволяет регулировать потребление физической памяти процессами, работающими в проектах с определенными ограничениями ресурсов.
Solaris 10 8/07: Если в системе имеются работающие зоны, для регулирования потребления физической памяти в неглобальных зонах используется демон rcapd в глобальной зоне. См. Глава 18Планирование и настройка неглобальных зон (задачи).
В этой главе рассматриваются следующие темы.
Вводная информация по демону ограниченного выделения ресурсов
Атрибут ограничения использования физической памяти проектами
См. процедуры использования функции 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:
Общее количество физической памяти в байтах, доступное процессам в проекте.
Например, следующей строкой в файле /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 |
Команду 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 и стандартные значения их интервалов описаны в следующей таблице.
Операция |
Значение интервала по умолчанию в секундах |
Описание |
---|---|---|
scan |
15 |
Число секунд между операциями сканирования для процессов, добавленных или устраненных из рабочей нагрузки проекта. Минимальное значение – 1 секунда. |
sample |
5 |
Число секунд между выборкой размера резидентного набора и последующим принудительным ограничением. Минимальное значение – 1 секунда. |
report |
5 |
Число секунд между обновлением статистики подкачки страниц. При значении 0 статистика не обновляется, и результат команды rcapstat выводится в устаревшем виде. |
config |
60 |
Число секунд между перенастройками. Во время перенастройки rcapadm осуществляет чтение файла конфигурации, определяет наличие обновлений и выполняет сканирование базы данных project на предмет новых или пересмотренных ограничений проекта. Передача сигнала SIGHUP в rcapd вызывает немедленную перенастройку. |
Инструкции по настройке интервалов приведены в Установка интервалов операций.
Интервал сканирования определяет частоту поиска новых процессов демоном rcapd. В системах с большим количеством работающих процессов сканирование списка занимает больше времени, так что может быть оправдано увеличение продолжительности интервала в целях сокращения общих затрат процессорного времени. Однако интервал сканирования также соответствует минимальному времени существования процесса для причисления к ограниченной рабочей задаче. Если существуют рабочие нагрузки, запускающие множество короткоживущих процессов, то при увеличенном интервале сканирования rcapd может не относить эти процессы к рабочей нагрузке.
Интервал выборки, настроенный командой rcapadm, представляет собой минимальный интервал времени ожидания rcapd между выборкой показателей потребления памяти рабочей нагрузкой и принудительным ограничением в случае превышения. В случае уменьшения этого интервала частота применения ограничений демоном rcapd обычно возрастает, что может привести к увеличению объема ввода-вывода вследствие подкачки страниц. Однако более короткий интервал выборки может также снизить воздействие внезапного скачка в потреблении физической памяти определенной рабочей нагрузкой на другие задачи. Интервал между операциями выборки, в течение которого память потребляется рабочей нагрузкой без ограничений, и, возможно, отбирается память у других ограниченных нагрузок, сужается.
Если интервал выборки, указанный для команды rcapstat, меньше интервала, указанного для команды rcapd c rcapadm, выходные данные для некоторых интервалов могут быть нулевыми. Это вызвано тем, что частота обновления статистики rcapd меньше интервала, указанного командой rcapadm. Интервал, указанный командой rcapadm , не зависит от интервала выборки, используемого командой rcapstat.
Команда rcapstat позволяет контролировать использование ресурсов проектами, для которых установлены ограничения по памяти. Пример отчета rcapstat cм. в Создание отчетов командой rcapstat.
Для отчета можно задать интервал выборки и указать количество повторений статистики.
Интервал выборки в секундах. По умолчанию используется интервал, равный 5 секундам.
Число повторений статистики. По умолчанию rcapstat выводит статистику до поступления сигнала прерывания или до выхода процесса rcapd.
Статистика подкачки страниц в первом отчете, выданном командой rcapstat, показывает события с момента запуска демона. Последующие отчеты отражают события с момента выдачи последнего отчета.
В следующей таблице описаны заголовки столбцов в отчете rcapstat.
Заголовки столбцов rcapstat |
Описание |
---|---|
id |
Идентификатор проекта, ограниченного по памяти. |
project |
Название проекта. |
nproc |
Количество процессов в проекте. |
vm |
Общий размер виртуальной памяти, используемой процессами проекта, включая все отображенные файлы и устройства, в килобайтах (K), мегабайтах (M) или гигабайтах (G). |
rss |
Оценочный общий размер резидентного набора (RSS) процессов проекта в килобайтах (K), мегабайтах (M) или гигабайтах (G) без учета совместно используемых страниц. |
cap |
Ограничение RSS, определенное для проекта. Для получения информации о настройке ограничений памяти см. Атрибут ограничения использования физической памяти проектами или справочную страницу rcapd(1M). |
at |
Общий объем памяти, в отношении которого демоном rcapd предпринимались попытки постраничного вывода с момента последней выборки rcapstat. |
avgat |
Средний объем памяти, в отношении которого демоном rcapd предпринимались попытки постраничного вывода в течение каждого цикла выборки с момента последней выборки rcapstat . Скорость, с которой демоном rcapdвыполняется выборка набора RSS, можно задать командой rcapadm. См. Интервалы операций rcapd. |
pg |
Общий объем памяти, для которой демоном rcapd был успешно выполнен постраничный вывод с момента последней выборки rcapstat. |
avgpg |
Оценка среднего объема памяти, для которой демоном rcapd был успешно выполнен постраничный вывод в течение каждого цикла выборки с момента последней выборки rcapstat . Скорость выборки размеров RSS процессов демоном rcapd выполняет выборку размеров RSS процессов, можно задать командой rcapadm. См. Интервалы операций rcapd. |
Справочная информация по командам |
Описание |
---|---|
Контроль использования ресурсов для проектов с ограничениями по памяти. |
|
Настройка демона ограниченного выделения ресурсов, отображение текущего состояния демона ограниченного выделения ресурсов, если он настроен, и включение либо отключение ограниченного выделения ресурсов. |
|
Демон ограниченного выделения ресурсов. |
В этой главе содержатся процедуры настройки и использования демона ограниченного выделения ресурсов rcapd.
Обзор демона rcapd приведены в Глава 10Управление физической памятью с помощью демона ограниченного выделения ресурсов (обзор).
Задача |
Описание |
Инструкции |
---|---|---|
Установка порога принудительного ограничения памяти |
Настройка ограничения, которое реализуется при недостатке физической памяти, доступной процессам. | |
Установка интервала операций |
Интервал применяется к периодическим операциям, выполняемым демоном ограниченного выделения ресурсов. | |
Включение ограниченного выделения ресурсов |
Включение ограниченного выделения ресурсов в системе. | |
Отключение ограниченного выделения ресурсов |
Отключение ограниченного выделения ресурсов в системе. | |
Вывод информации об ограничениях и проектах |
Просмотр примеров команд для создания отчетов. |
Создание отчетов об ограниченном использовании ресурсов и о проектах |
Контроль размера резидентного набора проекта |
Создание отчета о размере резидентного набора проекта. | |
Определение размера рабочего набора проекта |
Создание отчета о размере рабочего набора проекта. | |
Создание отчета об использовании памяти и ограничениях использования памяти |
Вывод строки использования памяти и принудительного ограничения в конце отчета для каждого интервала. |
Создание отчетов по использованию памяти и порогу принудительного ограничения памяти |
В этом разделе приведены процедуры настройки демона ограниченного выделения ресурсов командой rcapadm. Для получения дополнительной информации см. раздел Настройка rcapd и справочную страницу rcapadm(1M). Также рассматривается настройка временного ограничения выделения ресурсов с помощью команды rcapadm
Команда rcapadm без аргументов выводит текущее состояние демона ограниченного выделения ресурсов, если он настроен.
Ограничения можно настроить так, чтобы они не применялись в условиях доступности достаточного объема физической памяти для процессов. Для получения дополнительной информации см. Порог принудительного ограничения памяти.
Минимальное значение (оно же значение по умолчанию) равно 0, т. е. ограничения применяются всегда. Приведенная ниже процедура позволяет задать другое минимальное значение.
Перейдите в режим суперпользователя или воспользуйтесь ролью, включающей в себя профиль управления процессами (Process Management).
Профиль управления процессами входит в роль системного администратора (System Administrator). Для получения информации о создании роли и назначении роли пользователю см. раздел "Управление RBAC (карта задач)" в документе Руководство по системному администрированию: службы безопасности.
Для установки другого значения использования памяти, при котором должно применяться ограничение памяти, используется параметр -c команды rcapadm.
# rcapadm -c percent |
Значение процент лежит в диапазоне от 0 до 100. Более высокие значения соответствуют меньшему ограничению. Более высокое значение указывает на то, что задачи проекта, к которым относится ограничение, могут выполняться до момента достижения порогового значения потребления памяти по всей системе.
Инструкции по просмотру текущего потребления физической памяти и порога принудительного ограничения приведены в Создание отчетов по использованию памяти и порогу принудительного ограничения памяти.
В разделе Интервалы операций rcapd приводится информация об интервалах периодических операций, выполняемых демоном rcapd. Приведенная ниже процедура позволяет задать интервалы операций командой rcapadm.
Перейдите в режим суперпользователя или воспользуйтесь ролью, включающей в себя профиль управления процессами (Process Management).
Профиль управления процессами входит в роль системного администратора (System Administrator). Для получения информации о создании роли и назначении роли пользователю см. раздел "Управление RBAC (карта задач)" в документе Руководство по системному администрированию: службы безопасности.
Для установки значений интервалов используется параметр -i.
# rcapadm -i interval=value,...,interval=value |
Все значения интервалов указываются в секундах.
Существует три способа включения ограниченного выделения ресурсов в системе. При включении ограниченного выделения ресурсов в файле /etc/rcap.conf выставляются значения по умолчанию.
Перейдите в режим суперпользователя или воспользуйтесь ролью, включающей в себя профиль управления процессами (Process Management).
Профиль управления процессами входит в роль системного администратора (System Administrator). Для получения информации о создании роли и назначении роли пользователю см. раздел "Управление RBAC (карта задач)" в документе Руководство по системному администрированию: службы безопасности.
Демон ограниченного выделения ресурсов включается одним из следующих способов:
Включение ограниченного выделения ресурсов командой svcadm.
# svcadm enable rcap |
Для включения демона ограниченного выделения ресурсов с немедленным запуском и последующим включением при каждой загрузке системы необходимо ввести следующую команду:
# rcapadm -E |
Для включения демона ограниченного выделения ресурсов при каждой загрузке без немедленного запуска необходимо также указать параметр -n:
# rcapadm -n -E |
Существует три способа отключения ограниченного выделения ресурсов в системе.
Перейдите в режим суперпользователя или воспользуйтесь ролью, включающей в себя профиль управления процессами (Process Management).
Профиль управления процессами входит в роль системного администратора (System Administrator). Для получения информации о создании роли и назначении роли пользователю см. раздел "Управление RBAC (карта задач)" в документе Руководство по системному администрированию: службы безопасности.
Демон ограниченного выделения ресурсов отключается одним из следующих способов:
Отключение ограниченного выделения ресурсов командой svcadm.
# svcadm disable rcap |
Для отключения демона ограниченного выделения ресурсов с немедленной остановкой и отменой запуска при загрузке системы необходимо ввести следующую команду:
# rcapadm -D |
Для отключения демона ограниченного выделения ресурсов без немедленной остановки следует также указать параметр -n:
# rcapadm -n -D |
Безопасное отключение демона ограниченного выделения ресурсов
Для безопасного отключения демона rcapd используется команда svcadm или rcapadm с параметром -D. В случае остановки демона командой kill (см. справочную страницу kill(1)) процессы могут остаться в остановленном состоянии до их перезапуска вручную. Для возобновления работы процесса используется команда prun. Для получения дополнительной информации см. справочную страницу prun(1).
Эта процедура предназначена для выделения максимального объема памяти, доступного для потребления указанной зоной. Значение остается действительным до ближайшей перезагрузки. Для настройки постоянно действующего ограничения используется команда zonecfg
Перейдите в режим суперпользователя или воспользуйтесь ролью, включающей в себя профиль управления процессами (Process Management).
Профиль управления процессами входит в роль системного администратора (System Administrator).
Настройте для зоны my-zone ограничение памяти в размере 512 МБ.
# rcapadm -z testzone -m 512M |
Для создания отчетов по статистике ограниченного выделения ресурсов используется команда 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 этого не произошло.
В последующих отчетах особой активности не наблюдается.
В следующем примере показан проект 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% |
В этой главе рассматриваются следующие функциональные возможности:
пулы ресурсов, используемые для распределения ресурсов компьютера;
динамические пулы ресурсов (DRP), используемые для динамического регулирования распределения ресурсов каждого пула в соответствии с общесистемными целями.
Начиная с Solaris 10 11/06, пулы ресурсов и динамические пулы ресурсов являются службами в механизме управления службами Solaris (SMF). Каждая из этих служб включается отдельно.
В этой главе рассматриваются следующие темы:
Включение и выключение пулов ресурсов и динамических пулов ресурсов
Наблюдение за механизмом пулов и степени использования ресурсов командой poolstat
См. процедуры использования этих функциональных возможностей в Глава 13Создание и администрирование пулов ресурсов (задачи).
Solaris 10: Пулы ресурсов теперь обеспечивают механизм регулирования распределения ресурсов каждого пула в ответ на системные события и на изменение нагрузки приложений. Динамические пулы ресурсов позволяют упростить и сократить количество решений, которые должны приниматься администратором. Регулирование проводится автоматически, причем сохраняются целевые показатели производительности системы, установленные администратором.
Теперь командой projmod можно задать значение атрибута project.pool в файле /etc/project.
Полный список новых функций Solaris 10 и описание версий Solaris приведены в Solaris 10 What’s New.
Solaris 10 11/06: Пулы ресурсов и динамические пулы ресурсов теперь являются службами SMF.
Пулы ресурсов позволяют разделить рабочие нагрузки и исключить взаимоисключающее потребление определенных ресурсов рабочими нагрузками. Подобное резервирование ресурсов позволяет достигнуть предсказуемой производительности в системах со смешанными рабочими нагрузками.
Пулы ресурсов обеспечивают сохраняемый механизм для настройки наборов процессоров (pset) и, дополнительно, для назначения класса планирования.
Пул можно представить себе как отдельный комплект разнообразных наборов ресурсов, доступных в системе. Создаваемые пулы могут соответствовать различным видам возможных комбинаций ресурсов:
pool1: pset_default |
pool2: pset1 |
pool3: pset1, pool.scheduler="FSS" |
Группирование разделов в пулы позволяет получить метку-манипулятор для связывания с отмеченными рабочими нагрузками. С каждой записью проекта в файле /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, описаны на следующих справочных страницах:
Все конфигурации пулов ресурсов, включая динамическую конфигурацию, могут содержать следующие элементы.
Свойства, воздействующие на общее поведение системы.
Определение пула ресурсов.
Определение набора процессоров.
Определение процессора.
Все эти элементы обладают свойствами, которыми можно управлять в целях изменения состояния и поведения архитектуры пулов ресурсов. Например, свойство пула 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 добавляется к записи проекта в файле /etc/project для связывания с этой записью отдельного пула. Новые рабочие нагрузки, запускаемые в проекте, привязываются к соответствующему пулу. Для получения дополнительной информации см. Глава 2Проекты и задачи (обзор).
Например, команду projmod можно использовать для установки атрибута project.pool для проекта sales в файле /etc/project:
# projmod -a -K project.pool=mypool sales |
Динамическая перенастройка (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 сохраняет и может анализировать историю принятых решений. История принятых решений используется во избежание перенастроек, не приводивших в прошлом к исправлению ситуации.
Следует отметить, что в случае изменения целевых показателей рабочих нагрузок или доступных в системе ресурсов перенастройка также может инициироваться асинхронно.
Управление службой 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) и Свойства пулов.
Эти два свойства ограничивают минимальное и максимальное количество процессоров, которые можно выделить в набор процессоров. Дополнительную информацию об этих свойствах приведены в Таблица 12–1.
Ресурсы из раздела ресурсов доступны для выделения другим разделам ресурсов в том же экземпляре Solaris в рамках этих ограничений. Доступ к ресурсу обеспечивается путем привязки к пулу, связанному с набором ресурсов. Привязка выполняется при регистрации или вручную администратором с полномочиями PRIV_SYS_RES_CONFIG.
Свойство cpu-pinned указывает, что определенный процессор не должен покидать набор процессоров, в котором он расположен, в результате действий DPR. Это свойство libpool можно использовать для максимизации использования кэша определенным приложением, выполняющимся внутри набора процессоров.
Дополнительную информацию об этом свойстве приведены в Таблица 12–1.
Свойство pool.importance описывает относительную важность пула в соответствии с определением, заданным администратором.
Целевые показатели задаются аналогично ограничениям. Полный перечень целевых показателей представлен в Таблица 12–1.
Существуют две категории целевых показателей.
Целевой показатель, зависящий от рабочей нагрузки, изменяется в зависимости от характера рабочей нагрузки, выполняющейся в системе. Примером может служить целевой показатель utilization. Показатель степени использования для набора ресурсов изменяется в соответствии с характером активной в наборе рабочей нагрузки.
Целевой показатель, не зависящий от рабочей нагрузки, не изменяется в зависимости от характера рабочей нагрузки, выполняющейся в системе. Примером может служить целевой показатель ЦП locality. Оценочное значение локальности (locality) для набора ресурсов не изменяется в зависимости от характера активной в наборе рабочей нагрузки.
Можно определить три типа целевых показателей.
Имя |
Допустимые элементы |
Знаки операций |
Значения |
---|---|---|---|
wt-load |
system |
нет |
нет |
locality |
pset |
нет |
loose | tight | none |
utilization |
pset |
< > ~ |
0–100% |
Целевые показатели хранятся в строках свойств в конфигурации 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 расшифровывается как взвешенная нагрузка.
Этот целевой показатель следует использовать, если ограничения, установленные с помощью минимальных и максимальных значений свойств, удовлетворяют требованиям, и для демона необходимо обеспечить свободное манипулирование ресурсами в рамках этих ограничений.
Целевой показатель locality влияет на воздействие, оказываемое локальностью, которая определяется по данным группы местоположений (lgroup), на выбранную конфигурацию. Локальность также можно определить как задержку. Группа lgroup описывает ресурсы памяти и ЦП. Группа lgroup используется в Solaris для определения расстояния между ресурсами в единицах времени. Для получения дополнительной информации о выделении группы местоположения см. раздел Locality Groups Overview в Programming Interfaces Guide.
Этому целевому показателю может соответствовать одно из трех значений:
В данном случае предпочтение оказывается конфигурациям, обеспечивающим максимальную локальность ресурсов.
В этом варианте предпочтение оказывается конфигурациям, обеспечивающим минимальную локальность ресурсов.
При выборе данного значения локальность не влияет на предпочтительность конфигурации. Это значение задается для показателя locality по умолчанию.
Как правило, для целевого показателя locality следует устанавливать значение tight. Однако в целях максимизации полосы пропускания памяти или минимизации воздействия операций DR на набор ресурсов для этого показателя можно установить значение loose или оставить значение по умолчанию none.
Целевой показатель utilization отдает предпочтение конфигурациям, в которых ресурсы распределяются по разделам, не соответствующим указанным целевым показателям по степени использования.
Этот показатель задается с помощью знаков операций и значений. Для этого используются следующие знаки операций:
Знак операции "меньше чем" указывает, что данное значение соответствует максимальному целевому значению.
Знак операции "больше чем" указывает, что данное значение соответствует минимальному целевому значению.
Знак операции "about" означает, что данное значение представляет собой целевое значение, для которого возможны некоторые колебания.
Для набора процессоров (pset) можно задать только один показатель "utilization" со знаком операции каждого типа.
Если задан знак операции ~, ввести знаки операций < и > невозможно.
Если заданы знаки операций < и >, невозможным становится указание знака операции ~. Следует отметить, что настройки знаков операций < и > не могут противоречить друг другу.
Совместное использование знаков операций < и > позволяет задать диапазон. Значения проверяются на допустимость во избежание их перекрывания.
В следующем примере демону poold необходимо оценить следующие целевые показатели набора процессоров:
Показатель utilization должен иметь значение между 30 и 80 процентами.
Показатель locality для набора процессоров должен быть максимальным.
Для этих показателей устанавливается важность по умолчанию, равная 1.
pset.poold.objectives "utilization > 30; utilization < 80; locality tight"
Дополнительные примеры использования приведены в Определение целевых показателей конфигурации.
Существуют четыре категории свойств:
Конфигурация
Ограничение
Целевой показатель
Параметр целевого показателя
Имя свойства |
Тип |
Категория |
Описание |
---|---|---|---|
system.poold.log-level |
string |
Конфигурация |
уровень журналирования; |
system.poold.log-location |
string |
Конфигурация |
место журналирования. |
system.poold.monitor-interval |
uint64 |
Конфигурация |
Интервал выборки для наблюдения. |
system.poold.history-file |
string |
Конфигурация |
Местоположение истории принятых решений. |
pset.max |
uint64 |
Ограничение |
Максимальное количество процессоров в данном наборе процессоров. |
pset.min |
uint64 |
Ограничение |
Минимальное количество процессоров в этом наборе процессоров. |
cpu.pinned |
bool |
Ограничение |
Процессоры, прикрепленные к данному набору процессоров. |
system.poold.objectives |
string |
Целевой показатель |
Форматированная строка, следующая после синтаксиса выражения целевого показателя poold |
pset.poold.objectives |
string |
Целевой показатель |
Форматированная строка, следующая после синтаксиса выражения poold |
pool.importance |
int64 |
Параметр целевого показателя |
Важность, заданная пользователем. |
Настройке подлежат следующие аспекты поведения демона:
интервал наблюдения;
уровень журналирования;
место журналирования.
Эти параметры задаются в конфигурации пулов. Уровнем журналирования также можно управлять из командной строки вызовом демона poold.
Значение свойства system.poold.monitor-interval указывается в миллисекундах.
Журналирование позволяет регистрировать информацию трех категорий. Это следующие категории:
Конфигурация
Наблюдение
Оптимизация
Имя свойства system.poold.log-level используется для указания параметра журналирования. Если это свойство не указано, используется уровень журналирования по умолчанию – NOTICE. Уровни параметра формируют иерархию. При уровне журналирования DEBUG демон poold регистрирует все сообщения. Уровень INFO соответствует среднему уровню информации, удобному для большинства администраторов.
Для указания уровня информации, записываемой в журнал, можно воспользоваться командой poold с параметром -l в командной строке.
Доступны следующие параметры:
ALERT
CRIT
ERR
WARNING
NOTICE
INFO
DEBUG
Уровни параметра непосредственно соответствуют их эквивалентам syslog. Для получения дополнительной информации об использовании syslog см. Место журналирования.
Для получения дополнительной информации о настройке журналирования poold см. Настройки уровня журналирования poold.
Возможна генерация сообщений следующих типов:
Проблемы при доступе к конфигурации libpool или иной непредвиденный отказ механизма libpool. Подобные проблемы вызывают завершение работы демона и требуют немедленного внимания администратора.
Проблемы вследствие непредвиденных отказов. Подобные проблемы вызывают завершение работы демона и требуют немедленного внимания администратора.
Проблемы с указанными пользователем параметрами, управляющими работой демона, например, неразрешимые конфликты целей степени использования для набора ресурсов. Для решения подобных проблем требуется административное вмешательство. Демон poold пытается принять меры к исправлению ситуации путем игнорирования конфликтующих целевых показателей, однако некоторые ошибки способны привести к завершению работы демона.
Предупреждения, связанные с установкой параметров конфигурации, которые, будучи технически корректными, могут не подходить для данной среды выполнения. В качестве примера можно привести маркировку всех процессорных ресурсов как прикрепленных, что приводит к невозможности перемещения ресурсов ЦП между наборами процессоров демоном poold.
Сообщения, содержащие подробную информацию, требуемую при отладке конфигурации. Эта информация, как правило, не используется администраторами.
Возможна генерация сообщений следующих типов:
Проблемы из-за непредвиденных отказов наблюдения. Подобные проблемы вызывают завершение работы демона и требуют немедленного внимания администратора.
Проблемы из-за непредвиденных ошибок наблюдения. Для исправления подобных ошибок может потребоваться административное вмешательство.
Сообщения о достижении границ, задаваемых элементами управления ресурсами.
Сообщения о статистике использования ресурсов.
Сообщения, содержащие подробную информацию, требуемую при отладке наблюдения. Эта информация, как правило, не используется администраторами.
Возможна генерация сообщений следующих типов:
Сообщения о проблемах при принятии оптимальных решений. В качестве примеров можно привести наборы ресурсов, слишком узко ограниченные минимальными и максимальными значениями или числом прикрепленных компонентов.
Также могут выводиться сообщения о проблемах, возникающих при выполнении оптимального перераспределения из-за непредвиденных ограничений. В качестве примеров можно привести удаление последнего процессора из набора процессоров, содержащего связанного потребителя ресурса.
Сообщения о пригодных конфигурациях или о конфигурациях, которые не используются вследствие выявленных при помощи истории принятых решений противоречий.
Возможен вывод сообщений о рассматриваемых альтернативных конфигурациях.
Сообщения, содержащие подробную информацию, требуемую для отладки оптимизации. Эта информация, как правило, не используется администраторами.
Для указания местоположения для вывода в журнал демоном poold используется свойство system.poold.log-location. Для команд poold можно указать местоположение SYSLOG (см. syslog(3C)).
Если это свойство не указано, в качестве местоположения по умолчанию для журнального вывода poold используется /var/log/pool/poold.
При вызове poold из командной строки это свойство не используется. Журнальные записи выводятся в stderr вызывающего терминала.
Если активен демон 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(1M). Для получения информации о задачах и использовании poolstat см. Вывод статистических отчетов по ресурсам, связанным с пулами, с помощью команды poolstat.
Если используется формат вывода по умолчанию, poolstat выводит строку заголовка, а затем по одной строке для каждого пула. Строка пула начинается с идентификатора и имени пула, после которых следует столбец статистических данных для набора процессоров, присоединенного к пулу. Наборы ресурсов, присоединенные к нескольким пулам, выводятся несколько раз, по одному разу на каждый пул.
Используются следующие заголовки столбцов:
Идентификатор пула.
Имя пула.
Идентификатор набора ресурсов.
Имя набора ресурсов.
Тип набора ресурсов.
Минимальный размер набора ресурсов.
Максимальный размер набора ресурсов.
Текущий размер набора ресурсов.
Мера текущего использования набора ресурсов.
Эта характеристика использования вычисляется как процент от степени использования набора ресурсов, умноженный на размер набора ресурсов. Если набор ресурсов перенастраивался в течение последнего интервала выборки, это значение может отсутствовать. В этом случае вместо значения отображается дефис (-).
Абсолютное представление нагрузки набора ресурсов.
Для получения дополнительной информации об этом свойстве см. справочную страницу libpool(3LIB).
Выходные данные poolstat можно настроить путем определения следующих элементов:
Порядок столбцов
Выводимые заголовки
Операции, выполняемые poolstat, могут быть настроены. Для отчета можно задать интервал выборки и указать количество повторений статистики.
Настройка интервалов для периодических операций, выполняемых poolstat. Все интервалы указываются в секундах.
Число повторений статистики. По умолчанию статистика poolstat выводится один раз.
Если значения интервал и число не указаны, данные статистики выводятся один раз. Если значение interval указано, а count не указано, то статистика выводится бесконечно.
Команды, указанные в следующей таблице, обеспечивают главный административный интерфейс для механизма пулов. Для получения информации по использованию этих команд в системе с установленными зонами см. Использование пулов ресурсов в зонах.
Ссылка на справочную страницу |
Описание |
---|---|
Включение или отключение механизма пулов. Активация определенной конфигурации или удаление текущей конфигурации с возвращением связанных ресурсов в их состояние по умолчанию. При запуске без параметров pooladm отображает текущую динамическую конфигурацию пулов. |
|
Активация привязки проектов, задач и процессов к пулу ресурсов вручную. |
|
Эта команда обеспечивает операции по конфигурированию для пулов и наборов. Конфигурации, создаваемые с помощью этого средства, активируются на целевом узле командой pooladm . При выполнении с аргументом подкоманды info с параметром - c по команде poolcfg отображается информация о статической конфигурации в /etc/pooladm.conf. Если указывается также аргумент имени файла, по этой команде отображается информация о статической конфигурации, содержащейся в именованном файле. Например, по команде poolcfg - c info /tmp/newconfig отображается информация о статической конфигурации в файле /tmp/newconfig . |
|
Системный демон пулов. Демон использует системные целевые показатели и наблюдаемую статистику для обеспечения соответствия целям по производительности, заданным администратором. Если корректирующие действия при отступлении от этих показателей оказываются неуспешными, poold заносит такое состояние в журнал. |
|
Вывод статистических данных по ресурсам, связанным с пулом. Эта команда служит для упрощения анализа производительности и вывода информации, используемой системными администраторами при распределении и перераспределении ресурсов. Можно задать параметры для исследования конкретных пулов и вывода статистики по конкретным наборам ресурсов. |
Библиотекой libpool предоставляется API (см. справочную страницуlibpool(3LIB)). Эта библиотека может использоваться программами для управления конфигурациями пулов.
В этой главе описываются процедуры создания и администрирования пулов ресурсов.
Для получения вводной информации о пулах ресурсов см. Глава 12Пулы ресурсов (обзор).
Задача |
Описание |
Инструкции |
---|---|---|
Включение или выключение пулов ресурсов |
Включение или отключение пулов ресурсов в системе. | |
Включение или выключение динамических пулов ресурсов |
Включение или выключение механизма динамических пулов ресурсов в системе. | |
Создание статической конфигурации пулов ресурсов |
Создание файла статической конфигурации, совпадающей с текущей динамической конфигурацией. Для получения дополнительной информации см. Архитектура пулов ресурсов. | |
Изменение конфигурации пула ресурсов |
Пересмотр конфигурации пулов в системе, например, создание дополнительных пулов. | |
Связывание пула ресурсов с классом планирования |
Когда пул связан с классом планирования, все процессы, привязанные к пулу, используют указанный планировщик. | |
Установка ограничений конфигурации и определение целевых показателей конфигурации |
Указание целевых показателей для poold, которые необходимо учитывать при выполнении корректирующих действий. Для получения дополнительной информации о целевых показателях конфигурации см. Обзор poold. |
См. Настройка ограничений конфигурации и Определение целевых показателей конфигурации |
Установка уровня журналирования |
Указание уровня регистрации информации, генерируемой poold. | |
Использование текстового файла с командой poolcfg. |
Входные данные команды poolcfg могут поступать из текстового файла. | |
Перенос ресурсов в ядре. |
Перенос ресурсов в ядре. Например, перенос ресурсов с определенными идентификаторами в целевой набор. | |
Активация конфигурации пулов. |
Активация конфигурации из файла конфигурации по умолчанию. | |
Проверка допустимости конфигурации пулов перед сохранением ее параметров. |
Проверка допустимости конфигурации пулов с выяснением результатов проверки. |
Проверка допустимости конфигурации перед сохранением ее параметров |
Удаление конфигурации пулов из системы |
Все связанные ресурсы, например наборы процессоров, возвращаются в состояние по умолчанию. | |
Привязка процессов к пулу |
Связывание выполняющегося процесса с пулом ресурсов вручную. | |
Привязка задач или проектов к пулу |
Связывание задач или проектов с пулом ресурсов. | |
Привязка новых процессов к пулу ресурсов |
Для автоматического связывания новых процессов проекта с данным пулом к каждой записи в базе данных project необходимо добавить соответствующий атрибут. | |
Использование атрибутов project для привязки процесса к другому ресурсу. |
Изменение привязки к пулам при запуске новых процессов. |
Использование атрибутов project для привязки процесса к другому пулу |
Создание отчетов при помощи утилиты poolstat. |
Создание серии отчетов с указанными интервалами. | |
Вывод статистического отчета по набору ресурсов |
Для вывода статистического отчета по набору ресурсов pset используется средствоpoolstat. |
Начиная с Solaris 10 11/06, службы пулов ресурсов и динамических пулов ресурсов можно включать и выключать с помощью команды svcadm, описанной на справочной странице svcadm(1M).
Команда pooladm, описанная на справочной странице pooladm(1M), позволяет выполнять следующие действия:
включение механизма пулов для обеспечения возможности манипулирования пулами;
отключение механизма пулов для запрета манипулирования пулами.
Если при обновлении системы архитектура пулов ресурсов включена, и существует файл /etc/pooladm.conf, включается служба пулов, и к системе применяется конфигурация из данного файла.
Перейдите в режим суперпользователя или воспользуйтесь ролью, включающей в себя профиль управления процессами (Process Management).
Профиль управления процессами входит в роль системного администратора (System Administrator). Для получения дополнительной информации о ролях см. Using the Solaris Management Tools With RBAC (Task Map) в System Administration Guide: Basic Administration.
Включите службу пулов ресурсов.
# svcadm enable system/pools:default |
Перейдите в режим суперпользователя или воспользуйтесь ролью, включающей в себя профиль управления процессами (Process Management).
Профиль управления процессами входит в роль системного администратора (System Administrator). Для получения дополнительной информации о ролях см. Using the Solaris Management Tools With RBAC (Task Map) в System Administration Guide: Basic Administration.
Отключите службу пулов ресурсов.
# svcadm disable system/pools:default |
Перейдите в режим суперпользователя или воспользуйтесь ролью, включающей в себя профиль управления службами (Service Management).
Роли содержат полномочия и привилегированные команды. Информацию относительно создания роли и ее назначения пользователю приведены в Configuring RBAC (Task Map) в System Administration Guide: Security ServicesManaging RBAC (Task Map) руководства Руководство по системному администрированию: службы безопасности.
Включите службу динамических пулов ресурсов.
# svcadm enable system/pools/dynamic:default |
Как показывает этот пример, перед запуском динамических пулов ресурсов (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 |
Если обе службы работают, и отключается служба пулов ресурсов:
# 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 |
Перейдите в режим суперпользователя или воспользуйтесь ролью, включающей в себя профиль управления процессами (Process Management).
Профиль управления процессами входит в роль системного администратора (System Administrator). Для получения дополнительной информации о ролях см. Using the Solaris Management Tools With RBAC (Task Map) в System Administration Guide: Basic Administration.
Отключите службу динамических пулов ресурсов.
# svcadm disable system/pools/dynamic:default |
Перейдите в режим суперпользователя или воспользуйтесь ролью, включающей в себя профиль управления процессами (Process Management).
Профиль управления процессами входит в роль системного администратора (System Administrator). Для получения дополнительной информации о ролях см. Using the Solaris Management Tools With RBAC (Task Map) в System Administration Guide: Basic Administration.
Включите механизм управления пулами.
# pooladm -e |
Перейдите в режим суперпользователя или воспользуйтесь ролью, включающей в себя профиль управления процессами (Process Management).
Профиль управления процессами входит в роль системного администратора (System Administrator). Для получения дополнительной информации о ролях см. Using the Solaris Management Tools With RBAC (Task Map) в System Administration Guide: Basic Administration.
Отключите механизм управления пулами.
# pooladm -d |
С помощью команды -s с параметром /usr/sbin/pooladm создайте файл статической конфигурации, совпадающей с текущей динамической конфигурацией. Если не указано другое имя файла, используется местоположение по умолчанию /etc/pooladm.conf .
Зафиксируйте конфигурацию командой pooladm с параметром -c. После этого статическую конфигурацию следует привести в соответствие с динамической конфигурацией командой pooladm с параметром -s.
Новые функциональные возможности команды pooladm -s, являются предпочтительными по сравнению с ранее использовавшимися функциональными возможностями команды poolcfg -c discover для создания новой конфигурации, совпадающей с динамической конфигурацией.
Включите пулы в системе.
Перейдите в режим суперпользователя или воспользуйтесь ролью, включающей в себя профиль управления процессами (Process Management).
Профиль управления процессами входит в роль системного администратора (System Administrator). Для получения дополнительной информации о ролях см. Using the Solaris Management Tools With RBAC (Task Map) в System Administration Guide: Basic Administration.
Обновите файл статической конфигурации в соответствии с текущей динамической конфигурацией.
# pooladm -s |
Выведите содержимое файла конфигурации в удобной для чтения форме.
Следует отметить, что в конфигурацию входят элементы по умолчанию, созданные автоматически.
# 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 |
Зафиксируйте конфигурацию в /etc/pooladm.conf .
# pooladm -c |
(Дополнительно) Для копирования динамической конфигурации в файл статической /tmp/backup используется следующая команда:
# pooladm -s /tmp/backup |
Для расширения конфигурации создайте набор процессоров с названием pset_batch и пул с названием pool_batch. Затем свяжите пул и набор процессоров.
Следует отметить, что аргументы подкоманды, содержащие пробелы, указываются в кавычках.
Перейдите в режим суперпользователя или воспользуйтесь ролью, включающей в себя профиль управления процессами (Process Management).
Профиль управления процессами входит в роль системного администратора (System Administrator). Для получения дополнительной информации о ролях см. Using the Solaris Management Tools With RBAC (Task Map) в System Administration Guide: Basic Administration.
Создайте набор процессоров pset_batch.
# poolcfg -c 'create pset pset_batch (uint pset.min = 2; uint pset.max = 10)' |
Создайте пул pool_batch.
# poolcfg -c 'create pool pool_batch' |
Свяжите пул с набором процессоров.
# poolcfg -c 'associate pool pool_batch (pset pset_batch)' |
Проверьте измененную конфигурацию.
# 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 |
Зафиксируйте конфигурацию в /etc/pooladm.conf .
# pooladm -c |
(Дополнительно) Для копирования динамической конфигурации в файл статической конфигурации /tmp/backup используется следующая команда:
# pooladm -s /tmp/backup |
Если пул связывается с классом планирования, указанный планировщик используется для всех процессов, привязанных к пулу. Для этого в свойстве pool.scheduler указывается имя планировщика. В этом примере пул pool_batch связывается с планировщиком долевого распределения (FSS).
Перейдите в режим суперпользователя или воспользуйтесь ролью, включающей в себя профиль управления процессами (Process Management).
Профиль управления процессами входит в роль системного администратора (System Administrator). Информацию относительно создания роли и назначения роли пользователю приведены в разделе "Managing RBAC (Task Map)" руководства Руководство по системному администрированию: службы безопасности.
Измените пул pool_batch и свяжите его с FSS.
# poolcfg -c 'modify pool pool_batch (string pool.scheduler="FSS")' |
Проверьте измененную конфигурацию.
# 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 |
Зафиксируйте конфигурацию в /etc/pooladm.conf :
# pooladm -c |
(Дополнительно) Для копирования динамической конфигурации в файл статической /tmp/backup используется следующая команда:
# pooladm -s /tmp/backup |
Ограничения влияют на диапазон возможных конфигураций, устраняя ряд потенциальных изменений, которые можно было бы внести в конфигурацию. Эта процедура используется для настройки свойства cpu.pinned.
В следующих примерах cpuid является целым числом.
Перейдите в режим суперпользователя или воспользуйтесь ролью, включающей в себя профиль управления процессами (Process Management).
Профиль управления процессами входит в роль системного администратора (System Administrator). Для получения дополнительной информации о ролях см. Using the Solaris Management Tools With RBAC (Task Map) в System Administration Guide: Basic Administration.
Измените свойство cpu.pinned в статической или динамической конфигурации.
Для poold можно задать целевые показатели, которые будут учитываться при принятии корректирующих мер.
В следующей процедуре значение целевого показателя wt-load заставляет демон poold сопоставлять распределение ресурсов с их использованием. Целевой показатель locality отключен, что упростит достижение указанной цели.
Перейдите в режим суперпользователя или воспользуйтесь ролью, включающей в себя профиль управления процессами (Process Management).
Профиль управления процессами входит в роль системного администратора (System Administrator). Для получения дополнительной информации о ролях см. Using the Solaris Management Tools With RBAC (Task Map) в System Administration Guide: Basic Administration.
Измените системный параметр tester, чтобы присвоить более высокий приоритет целевому показателю wt-load.
# poolcfg -c 'modify system tester (string system.poold.objectives="wt-load")' |
Отключите целевой показатель locality для набора процессоров по умолчанию.
# poolcfg -c 'modify pset pset_default (string pset.poold.objectives="locality none")'one line |
Отключите целевой показатель locality для набора процессоров pset_batch.
# poolcfg -c 'modify pset pset_batch (string pset.poold.objectives="locality none")'one line |
Проверьте измененную конфигурацию.
# 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 |
Зафиксируйте конфигурацию в /etc/pooladm.conf .
# pooladm -c |
(Дополнительно) Для копирования динамической конфигурации в файл статической /tmp/backup используется следующая команда:
# pooladm -s /tmp/backup |
Уровень регистрационной информации, генерируемой демоном poold, задается в виде свойства system.poold.log-level в конфигурации poold. Конфигурация poold содержится в конфигурации libpool. Для получения дополнительной информации см. Информация журналирования poold и справочные страницы poolcfg(1M) и libpool(3LIB).
Также для указания уровня регистрационной информации, генерируемой демоном poold, может использоваться команда poold, вызываемая из командной строки.
Перейдите в режим суперпользователя или воспользуйтесь ролью, включающей в себя профиль управления процессами (Process Management).
Профиль управления процессами входит в роль системного администратора (System Administrator). Для получения дополнительной информации о ролях см. Using the Solaris Management Tools With RBAC (Task Map) в System Administration Guide: Basic Administration.
Уровень журналирования настраивается командой poold с параметром-l и дополнительным параметром (например, INFO).
# /usr/lib/pool/poold -l INFO |
Для получения информации о доступных параметрах см. Информация журналирования poold. Значение по умолчанию для уровня журналирования – NOTICE.
Команда poolcfg с параметром -f может получать входные данные из текстового файла, содержащего аргументы подкоманды poolcfg с параметром -c. Этот метод удобен при необходимости выполнения ряда операций. При обработке нескольких команд конфигурация обновляется только в случае успешности каждой из них. В случае крупных или сложных конфигураций этот прием может оказаться более удобным, чем вызов подкоманд по отдельности.
Следует отметить, что символ # в командных файлах означает, что остальная часть строки является комментарием.
Создайте входной файл 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) |
Перейдите в режим суперпользователя или воспользуйтесь ролью, включающей в себя профиль управления процессами (Process Management).
Профиль управления процессами входит в роль системного администратора (System Administrator). Информацию относительно создания роли и назначения роли пользователю приведены в разделе "Managing RBAC" руководства Руководство по системному администрированию: службы безопасности.
Выполните команду:
# /usr/sbin/poolcfg -f poolcmds.txt |
Для переноса ресурсов в ядре используется аргумент подкоманды transfer параметра -c команды poolcfg с параметром -d. Параметр -d означает, что команда работает непосредственно с ядром и не получает входные данные из файла.
Следующая процедура позволяет переместить два ЦП из набора процессоров pset1 в набор процессоров pset2 в ядре.
Перейдите в режим суперпользователя или воспользуйтесь ролью, включающей в себя профиль управления процессами (Process Management).
Профиль управления процессами входит в роль системного администратора (System Administrator). Для получения дополнительной информации о ролях см. Using the Solaris Management Tools With RBAC (Task Map) в System Administration Guide: Basic Administration.
Переместите два ЦП из pset1 в pset2.
Элементы выражения from и to могут указываться в любом порядке. Поддерживается только одна пара to и from на команду.
# poolcfg -dc 'transfer 2 from pset pset1 to pset2' |
Если требуется выполнить перенос конкретных идентификаторов типа ресурса, можно воспользоваться альтернативным синтаксисом. Например, следующая команда присваивает два процессора с идентификаторами 0 и 2 набору процессоров pset_large:
# poolcfg -dc "transfer to pset pset_large (cpu 0; cpu 2)" |
Если перенос не удается из-за недостаточных ресурсов или из-за невозможности обнаружения указанных идентификаторов, выдается сообщение об ошибке.
Для активации определенной конфигурации пулов или удаления конфигурации пулов, активной в текущий момент, используется команда pooladm. Для получения дополнительной информации об этой команде см. справочную страницу pooladm(1M).
Для активации конфигурации из файла конфигурации по умолчанию /etc/pooladm.conf используется команда pooladm с параметром -c – "применить конфигурацию".
Перейдите в режим суперпользователя или воспользуйтесь ролью, включающей в себя профиль управления процессами (Process Management).
Профиль управления процессами входит в роль системного администратора (System Administrator). Для получения дополнительной информации о ролях см. Using the Solaris Management Tools With RBAC (Task Map) в System Administration Guide: Basic Administration.
Зафиксируйте конфигурацию в /etc/pooladm.conf .
# pooladm -c |
(Дополнительно) Скопируйте динамическую конфигурацию в файл статической конфигурации, например /tmp/backup.
# pooladm -s /tmp/backup |
Для выяснения результатов проверки допустимости можно использовать параметр -n с параметром -c. Фактического сохранения параметров конфигурации не происходит.
Следующая команда используется для проверки допустимости конфигурации, содержащейся в файле /home/admin/newconfig. Выводятся сообщения обо всех возникающих состояниях ошибки, однако сама конфигурация не изменяется.
Перейдите в режим суперпользователя или воспользуйтесь ролью, включающей в себя профиль управления процессами (Process Management).
Профиль управления процессами входит в роль системного администратора (System Administrator). Для получения дополнительной информации о ролях см. Using the Solaris Management Tools With RBAC (Task Map) в System Administration Guide: Basic Administration.
Перед сохранением параметров конфигурации ее следует проверить на допустимость.
# pooladm -n -c /home/admin/newconfig |
Для удаления текущей активной конфигурации и возврата всех связанных ресурсов, например наборов процессоров, к их состоянию по умолчанию используется параметр -x – "удалить конфигурацию".
Перейдите в режим суперпользователя или воспользуйтесь ролью, включающей в себя профиль управления процессами (Process Management).
Профиль управления процессами входит в роль системного администратора (System Administrator). Для получения дополнительной информации о ролях см. Using the Solaris Management Tools With RBAC (Task Map) в System Administration Guide: Basic Administration.
Удалите текущую активную конфигурацию.
# 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.
Перейдите в режим суперпользователя или воспользуйтесь ролью, включающей в себя профиль управления процессами (Process Management).
Профиль управления процессами входит в роль системного администратора (System Administrator). Для получения дополнительной информации о ролях см. Using the Solaris Management Tools With RBAC (Task Map) в System Administration Guide: Basic Administration.
Свяжите процесс с пулом вручную:
# poolbind -p ohare $$ |
Проверьте привязку процесса к пулу командой poolbind с параметром -q.
$ poolbind -q $$ 155509 ohare |
Выводится идентификатор процесса и привязка к пулу.
Для привязки задач или проектов к пулу используется команда poolbind с параметром -i. В следующем примере все процессы в проекте airmiles связываются с пулом laguardia.
Перейдите в режим суперпользователя или воспользуйтесь ролью, включающей в себя профиль управления процессами (Process Management).
Профиль управления процессами входит в роль системного администратора (System Administrator). Для получения дополнительной информации о ролях см. Using the Solaris Management Tools With RBAC (Task Map) в System Administration Guide: Basic Administration.
Свяжите все процессы в проекте airmiles с пулом laguardia.
# poolbind -i project -p laguardia airmiles |
Атрибут project.pool позволяет выполнить привязку процессов проекта к пулу ресурсов.
Перейдите в режим суперпользователя или воспользуйтесь ролью, включающей в себя профиль управления процессами (Process Management).
Профиль управления процессами входит в роль системного администратора (System Administrator). Для получения дополнительной информации о ролях см. Using the Solaris Management Tools With RBAC (Task Map) в System Administration Guide: Basic Administration.
Добавьте атрибут project.pool к каждой записи в базе данных project.
# projmod -a -K project.pool=poolname 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.
Запустите процесс в проекте passes.
$ newtask -l -p passes |
Для проверки правильности привязки проекта можно воспользоваться командой poolbind с параметром -q. Для передачи в команду номера процесса родительской оболочки используется двойной знак доллара ($$).
$ poolbind -q $$ 6384 pool backstage |
Выводится идентификатор процесса и привязка к пулу.
Команда poolstat позволяет вывести статистические данные по ресурсам, связанным с пулом. Для получения дополнительной информации см. Наблюдение за механизмом пулов и степени использования ресурсов командой poolstat и справочную страницу poolstat(1M).
В следующих подразделах приводятся примеры создания отчетов в различных целях.
По команде poolstat без аргументов выводится строка заголовка и по одной строке информации для каждого пула. В строке информации отображается идентификатор пула, имя пула и статистика по ресурсам набора процессоров, присоединенного к пулу.
machine% poolstat pset id pool size used load 0 pool_default 4 3.6 6.2 1 pool_sales 4 3.3 8.4 |
Следующая команда создает три отчета с 5-секундным интервалом выборки.
machine% poolstat 5 3 pset id pool size used load 46 pool_sales 2 1.2 8.3 0 pool_default 2 0.4 5.2 pset id pool size used load 46 pool_sales 2 1.4 8.4 0 pool_default 2 1.9 2.0 pset id pool size used load 46 pool_sales 2 1.1 8.0 0 pool_default 2 0.3 5.0 |
В следующем примере команда poolstat с параметром -r используется для вывода статистики по набору ресурсов набора процессоров. Следует отметить, что набор ресурсов pset_default присоединен к нескольким пулам, поэтому он выводится по одному разу для каждого пула, в который он входит.
machine% poolstat -r pset id pool type rid rset min max size used load 0 pool_default pset -1 pset_default 1 65K 2 1.2 8.3 6 pool_sales pset 1 pset_sales 1 65K 2 1.2 8.3 2 pool_other pset -1 pset_default 1 10K 2 0.4 5.2 |
В этой главе рассматривается архитектура управления ресурсами и описывается гипотетический проект консолидации серверов.
В этой главе рассматриваются следующие темы:
В этом примере в одной системе консолидируются пять приложений. Целевые приложения имеют разные требования к ресурсам, разные множества пользователей и разные архитектуры. В настоящее время каждое приложение существует на выделенном сервере, разработанном с учетом требований приложения. Приложения и их характеристики сведены в следующую таблицу.
Описание приложений |
Характеристики |
---|---|
Сервер приложений |
Отрицательная масштабируемость при увеличении числа процессоров свыше 2. |
Экземпляр базы данных для сервера приложений |
Интенсивная обработка транзакций. |
Сервер приложений в среде тестирования и разработки |
На базе графического интерфейса, с непротестированным кодом. |
Сервер обработки транзакций |
Основной показатель – время отклика. |
Автономный экземпляр базы данных |
Обработка большого количества транзакций и обслуживание нескольких часовых поясов. |
Для консолидации приложений в единую систему используется следующая конфигурация.
В сервере приложений установлены два процессора.
Экземпляр базы данных для сервера приложений и автономный экземпляр базы данных консолидируются на едином наборе из четырех или более процессоров. Для автономного экземпляра базы данных гарантируется 75 процентов этого ресурса.
Для обеспечения достаточно быстрого отклика сервера приложений требуется класс планирования IA. Для снижения влияния некорректных сборок кода накладываются ограничения по памяти.
Для минимизации задержки запросов серверу обработки транзакций назначается выделенный набор по крайней мере из двух процессоров.
Эта конфигурация относится к известным приложениям, выполняющимся в каждом из наборов ресурсов и потребляющим в них процессорные циклы. Таким образом, можно установить ограничения, позволяющие перенести процессорный ресурс в набор, где имеется потребность в этом ресурсе.
Для обеспечения возможности получения дополнительных ресурсов, интенсивно используемыми наборами (по сравнению с наборами, степень использования которых ниже), устанавливается целевая нагрузка wt-load.
Для целевого показателя locality задается значение tight , что позволяет максимизировать локальность процессоров.
Также накладывается дополнительное ограничение, предотвращающее использование наборов ресурсов более чем на 80 процентов. Это ограничение позволяет обеспечить доступ всех приложений к требуемым ресурсам. Кроме того, для транзакционного набора процессоров цель поддержания потребления на уровне ниже 80 процентов вдвое важнее других указанных целевых показателей. Эта важность определяется в конфигурации.
Отредактируйте файл базы данных/etc/project. Добавьте записи, реализующие требуемые элементы управления ресурсами и выполняющие сопоставление пользователей и пулов ресурсов, а затем просмотрите полученный файл.
# cat /etc/project . . . user.app_server:2001:Production Application Server:::project.pool=appserver_pool user.app_db:2002:App Server DB:::project.pool=db_pool;project.cpu-shares=(privileged,1,deny) development:2003:Test and development::staff:project.pool=dev_pool; process.max-address-space=(privileged,536870912,deny)keep with previous line user.tp_engine:2004:Transaction Engine:::project.pool=tp_pool user.geo_db:2005:EDI DB:::project.pool=db_pool;project.cpu-shares=(privileged,3,deny) . . . |
Группа разработки должна выполнять свои задачи в проекте по разработке, поскольку доступ к этому проекту осуществляется по идентификатору группы пользователя (GID).
Создайте входной файл с именем pool.host, который будет использоваться для настройки требуемых пулов ресурсов. Просмотрите файл.
# cat pool.host create system host create pset dev_pset (uint pset.min = 0; uint pset.max = 2) create pset tp_pset (uint pset.min = 2; uint pset.max=8) create pset db_pset (uint pset.min = 4; uint pset.max = 6) create pset app_pset (uint pset.min = 1; uint pset.max = 2) create pool dev_pool (string pool.scheduler="IA") create pool appserver_pool (string pool.scheduler="TS") create pool db_pool (string pool.scheduler="FSS") create pool tp_pool (string pool.scheduler="TS") associate pool dev_pool (pset dev_pset) associate pool appserver_pool (pset app_pset) associate pool db_pool (pset db_pset) associate pool tp_pool (pset tp_pset) modify system tester (string system.poold.objectives="wt-load") modify pset dev_pset (string pset.poold.objectives="locality tight; utilization < 80") modify pset tp_pset (string pset.poold.objectives="locality tight; 2: utilization < 80") modify pset db_pset (string pset.poold.objectives="locality tight;utilization < 80") modify pset app_pset (string pset.poold.objectives="locality tight; utilization < 80") |
Обновите конфигурацию с использованием входного файла pool.host.
# poolcfg -f pool.host |
Активируйте конфигурацию.
# pooladm -c |
Теперь архитектура в системе переведена в рабочее состояние.
Для просмотра конфигурации архитектуры, содержащей также элементы по умолчанию, создаваемые системой, необходимо ввести следующую команду:
# pooladm system host string system.comment int system.version 1 boolean system.bind-default true int system.poold.pid 177916 string system.poold.objectives wt-load pool dev_pool int pool.sys_id 125 boolean pool.default false boolean pool.active true int pool.importance 1 string pool.comment string pool.scheduler IA pset dev_pset pool appserver_pool int pool.sys_id 124 boolean pool.default false boolean pool.active true int pool.importance 1 string pool.comment string pool.scheduler TS pset app_pset pool db_pool int pool.sys_id 123 boolean pool.default false boolean pool.active true int pool.importance 1 string pool.comment string pool.scheduler FSS pset db_pset pool tp_pool int pool.sys_id 122 boolean pool.default false boolean pool.active true int pool.importance 1 string pool.comment string pool.scheduler TS pset tp_pset pool pool_default int pool.sys_id 0 boolean pool.default true boolean pool.active true int pool.importance 1 string pool.comment string pool.scheduler TS pset pset_default pset dev_pset int pset.sys_id 4 string pset.units population boolean pset.default false uint pset.min 0 uint pset.max 2 string pset.comment boolean pset.escapable false uint pset.load 0 uint pset.size 0 string pset.poold.objectives locality tight; utilization < 80 pset tp_pset int pset.sys_id 3 string pset.units population boolean pset.default false uint pset.min 2 uint pset.max 8 string pset.comment boolean pset.escapable false uint pset.load 0 uint pset.size 0 string pset.poold.objectives locality tight; 2: utilization < 80 cpu int cpu.sys_id 1 string cpu.comment string cpu.status on-line cpu int cpu.sys_id 2 string cpu.comment string cpu.status on-line pset db_pset int pset.sys_id 2 string pset.units population boolean pset.default false uint pset.min 4 uint pset.max 6 string pset.comment boolean pset.escapable false uint pset.load 0 uint pset.size 0 string pset.poold.objectives locality tight; utilization < 80 cpu int cpu.sys_id 3 string cpu.comment string cpu.status on-line cpu int cpu.sys_id 4 string cpu.comment string cpu.status on-line cpu int cpu.sys_id 5 string cpu.comment string cpu.status on-line cpu int cpu.sys_id 6 string cpu.comment string cpu.status on-line pset app_pset int pset.sys_id 1 string pset.units population boolean pset.default false uint pset.min 1 uint pset.max 2 string pset.comment boolean pset.escapable false uint pset.load 0 uint pset.size 0 string pset.poold.objectives locality tight; utilization < 80 cpu int cpu.sys_id 7 string cpu.comment string cpu.status on-line pset pset_default int pset.sys_id -1 string pset.units population boolean pset.default true uint pset.min 1 uint pset.max 4294967295 string pset.comment boolean pset.escapable false uint pset.load 0 uint pset.size 0 cpu int cpu.sys_id 0 string cpu.comment string cpu.status on-line |
Графическое представление архитектуры приведено ниже.
В пуле db_pool для автономного экземпляра базы данных гарантируется 75 процентов процессорного ресурса.
В этой главе описываются функции управления ресурсами и наблюдения за производительностью в консоли Solaris Management Console. Консоль позволяет работать лишь с частью функций управления ресурсами.
Консоль используется для контроля производительности системы и для ввода значений элементов управления ресурсами, приведенных в Таблица 15–1, для проектов, задач и процессов. Консоль служит удобной, безопасной альтернативой интерфейса командной строки (CLI) и предназначается для управления сотнями конфигурационных параметров, разбросанных по разным системам. Управление каждой системой осуществляется индивидуально. Графический интерфейс консоли подходит для всех уровней опыта.
Рассматриваются следующие темы:
Задача |
Описание |
Инструкции |
---|---|---|
Использование консоли |
Запустите консоль Solaris Management Console в локальной среде или в среде службы имен либо службы каталога. Следует отметить, что в среде службы имен недоступна служебная программа производительности. |
Starting the Solaris Management Console в System Administration Guide: Basic Administration и Using the Solaris Management Tools in a Name Service Environment (Task Map) в System Administration Guide: Basic Administration |
Наблюдение за производительностью системы |
Доступ к служебной программе производительности (Performance) в окне "System Status". | |
Добавление элементов управления ресурсами к проектам |
Доступ к вкладке "Resource Controls" в "System Configuration". |
Консоль Solaris Management Console включает в себя функциональные возможности управления ресурсами. Консоль служит контейнером для графических средств администрирования, хранящихся в коллекциях, называемых комплектами инструментальных средств. Для получения информации о и ее использования см. Глава 2, Working With the Solaris Management Console (Tasks), в System Administration Guide: Basic Administration.
Основным источником документации по использованию консоли и ее средств является справочная система в самой консоли. Описание документации, доступной в интерактивной справке, приведены в разделе Solaris Management Console (Overview) в System Administration Guide: Basic Administration.
Термин область действия управления относится к среде службы имен, выбранной для использования с требуемым средством управления. Для элементов управления ресурсами и служебных программ производительности можно выбрать следующие области действия: локальный файл /etc/project или NIS.
Область действия управления, выбранная в ходе консольного сеанса, должна соответствовать основной службе имен, указанной в файле /etc/nsswitch.conf.
Служебная программа производительности (Performance) используется для наблюдения за использованием ресурсов. Информацию об использовании ресурсов можно получить в обобщенном виде по отдельным проектам или пользователям.
Служебная программа производительности расположена в группе "System Status" на панели переходов. Доступ к служебной программе производительности осуществляется следующим образом:
Щелкните элемент управления System Status на панели переходов.
Этот элемент управления применяется для раскрытия пунктов меню на панели переходов.
Щелкните элемент управления "Performance".
Щелкните элемент управления "System".
Дважды щелкните "Summary", "Projects" или "Users".
Выбор зависит от ресурсов, использование которых требуется контролировать.
Приводятся значения для следующих атрибутов.
Атрибут |
Описание |
---|---|
Активные процессы |
Число активных в системе процессов. |
Используемая физическая память |
Объем используемой системной памяти. |
Свободная физическая память |
Объем доступной системной памяти. |
Swap Used |
Объем используемого пространства подкачки в системе. |
Swap Free |
Объем свободного пространства подкачки в системе. |
Частота страниц |
Интенсивность подкачки страниц в системе. |
Системные вызовы |
Число системных вызовов в секунду. |
Сетевые пакеты |
Число передаваемых сетевых пакетов в секунду. |
Использование ЦП |
Процент процессорной мощности, используемой в настоящее время. |
Load Average |
Число процессов в очереди выполнения системы, усредненное за последние 1 минуту, 5 минут и 15 минут. |
Приводятся значения для следующих атрибутов.
Атрибут |
Краткое имя |
Описание |
---|---|---|
Входные блоки |
inblk |
Число считанных блоков. |
Записанные блоки |
oublk |
Число записанных блоков. |
Прочитанные/записанные символы |
ioch |
Число записанных и считанных символов. |
Время бездействия из-за ошибки страницы данных |
dftime |
Время, затраченное на обработку ошибок страниц данных. |
Непреднамеренные переключения контекста |
ictx |
Число непроизвольных переключений контекста. |
Время системного режима |
stime |
Время, проведенное в режиме ядра. |
Средняя нагрузка |
majfl |
Число существенных ошибок отсутствия страниц. |
Полученные сообщения |
mrcv |
Число полученных сообщений. |
Отправленные сообщения |
msend |
Число отправленных сообщений. |
Небольшие ошибки страниц |
minf |
Число несущественных ошибок отсутствия страниц. |
Число процессов |
nprocs |
Число процессов, принадлежащих пользователю или проекту. |
Число LWP |
count |
Число легковесных процессов. |
Другое время бездействия |
slptime |
Время бездействия, отличное от времени tftime, dftime, kftime и ltime |
Время ЦП |
pctcpu |
Процент процессорного времени, использованного процессом, пользователем или проектом за последнее время. |
Используемая память |
pctmem |
Процент системной памяти, используемой процессом, пользователем или проектом. |
Размер кучи |
brksize |
Объем памяти, выделенный для сегмента данных процесса. |
Размер резидентного набора |
rsssize |
Текущий объем памяти, заявленный процессом. |
Размер обработки образа |
size |
Размер памяти, занимаемой процессом, в килобайтах. |
Полученные сигналы |
sigs |
Число полученных сигналов. |
Время останова |
stoptime |
Время, проведенное в остановленном состоянии. |
Swap Operations |
swaps |
Число выполняемых операций подкачки. |
Выполненные системные вызовы |
sysc |
Число системных вызовов, выполненных за последний временной интервал. |
Время бездействия из-за ошибки системной страницы |
kftime |
Время, затраченное на обработку ошибок страниц. |
Время системных ловушек |
ttime |
Время, затраченное на обработку системных ловушек. |
Время бездействия из-за ошибки текстовой страницы |
tftime |
Время, затраченное на обработку отсутствия текстовых страниц. |
Время бездействия из-за ожидания блокировки пользователя |
ltime |
Время, затраченное на ожидание пользовательских блокировок. |
Время пользовательского режима |
utime |
Время, проведенное в режиме пользователя. |
Время системного и пользовательского режима |
time |
Совокупное время работы процессора. |
Преднамеренные переключения контекста |
vctx |
Число добровольных переключений контекста. |
Время ожидания ЦП |
wtime |
Время, затраченное на ожидание освобождения процессора (задержка). |
Элементы управления ресурсами позволяют связать проект с рядом ограничений по ресурсам. Эти ограничения определяют допустимое использование ресурса задачами и процессами, выполняющимися в контексте проекта.
Вкладка "Resource Controls" расположена в разделе "System Configuration" на панели переходов. Для обращения к элементам управления ресурсами необходимо выполнить следующие действия:
Щелкните элемент управления "System Configuration" на панели переходов.
Дважды щелкните пункт "Projects".
Выберите проект щелчком в главном окне консоли.
Выберите "Properties" из меню "Action".
Щелкните вкладку "Resource Controls".
Выполните просмотр, добавление, редактирование либо удаление значений элементов управления ресурсами для процессов, проектов и задач.
В следующей таблице содержится перечень элементов управления ресурсами, которые можно настраивать при помощи консоли. В таблице указывается ресурс, ограничиваемый каждым элементом управления. В таблице также представлены единицы, используемые по умолчанию для данного ресурса в базе данных project. Единицы по умолчанию могут быть двух типов:
Количества соответствуют ограниченным объемам.
Индексы соответствуют максимально допустимым идентификаторам.
Так, project.cpu-sharesуказывает количество долей, которые разрешено использовать для проекта. process.max-file-descriptor указывает наивысший номер файла, который может быть назначен процессу системным вызовом open(2).
Таблица 15–1 Стандартные элементы управления ресурсами в Solaris Management Console
Имя элемента управления |
Описание |
Единица по умолчанию |
---|---|---|
project.cpu-shares |
Число долей ЦП, выделенных данному проекту планировщиком долевого распределения (FSS) (см. справочную страницу FSS(7)) |
Количество (доли) |
task.max-cpu-time |
Максимальное процессорное время, доступное процессам этой задачи. |
Время (секунды) |
task.max-lwps |
Максимальное количество LWP, одновременно доступных процессам этой задачи. |
Количество (LWP) |
process.max-cpu-time |
Максимальное процессорное время, доступное этому процессу. |
Время (секунды) |
process.max-file-descriptor |
Максимальный индекс дескриптора файла, доступный этому процессу. |
Индекс (максимальный дескриптор файла) |
process.max-file-size |
Максимальное смещение в файле, доступное данному проекту для записи. |
Размер (байты) |
process.max-core-size |
Максимальный размер файла дампа оперативной памяти, создаваемого этим процессом. |
Размер (байты) |
process.max-data-size |
Максимальный размер кучи, доступной этому процессу. |
Размер (байты) |
process.max-stack-size |
Максимальный сегмент памяти стека, доступный этому процессу. |
Размер (байты) |
process.max-address-space |
Максимальный размер адресного пространства, полученный суммированием размеров сегментов, доступных данному процессу. |
Размер (байты) |
Значения элементов управления ресурсами можно просматривать, добавлять, редактировать или удалять. Эти операции выполняются в диалоговых окнах консоли.
Просмотр элементов управления ресурсами и их значений осуществляется в таблицах консоли. В столбце "Resource Control" выводится список элементов управления ресурсами, подлежащих настройке. В столбце "Value" отображаются свойства, связанные с каждым из элементов управления ресурсами. В этой таблице значения приводятся в круглых скобках в виде простого текста, разделенного запятыми. Значения в круглых скобках представляют собой "выражения действия". Каждое выражение действия состоит из порогового значения, уровня полномочий, одного сигнала и одного локального действия, связанного с определенным пороговым значением. Каждому элементу управления ресурсами может соответствовать несколько выражений действия, также разделенных запятыми.
В работающей системе значения, измененные в базе данных projectпосредством консоли, применяются только в отношении новых задач, запущенных в проекте.
Для получения информации относительно проектов и задач см. Глава 2Проекты и задачи (обзор). Для получения информации относительно элементов управления ресурсами см. Глава 6Элементы управления ресурсами (обзор). Для получения информации о планировщике долевого распределения (FSS) см. Глава 8Планировщик долевого распределения (обзор).
При помощи консоли могут быть настроены не все возможные элементы управления ресурсами. Список элементов управления, которые можно настроить в консоли, приведены в Таблица 15–1.