Омар Хайям

команда NICE Динамічні пріоритети в ОС Unix Особливості планувальників деяких версій Unix Процеси реального часу і їх планування в Unix SVR4 Конфігурація планувальника Unix SVR4
висновок література

Наведена як епіграф цитата з Омара Хайяма прикрашала колись заставку діалогової системи PRIMUS - популярної в світі ЄС ЕОМ розробки, виконаної в Московському інженерно-фізичному інституті. Комп'ютерна інтерпретація цього чотиривірші явно натякає на те, що якщо будь-які завдання постійно отримують більш високий пріоритет, то її менш пріоритетні конкуренти можуть "до смерті" очікувати необхідних ресурсів. Знання алгоритмів планування процесів і системи пріоритетів ОС Unix у багатьох випадках дозволяють системному адміністратору успішно впоратися з проблемами підвищення продуктивності. У разі якщо комп'ютер, що працює під управлінням ОС Unix, вирішує завдання в реальному часі, значення планування процесів ще більше зростає.

У запропонованій статті надано огляд питань, пов'язаних з пріоритетами процесів і їх плануванням в ОС Unix. Однак ряд моментів планування, специфічних для мультипроцесорних систем, в статті не розглядається. Більшість наведених даних в тій чи іншій мірі справедливі для самих різних діалектів Unix. У ряді випадків, коли мова йде про будь-якої конкретної комерційної версії фірми-виробника, це спеціально обмовляється. Найбільша увага приділяється Unix SVR4. Це пов'язано з широкою поширеністю даної версії як платформи для реалізації ОС фірм-виробників. Зокрема, одна з найпопулярніших в Росії серед Unix-платформ ОС Solaris фірми Sun заснована на Unix SVR4.

З метою "демонополізації" ресурсу центрального процесора в операційних системах давно застосовується квантування часу. Однак реальні вимоги до планування завдань (процесів в термінології Unix), так само як і методи задоволення цих вимог (планування) набагато складніше. В алгоритмах планування задіяні пріоритети процесів. В ОС Unix Стандартний планувальник набагато простіше, ніж в 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 Відповідне мінімальної пріоритетності (аналогічно значенням пріоритету 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.
Залежність dprty від часу (чим вище dprty, тим нижче пріоритетність). С - лічильник використання процесора.

Особливості планувальників деяких версій Unix

Як вже було показано, різні реалізації 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 відноситься до процесів низької пріоритетності - вони можуть використовувати процесор, тільки якщо в системі немає "звичайних", готових до виконання процесів.

• -n nice задає значення nice в діапазоні від 0 до 39 включно.
• -t slice задає квант часу в одиницях "тиків" годин (зазвичай 10 мсек)
• -d період, обсяг встановлює режим періодичного планування типу deadline. В цьому режимі процесу гарантується виділення певного обсягу часу процесора (мсек) в кожен період часу, що задається аргументом період (мсек).
• -D only (any) "уточнює" режим планування типу deadline.

Якщо задано 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.

література

1. Лорін Г., Дейтел Х. М. Операційні системи. М .: Фінанси і статистика, 1984
2. Кузьмінський М. Відкриті системи. 1997. # 1. С.18-22
3. OS MVS. System Tuning Guide, 1983
4. M. Loukides System Performance Tuning. O'Reilly & Assoc., 1992
5. Frish A. Essential System Administration, 2nd Ed. O'Reilly & Assoc., 1995
6. А. Робачевскій, Операційна система Unix, BHV, С.-Петербург, 1997.
7. Bach MJ The Design of the Unix Operating System. Prentice Hall, 1990.