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

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

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

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

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

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

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

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

• Настройка FSS

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Настройка FSS

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

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

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

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

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

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

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

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

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

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

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

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

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

-r

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

-n имя

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

-v значение

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

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

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

x-files

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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