Напрасно ты винишь в непостоянстве рок.
Что не внакладе ты, тебе и невдомек.
Когда б он в милостях своих был постоянен,
ты б очереди ждать своей до смерти мог.
Омар Хайям
Приведенная в качестве эпиграфа цитата из Омара Хайяма украшала когда-то заставку диалоговой системы PRIMUS - популярной в мире ЕС ЭВМ разработки, выполненной в Московском инженерно-физическом институте. Компьютерная интерпретация этого четверостишия явно намекает на то, что если какие-либо задачи постоянно получают более высокий приоритет, то ее менее приоритетные конкуренты могут "до смерти" ожидать требуемых ресурсов. Знание алгоритмов планирования процессов и системы приоритетов ОС Unix во многих случаях позволяют системному администратору успешно справиться с проблемами повышения производительности. В случае если компьютер, работающий под управлением ОС Unix, решает задачи в реальном времени, значение планирования процессов еще больше возрастает.
В предлагаемой статье дан обзор вопросов, связанных с приоритетами процессов и их планированием в ОС Unix. Однако ряд моментов планирования, специфических для мультипроцессорных систем, в статье не рассматривается. Большинство приводимых данных в той или иной степени справедливы для самых разных диалектов Unix. В ряде случаев, когда речь идет о какой-либо конкретной коммерческой версии фирмы-производителя, это специально оговаривается. Наибольшее внимание уделяется Unix SVR4. Это связано с широкой распространенностью данной версии как платформы для реализации ОС фирм-производителей. В частности, одна из самых популярных в России среди Unix-платформ ОС Solaris фирмы Sun основана на Unix SVR4.
С целью "демонополизации" ресурса центрального процессора в операционных системах давно применяется квантование времени. Однако реальные требования к планированию задач (процессов в терминологии Unix), равно как и методы удовлетворения этих требований (планирование) гораздо сложнее. В алгоритмах планирования задействованы приоритеты процессов. В ОС Unix cтандартный планировщик гораздо проще, чем в MVS - знаменитой ОС мэйнфреймов IBM. Однако алгоритмы работы планировщика в ОС Unix и поддерживаемая им система приоритетов также достаточно сложны.
Во многих ОС используется двухуровневый планировщик [1]. В этом случае высокоуровневое планирование часто относится к пакетной обработке. Таким планировщиком заданий в ОС Unix может служить, например, пакетная система NQS [2], которая не является, однако, стандартной частью Unix. Другие средства высокоуровневого планирования дают средства cron, команда at и т. д.
Низкоуровневый планировщик (диспетчер - в терминологии ОС MVS) всегда присутствует в ОС, даже если единственное, что она умеет делать, - это примитивное квантование. В ОС MVS представлена не имеющая себе равных разработка - планировщик промежуточного уровня SRM (System Resource Manager) [1,3]. Он допускает, в частности, формирование политики обработки задач, которую на достаточно высоком уровне формулирует владелец компьютера. Таким образом, планировщик в MVS является трехуровневым. Для ОС Unix также имеются программные системы, предоставляющие пользователю возможность формулировать некоторую собственную политику распределения ресурсов. Среди этих систем, например, Fair Share Scheduler, который доступен, в частности, для OC IRIX 6.2. Однако подобные средства менее развиты, чем в MVS, и не входят в "стандарт" ОС Unix и ее "фирменные диалекты". Статья посвящена базовым средствам ОС Unix, относящимся к низкоуровневому планированию.
Команда NICE
Начнем с наиболее известных пользователям и системным администраторам вещей, относящихся к команде nice. На самом деле реальные внутренние (динамические) приоритеты устроены гораздо хитрее. Сначала поговорим о процессах, работающих в режиме разделения времени. Unix SVR4 позволяет также работать с процессами реального времени, которые мы рассмотрим отдельно.
Строго говоря, существует целый ряд слегка отличающихся друг от друга версий nice: встроенные в С-shell версии для BSD и Unix System V, и собственно Unix-команды (/bin/nice или /usr/bin/nice) для BSD и Unix System V [4,5]. Кроме характерных для мира Unix небольших различий между версиями, здесь присутствует еще одно неудачное решение разработчиков: чем выше значение, задаваемое nice, тем ниже приоритет. Это связано с тем, что разработчики [4] имели в виду под значением nice "уровень приятности" соответствующего процесса для других пользователей: чем ниже приоритетность чужого процесса, тем для нас, естественно, лучше - "уровень приятности" этого процесса выше. Во избежание путаницы будем говорить о повышенной или пониженной приоритетности процессов, а термин "величина (значение) приоритета" употреблять в смысле значения nice. Итак, чем выше значение приоритета, тем ниже приоритетность процесса.
В BSD Unix значение приоритета является целым числом от -20 до +20: -20 относится к самым приоритетным процессам, а +20 - к процессам наименьшей приоритетности. Умалчиваемое значение приоритета (если не используется nice) равно 0. Точнее говоря, если пользователь не обращается к nice, приоритет запускаемого процесса будет унаследован от предка, в простейшем случае - оболочки, обычно имеющей нулевое значение приоритета. Рядовой пользователь может задавать только более высокие (положительные) значения приоритета, понижая приоритетность запускаемых процессов. Суперпользователь может задавать также отрицательные значения приоритета. Далее, если команду может выполнить обычный пользователь, в тексте будет указано приглашение "%", иначе - приглашение "#". Команда
(1)%nice command
выполнит Unix-команду command co значением приоритета 4 (умалчиваемая величина, если значение приоритета не задано явно, см. (2)). Например, команда
#nice fsr /usr1
в ОС IRIX выполнит дефрагментацию файловой системы /usr1, имеющей тип EFS, с пониженной приоритетностью.
Часто отрицательные, низшие значения приоритета (от -17 до -20) резервируются для системных процессов. Кроме того, большинство систем имеют еще одно специальное выделенное значение приоритета. Если процесс имеет это значение приоритета, то он будет получать ресурс центрального процессора только в том случае, если в системе отсутствуют любые другие процессы, претендующие на использование процессора. Например, в Digital Unix это происходит при значении приоритета, равном 20 [5].
Здесь следует обратить внимание на одно важное обстоятельство. Возьмем ситуацию, в которой требуется, чтобы некоторое большое (в смысле затрат процессорных ресурсов) пакетное задание не мешало работе других процессов разделения времени. Может оказаться недостаточным просто понизить приоритет задания, указав ему значение, приоритета равное 20. Действительно, если пакетное задание отличается также большими требованиями к оперативной памяти - что бывает достаточно часто, - то, возможно, при работе интерактивных процессов пакетное задание придется свернуть (swap-out). А когда закончатся интерактивные команды, Unix вернет пакетное задание обратно в память (swap-in). Если такая смена состояний будет происходить достаточно часто, администратор рискует получить плохое время реакции для интерактивных процессов из-за частого свопинга.
Формат команды nice, встроенной в csh, в BSD Unix имеет вид
(2)#nice {+/-}n command
где n - целое число от 0 до 20 включительно. Аналогично устроена встроенная команда nice в GNU-версии tcsh nice. Как команда BSD Unix может использоваться более универсально, в том числе в скриптах Bourne shell. Этот вариант nice отличается от встроенного в csh только синтаксисом:
(3)% nice -n command
означает, в отличие от (2), положительное значение приоритета nice - более низкую приоритетность. А команда
(4)#nice -n command
используется для указания отрицательного значения приоритета nice - более высокой приоритетности. Естественно, форма (4) команды nice может применяться только суперпользователем.
Рассмотрим теперь Unix SVR3. В качестве примера реализации nice по схеме SVR3 можно привести IRIX 6.1, которая используется в суперкомпьютерном центре ИОХ РАН на SMP-сервере Power Challenge. Хотя в SVR3 основные идеи такие же, как и в BSD, реализация имеет некоторые особенности. Значения приоритета nice изменяются от 0 до 39 включительно; 39 cоответствует минимальной приоритетности (аналогично значению приоритета 20 в BSD), 0 - наивысшей приоритетности; умалчиваемое значение приоритета равно 20. В некоторых реализациях System V поддержка процессов реального времени также осуществляется через nice.
Встроенная в csh версия nice для SVR3 в остальном аналогична BSD-версии. Команда (1) приводит к выполнению command со значением приоритета 24 - как и для BSD, на 4 больше умалчиваемого значения приоритета; как и в BSD, это означает понижение приоритетности.
Команда формы (2) в SVR3 отличается от BSD, во-первых, возможными значениями n (целые от 0 до 19). Во-вторых, хотя здесь, как и в BSD, чем больше n, тем ниже приоритетность, точный смысл n в (2) другой: в SVR3 n означает изменение относительно умалчиваемого (при отсутствии обращения к nice) значения nice. Таким образом,
%nice +7 fsr /usr1
означает выполнение fsr со значением приоритета, равным 27.
"Настоящая" (не встроенная в сsh) команда nice в SVR3 также имеет свои отличия. Форма (1) в данном случае - это увеличение значения приоритета на 10, а не на 4, что приводит к более существенному уменьшению приоритетности. Форма (3) означает в SVR3 увеличение значения приоритета на n (уменьшение приоритетности). Форма (4) означает уменьшение значения приоритета на n (увеличение приоритетности) и доступна только суперпользователю. В ОС Solaris (Unix SVR4) применяется похожая реализация nice, но эта ОС располагает более мощными и развитыми средствами, в частности, командой priocntl (см. ниже).
Кроме различных форм команды nice, в BSD Unix появилась команда renice, которая влияет на уже выполняющиеся процессы. Она имеет форму
-p pid (5)#/etc/renice приоритет -g pgrp -u username
где "приоритет" задает новое значение приоритета процессу, и, естественно, лежит в диапазоне от -20 до +20; pid (Process ID) задает номер процесса, pgrp - номер группы процессов, username - имя пользователя; фигурные скобки означают "или". Задание номера группы процессов или имени пользователя означает изменение значения приоритета nice для всех соответствующих процессов.
Многие версии Unix System V, в том числе IRIX 6.1, также стали поддерживать команду renice. Кроме формы (5), применяется и более простая форма
(6)#renice приоритет pid
представляющая собой сокращение первого варианта формы (5) - изменение значения приоритета конкретного процесса.
Наконец, некоторые версии Unix, например, Digital Unix и HP-UX, применяют слегка модифицированную форму (7):
(7)#renice -n приоритет pid
Естественно, использовать команду renice для повышения приоритетности может только суперпользователь. Кроме команд nice имеются и соответствующие системные вызовы, которые в данной статье не рассматриваются.
Динамические приоритеты в ОС Unix
В действительности расположенный в ядре планировщик Unix работает не со "статическими" приоритетами nice, а с приоритетами, динамически изменяемыми по ходу выполнения процесса. Так, в BSD-системах к процессам, которые "скушали" определенный объем процессорного времени, например 20 минут, автоматически применяется вызов nice [4]. Схема, введенная в BSD 4.3, рассмотрена в [6]. Дальнейшее изложение в данном разделе статьи будет ориентировано на Unix System V. Как значение nice, так и значение динамического приоритета для процессов можно определить из вывода команды ps -l. Эти значения приводятся в колонках, озаглавленных NI и PRI соответственно.
Здесь можно провести некоторую аналогию с языком управления заданиями в ОС MVS. Параметр PRTY оператора EXEC является в определенном смысле аналогом nice: от их значений зависит динамический приоритет. Однако "настоящий" приоритет выполнения в MVS может быть задан параметром DPRTY, хотя и этот приоритет MVS может динамически изменить.
Планировщик Unix поддерживает фактически несколько циклических (round robin) очередей c обратной связью. Процесс, квант времени которого истек, возвращается в зависимости от динамического приоритета в одну из таких очередей, весь набор которых называют "очередью выполнения" (run queue).
Планировщик просматривает набор процессов, находящихся в оперативной памяти и готовых к выполнению, и выбирает среди них наиболее приоритетный процесс. Если имеется несколько процессов с одинаково высокой приоритетностью на выполнение выбирается тот, который дольше всего ждет процессорный ресурс в состоянии готовности к выполнению. Если же не удается вообще найти готовые к выполнению процессы, планировщик ожидает следующего прерывания, которое произойдет не позднее чем через один такт часов, и снова выполняет процесс планирования.
Все процессы в соответствии с их приоритетами можно разбить на два класса: пользовательские процессы разделения времени и системные процессы (процессы ядра). В классе имеется несколько уровней приоритета, каждому из которых в классе пользовательских процессов соответствует своя очередь. Приоритетность пользовательских процессов лежит ниже некоторого порогового значения, а процессов ядра - выше этого порога. Далее речь пойдет только о пользовательских процессах, принадлежащих классу процессов разделения времени.
Когда процесс "отправляется спать", планировщик присваивает ему фиксированный приоритет в зависимости от причины засыпания, который не зависит от наблюдавшейся перед этим событием активности "поедания" процессом процессорных ресурсов. Дополнительные подробности можно найти в [7].
Динамические приоритеты процессов, работающих в пользовательском режиме, перевычисляются планировщиком Unix System V один раз в секунду [7]. Обработчик прерываний от часов может прерывать пользовательский процесс несколько раз за его квант времени. Каждый раз при обработке такого прерывания счетчик "С" использования процессора в соответствующей строке таблицы процессов увеличивается на 1. Каждую секунду обработчик прерываний от часов пересчитывает счетчик использования процессора для каждого пользовательского процесса по формуле
С=С*k (8)
где 0 dprty=K*C + базовый_приоритет + nice (9) где базовый_приоритет - это указанное пороговое значение приоритета пользовательских процессов (более приоритетными бывают только системные процессы). Константа К для System V равна 0.5. Близкие к (8), (9) алгоритмы использует Digital Unix. Чем ниже величина dprty динамического приоритета процесса, тем выше его приоритетность. Самая низкая величина dprty отвечает пороговому значению, ниже которого располагаются только системные процессы, работающие в режиме ядра. В результате перерасчета dprty, пользовательские процессы, активно использующие процессор перемещаются из очереди с одним приоритетом в очереди с другим, более высоким dprty (в очереди менее приоритетных процессов). Чтобы понять, как работает механизм перерасчета динамических приоритетов в соответствии с формулами (8) и (9), рассмотрим конкретный пример, взятый из [7] для простейшего случая nice=0. Пусть имеется три готовых к выполнению процесса A, B, C, находящихся в памяти и имеющих стартовое значение приоритета, равное базовому значению (60), - максимально возможную приоритетность. Предположим, что эти процессы не делают системных вызовов и что в системе нет других готовых к выполнению процессов. Пусть квант времени равен 1 сек, а прерывания от часов происходят 60 раз за 1 сек. Если A начинает выполняться первым, то через 1 сек его счетчик использования процессора будет равен 60. В этот момент времени планировщик пересчитает dprty (рис.1), и далее будет выполняться процесс B, а его счетчик использования процессора будет возрастать. При t=2 cек управление получит наиболее приоритетный процесс С и т. д. Рисунок 1. Как уже было показано, различные реализации Unix имеют свои особенности в работе с командой nice. Многие реализации отличаются существенными модификациями схемы работы с приоритетами. В качестве примера можно указать планировщик ОС AIX, в котором величины динамических приоритетов колеблются в диапазоне от 0 до 127. В AIX имеется специальная утилита schedtune, которая позволяет изменять некоторые параметры планировщика, в том числе и величину кванта времени. В последней, четвертой версии AIX, в schedtune появились и иные параметры [5]. В качестве другого примера можно подробнее рассмотреть некоторые возможности OC IRIX 6.1 и 6.2. Следующая команда IRIX 6.1/6.2 позволяет изменять некоторые параметры планировщика: (10)#npri [-h ndpri] [-n nice] [-t slice] [-d период, объем] [-D only ] процесс any где процесс задается своим идентификатором или явно указывает, какую команду нужно выполнить с этими параметрами планировщика: процесс ::= команда аргументы_команды -p pid Как правило, эта команда доступна только системному администратору, и хотя ряд параметров в некоторых пределах может изменить и обычный пользователь, по общим соображениям лучше этого не разрешать. -h npri задает неизменный приоритет - приоритетность, не уменьшающуюся во времени. Аргумент npri лежит в диапазоне от 30 до 255, включая границы. Диапазон от 40 до 127 включительно относится к обычным интерактивным процессам разделения времени. Группа более приоритетных процессов имеет более низкое значение приоритета - от 30 до 39. С ними надо работать очень осторожно: обычный интерактивный процесс разделения времени не может их прервать. Диапазон от 127 до 255 относится к процессам низкой приоритетности - они могут использовать процессор, только если в системе нет "обычных", готовых к выполнению процессов.
Зависимость dprty от времени (чем выше dprty, тем ниже приоритетность). С - счетчик использования процессора.Особенности планировщиков некоторых версий Unix
Если задано only, то после исчерпания объема гарантированного процессорного времени процесс не сможет в заданный период претендовать на дополнительное время процессора. Если указано any (по умолчанию), то и после исчерпания гарантированного объема времени процесс будет еще пытаться конкурировать за процессорные ресурсы с другими процессами, но уже на основании обычного режима планирования.В качестве приложений, для которых целесообразно указать гарантированное обслуживание процессором, можно упомянуть задачи визуализационного моделирования, работу с "непрерывными средами" на DAT или CD-ROM и др. Для работы с процессами реального времени в файловой системе xfs в ОС IRIX также имеется возможность поддержания гарантированной обработки подсистемой ввода/вывода. В ОС IRIX 6.х есть системный вызов schedctl, который использует команда npri.
Процессы реального времени и их планирование в Unix SVR4
В некоторых более ранних реализациях System V предусмотрена поддержка процессов реального времени через nice. Для этого суперпользователю приходилось запускать необходимые для работы в реальном времени задания с очень низкими значениями nice (-20 или ниже) [4]. Однако можно сказать, что полная поддержка процессов реального времени появилась только в Unix SVR4. Включение поддержки процессов реального времени в планировщик Unix SVR4 следует считать одним из самых кардинальных изменений в этом компоненте ядра Unix. POSIX 1003.1b описывает стандарт на средства реального времени.
Если интерактивные процессы разделяют процессорное время между собой, то процессы реального времени нуждаются в монополизации процессорного ресурса. Процессы реального времени могут прерывать интерактивные процессы разделения времени, но не наоборот. Если процесс реального времени монополизировал и не отдает процессор, то убить его с терминала из обычной оболочки, работающей в классе разделения времени, не удастся. Процессы реального времени имеют фиксированные приоритеты. Обычно работать с процессами реального времени на компьютере общего назначения не рекомендуется [4].
В Unix SVR4 все процессы делятся на три основных класса в соответствии с их глобальным приоритетом: класс процессов реального времени (RT), класс системных процессов и класс процессов разделения времени (рис. 2). В Руководстве по ОС Solaris говорится о наличии еще и класса интерактивных процессов (IA), для которых целью планировщика является обеспечение хорошего времени ответа, в то время как для класса процессов разделения времени (TS) задача состоит в обеспечении хорошей пропускной способности вычислительной установки, но так, чтобы "не мешать" достижению хорошего времени ответа для процессов класса IA. Доступ к классу IA имеет только суперпользователь. Классы TS и IA разделяют общие параметры планировщика и не различаются между собой с точки зрения механизма планирования. В связи с этим здесь не имеет смысла выделять IA в отдельный класс - будем просто говорить об (общем) классе TS.
Рис. 2. Приоритеты в Unix SVR4
Упомянутые глобальные приоритеты имеют, наконец, "естественный" смысл: чем выше приоритет, тем выше приоритетность процесса. Пользователь может получить соответствующий диапазон приоритетов, выдав команду
(11)%priocntl -l
Для запуска команды на выполнение в реальном времени суперпользователь может ввести
(12)#priocntl -e -c RT -p приоритет команда
где -с RT задает класс (Real Time). Приоритет задает значение приоритета внутри класса процессов реального времени (от 0 до 59, рис. 2); умалчиваемое значение равно 0. Аналогичным образом можно запускать процесс в класс TS.
Следующая команда позволяет суперпользователю перевести существующий процесс в класс реального времени и установить ему приоритет:
(13)#priocntl -s -c RT -p приоритет -i pid n
-s означает "установить" (set) приоритет; -i pid n задает идентификацию процесса, чей pid равен n.
Аналогичным образом можно работать с процессами класса TS. В ключе -i указывается тип идентификации процессов, который может принимать значения pid, ppid, pgid, sid (session id), class, uid, gid, all. Эти обозначения говорят сами за себя. Последний аргумент в команде (13) может задаваться в виде списка разделенных пробелами значений, указывающих на конкретный процесс (или конкретные процессы).
Можно указать, чтобы все процессы определенного пользователя стали работать в реальном времени:
(14)#priocntl -s -c RT -p приоритет -i uid n
Однако при этом в реальном времени будет работать и пользовательская оболочка, что считается опасным [4]. Если необходимо перевести процесс реального времени в класс процессов разделения времени, то это можно сделать командой
(15)#priocntl -s -c TS -p приоритет -i pid n
Здесь приоритет, естественно, задает значение приоритета внутри класса процессов разделения времени - величину nice (0 по умолчанию). Команда priocntl является универсальным средством; с ее помощью можно изменять и приоритеты процессов разделения времени:
(16)%priocntl -s -c TS -p приоритет -i pid n
В качестве другого примера применения priocntl можно взять установку максимального уровня приоритета для определенного процесса из класса TS:
(17)#priocntl -s -m приоритет pid
Данная команда устанавливает (-s) максимальный (-m) приоритет для процесса с идентификатором pid. Это может быть полезно для ограничения возможности роста приоритета низкоприоритетных процессов, чтобы они не мешали распределению процессорного времени более высокоприоритетным интерактивным процессам. Вообще priocntl с ключом -s имеет опции, подобно -m, которые являются специфическими для каждого класса.
#scheduler table for RT RES=1000 100 # 0 100 # 1 ......... 100 # 5 90 # 6 90 # 7 ......... 10 # 58 10 # 59 #end of table
Конфигурирование планировщика Unix SVR4
Планировщик Unix SVR4 имеет гибкие средства конфигурирования, обеспечиваемые командой dispadmin:
#dispadmin -l
выдает всю таблицу планировщика (см. ниже), а команда
#dispadmin -g -c класс
выдает таблицу планировщика для конкретного класса (RT или TS). Таблица планировщика устроена по-разному для процессов класса реального времени и процессов класса разделения времени. Можно считать, что существуют две разные таблицы. Начнем с таблицы планировщика для процессов реального времени. Вот пример этой таблицы, взятый из Руководства по ОС Solaris 2.5:
Первая строка задает единицы измерения времени, используемые в таблице: RES=n означает применение в качестве единицы 1/n сек. Каждая последующая строчка этой таблицы содержит одно целое число, за которым может следовать комментарий, расположенный за символом #. Каждая такая строка соответствует своему уровню приоритета в классе процессов реального времени. Соответствующее число задает квант времени (в единицах RES), который может использовать процесс. Если RES меньше, чем реальное разрешение часов системы, то кванты времени будут при необходимости округляться, чтобы стать кратными разрешению часов. Строчки, содержащие кванты, располагаются в таблице в порядке увеличения приоритета (от 0 до 59). Если указать значение кванта, равное -2, то соответствующие процессы будут получать бесконечно большие кванты.
#scheduler table for TS RES=1000 # quantum exhausted_prty sleep_prty wait_time wait_prty # prty 500 0 10 5 10 # 0 500 0 11 5 11 # 1 500 1 12 5 12 # 2 500 1 13 5 13 # 3 500 2 14 5 14 # 4 500 2 15 5 15 # 5 450 3 16 5 16 # 6 450 3 17 5 17 # 7 .................................................................... 50 48 59 5 59 # 58 50 49 59 5 59 # 59 # end of table
В течение указанного кванта времени процесс реального времени не может быть прерван. По истечении этого кванта планировщик просматривает процессы реального времени, выбирая на выполнение самый высокоприоритетный. Обычно чем выше приоритет, тем меньший квант времени приписывается процессам с этим приоритетом. Принципиальная возможность ядра Unix прервать процесс реального времени используется некоторыми системными администраторами, которые запускают СУБД, скажем Oracle, в режиме реального времени.
Таблица планировщика для класса процессов разделения времени также имеет в начале строку, задающую RES, и далее по одной строке для каждого уровня приоритета в порядке его увеличения:
Здесь квант указывает на период времени, в течение которого процесс может потреблять процессорный ресурс без прерывания. Если процесс полностью исчерпает квант, то он будет прерван и получит приоритет, указываемый во втором поле (приоритет_исчерпания). Как правило, приоритет_исчерпания ниже исходного. Это позволяет понижать приоритет процессоров, интенсивно использующих процессорный ресурс.
Приоритет_засыпания - это приоритет, который получает процесс после пробуждения, если он заснул (например, запустив ввод/вывод), не исчерпав свой квант. Время_ожидания указывает интервал времени, в течение которого процесс с данным приоритетом может ожидать начала выделения ему процессорных ресурсов. По истечении этого времени считается, что "терпение процесса лопнуло", и планировщик обязан поменять ему приоритет на значение, задаваемое полем приоритет_ожидания. При желании системный администратор может указать в этом поле более высокое значение, что выглядит вполне естественно. Установив все величины приоритетов в строке равными приоритету, который эта строка описывает, можно установить режим неизменного приоритета, аналогичный описанному выше для ОС IRIX 6.х. Нетрудно также сформировать таблицу с выделением низкоприоритетных процессов, которые смогут получать процессорный ресурс только при отсутствии в системе процессов с большей приоритетностью и т. д.
Для того чтобы установить свою собственную таблицу планирования, системный администратор может выдать команду
#priocntl -s имя_файла -c класс
где класс= RT или TS, а имя_файла указывает на файл, содержащий описанную таблицу планировщика для процессов реального времени или разделения времени соответственно.
Заключение
Первое, что любят делать многие системные администраторы, особенно молодые и горячие, - это устанавливать себе более высокую приоритетность, например подняв ее для своей оболочки. Ясно, что если поднять ее "до небес", да еще, например, сделать приоритет неуменьшающимся - то, скажем, при инсталляции какого-либо крупного пакета в период трансляции, которая бывает достаточно долгой, пользователи вряд ли будут счастливы. Это нарушение первого принципа: "Живи сам и дай жить другим".
Другая голубая мечта некоторых "крутых" системных администраторов - поменять какие-нибудь "хитрые" параметры, дабы добиться увеличения пропускной способности или уменьшения времени реакции интерактивных процессов. Поскольку современные версии Unix предоставляют в распоряжение системного администратора весьма гибкий и "утонченный" аппарат, не нужно забывать второй принцип: KISS (Keep It Simple, Stupid) - "будь попроще, дурачок". Это золотое правило всех программистов особенно важно при тонкой настройке параметров планировщика. Как правило, хорошо работают уже простые схемы приоритетов.
Работа выполнена в рамках реализации проекта РФФИ 95-07-20201.
Литература
- Лорин Г., Дейтел Х. М. Операционные системы. М.: Финансы и статистика, 1984
- Кузьминский М. Открытые системы. 1997. #1. С.18-22
- OS MVS. System Tuning Guide, 1983
- M. Loukides System Performance Tuning. O'Reilly & Assoc., 1992
- Frish A. Essential System Administration, 2nd Ed. O'Reilly & Assoc., 1995
- А. Робачевский, Операционная система Unix, BHV, С.-Петербург, 1997
- Bach M. J. The Design of the Unix Operating System. Prentice Hall, 1990
