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

ВСТУП

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

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

Найбільш вдалим для вирішення поставленої задачі здається підхід на основі систем підтримки прийняття рішень (СППР). Важливою перевагою універсальних СППР є можливість їх використання в широкому діапазоні завдань ППР: від аналізу ситуації тільки одним фахівцем/керівником за відсутності чисельних даних про характеристики порівнюваних об'єктів до обробки великих об'ємів об'єктивної і суб'єктивної інформації.

Головною в СППР є не обчислювальна частина (для цього досить використовувати Exel), а технологічна підтримка процедури коректного витягання і формалізації суб'єктивних вимог і переваг фахівців, а також процедури покрокової агрегації інформації під контролем аналітика.

ІМІТАЦІЙНА МОДЕЛЬ СИСТЕМИ

ОЦІНКИ ПРОДУКТИВНОСТІ

1 Приклад системи для вивчення оцінки продуктивності

Для проведення дослідження впливу характеристик елементів інформаційної системи на оцінку продуктивності цієї системи введемо в розгляд систему-приклад.

Ця система-приклад має дуже просту конфігурацію і схему. Ця система має конфігурацію, яка приведена на рис. 2.1. Далі по тексту роботи для зручності називатимемо цю систему ПРОП-система (конфігурація Прикладу для вивчення Оцінки Продуктивності).

Рис. 2.1. Блок-схема ПРОП-системи.

Таким чином, термін ПРОП-система позначатиме систему з конфігурацією рис. 2.1. Відмітемо, що природа пристроїв введення-виведення не специфікована; вона залежатиме від типу системи, що розглядається у кожному конкретному випадку. Типові структури систем, з якими ми матимемо справу впродовж цієї книги, перераховані у табл. 2.1 і будуть стисло описані нижче стосовно конфігурації ПРОП-системи.

2.2. Опис роботи ПРОП-системи

Типовими пристроями введення-виведення системи пакетної обробка (у тому числі і конфігурації ПРОП) є пристрої читання записів з магнітної стрічки і пристрій друку.

Користувачі пред'являють свої завдання (програми і дані) у вигляді записів на магнітній стрічці. Записи з магнітної стрічки читаються пристроєм читання записів з магнітної стрічки, і після перетворення кодів їх вміст переноситься в буферну область в основній пам'яті М через Р4. Коли буфер наповниться, його вміст переноситься на диск через Р3. На диску завдання чекають своєї черги на завантаження в пам'ять. Як тільки завдання завантажене через Р3, воно може оброблятися центральним процесором Pi. Під час виконання завдання буде вимагати інформацію, розташовану на робочому диску (Диск2) або на системному диску (Диск). Операційна система, яка розташована в пам'яті М (хоча б частково), піклуватиметься про обмін даних. Завдання також генеруватиме вихідні повідомлення для користувача, які накопичуються на диску, а в кінці виконання завдання друкуються, проходячи через Р3, М і Р4.

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

Типові кроки завдання:

· компіляція,

· виконання програми,

· копіювання файлу з системного диска на робочий диск або, навпаки;

· роздрукування вмісту файлу.

Коли крок завдання закінчується, відведена йому область пам'яті звільняється, а наступний крок того ж завдання додається до списку кроків, що чекають завантаження в М.

Якщо всі процесори на рис. 2.1 насправді представляють один і той же фізичний процесор, скажімо Р*, то поєднання в часі неможливе. У той час коли Р* діє як Р4, він не може діяти як Р1, Р2 або Р3_. У цьому випадку завдання виконуються строго послідовно. Неможливо починати виконання нового завдання, перш ніж завершиться попереднє.

Таку організацію, в якій не допускається суміщення завдань, слід було б назвати чисто однопрограмною.

Нехай тепер процесори на рис. 2.1 представлені чотирма незалежними процесорами. Процесори Р2, Р3 і Р4 називаються каналами введення-виведення і можуть бути або контроллерами (процесори з постійними програмами), або звичайними процесорами з програмами, що запам'ятовуються. Діяльність цих чотирьох процесорів може перекриватися в часі. Тоді, наприклад, поки відбувається передача інформації між пристроєм читання завдань з магнітної стрічки і диском або між диском і пристроєм друку, P1 може виконувати завдання. Цей тип системи називатимемо СПП (СПП означає Суміщення роботи Периферійних Пристроїв у взаємодії з центральним процесором). У такій системі робота центрального процесора і каналу введення-виведення може перекриватися. Проте в пам'яті весь час знаходиться тільки одне завдання користувача, що вконується. Таким чином, не дивлячись на незалежність процесорів, центральний процесор не може перемикатися на інші завдання під час пересилок введення-виведення, замовлених поточним завданням, і має чекати їх завершення. Отже, в системі СПП поєднання обмежене.

Якщо в пам'ять може бути завантажено декілька завдань користувача, центральний процесор може перемикатися з одного завдання на інші, оскільки виконуване завдання потребує введення-виведення даних, а для того, щоб відбулася така передача даних, операційна система повинна зробити необхідні приготування. Ми називатимемо завдання активним, якщо воно знаходиться в даний момент в пам'яті. Перемикання центрального процесора можливо, тільки якщо хоч би одне з інших активних завдань готове до роботи. Активне завдання не готове (або блоковано), якщо воно чекає завершення замовленого їм введення-виведення даних. Такий тип систем ми називатимемо мультипрограмними системами. У такій системі число активних завдань звичайно називається ступенем мультипрограмування. Термін однопрограмна робота буде застосовуватися також і до систем типу СПП, не дивлячись на одночасне виконання деяких дій в таких системах, оскільки центральний процесор не перемикається на інше завдання, поки виконуване завдання блокує саме себе запитом на уведення-виведення даних.

Як у однопрограмних, так і в мультипрограмних системах програма, мабуть, повинна бути повністю завантажена в пам'ять, щоб почалося її виконання. На кожне завдання відводиться певний об'єм пам'яті. Якщо розмір завдання перевершує цей об'єм, програміст повинен розділити завдання на сегменти, які повинні бути послідовно завантажені операційною системою відповідно до детальних вказівок користувача. Ця організація називається (з очевидних причин) ручним управлінням пам'яттю.

Проте можливо (і особливо зручно в мультипрограмних системах) побудувати механізми, які дозволять програмам виконуватися навіть будучи завантаженими лише частково, без жорстких обмежень, сегментів, що накладаються методом перекриття, і без втручання програміста. Це може бути досягнуто застосуванням схем автоматичного управління пам'яттю, які дозволяють операційній системі вирішувати, яка частина програми повинна знаходитися в пам'яті в даний момент. Посилання виконуваної програми на розділ інформації, що не знаходиться в основній пам'яті, викликає відмову. Відмови обробляються операційною системою, яка прочитує відсутній розділ з пристрою, що виділений для цієї мети (наприклад, з робочого диску). Таким чином, ієрархія пам'яті, що складається з М і робочого диску, автоматично управляється операційною системою, яка веде обмін інформацією між М і робочим диском без жодних вказівок з боку програміста. Дійсно, маючи справу з такими системами, програмісти пишуть свої програми в просторі адрес, не співпадаючому з простором фізичних адрес, тобто з М. Цей простір називається простором віртуальних адрес, або множиною адрес віртуальної пам'яті. Розмір віртуальної пам'яті одного завдання звичайно багато більше М (або області М, відведеної одному завданню). Таким чином, програмісту тільки зрідка доводиться піклуватися про пристосування завдань до наявного розміру пам'яті. Накладення віртуальних адрес на фізичні (у М або в робочому диску) виконується динамічно, посилання за посиланням, спеціальним апаратним механізмом.

Типовими пристроями введення-виведення діалогової ПРОП-системи є модеми або дисплеї. Користувачі вводять команди замість пропозицій мови управління завданнями і дані для системних програм або програм користувача, з якими вони взаємодіють. Ці програми повинні існувати в системі до того, як вони будуть названі командами користувача. Кожне повідомлення, введене користувачем, що складається з команди або даних, або з того і іншого, збирається символ за символом процесором Р4 в буфері усередині М. Коли поступає символ «кінець повідомлення», операційна система інтерпретує повідомлення і «активує» процес, з яким користувач бажає взаємодіяти. Звичайно цей процес містить велику частину своєї інформації на диску або на робочому диску. Активація процесу означає в даному випадку постановку його в чергу процесів, що чекають завантаження в пам'ять. У деякий момент інформація для процесу (програми і дані) завантажується повністю або частково в М, і як тільки процесор підключиться до нього, почнеться виконання процесу.

Користувач, що вводить «легку» команду (що вимагає малих ресурсів системи), чекає швидкої відповіді системи. Наприклад, команда редагування рядка повинна бути виконана найбільше за декількох секунд. Інакше увага користувача розсіюватиметься і взаємодія з системою стане обтяжливою і неефективною.

Проте деякі з команд, що підлягають обслуговуванню в даний момент часу, цілком можуть виявитися «важкими»; наприклад, деякі користувачі можуть замовити компіляцію, виконання довгої програми або маніпуляцію з великим файлом; тоді як інші просто виконують редагування, питають час дня або використовують систему як настільний калькулятор. Звичайно, для того, щоб запобігти дії важких запитів на час відповіді системи на легкі питання, використовується метод розділення часу. Цей метод полягає в обмеженні часу, на який центральний процесор передається даному процесу без перемикання на інші готові процеси. Очевидно, що центральний процесор перемикається, тільки якщо існує інший готовий процес. Максимальний час центрального процесора, який може бути наданий деякому процесу кожного разу при його включенні, називається квантом процесорного часу. Якщо виконання процесу не завершилося, коли закінчився квант, процес уривається і ставиться в чергу готових. Коли підходить його черга, процес одержує наступний квант і т.д. до його завершення. Відмітимо, що завершення в діалоговій системі звичайне означає, що процес вимагає нової команди або нових даних від користувача.

Діалогова система може бути однопрограмною або мультипрограмною. У першому випадку тільки один процес в даний момент часу знаходиться в основній пам'яті. Коли його час перевершує квант, процес розвантажується з пам'яті і у пам'ять завантажується інший процес, готовий до виконання. У разі мультипрограмування в пам'яті одночасно можуть знаходитися декілька процесів, і центральний процесор перемикається па готовий процес, якщо поточний процес блокує сам себе операцією введення-виведення. Якщо це термінальна операція введення-виведення (тобто процес нею закінчується) або квант вичерпаний, процес звичайно (але не завжди) розвантажується з пам'яті.

Ієрархія пам'яті навіть в діалоговій системі може управлятися уручну або, принаймні частково, автоматично. У останньому випадку для того, щоб процеси могли виконуватися, не обов'язково, щоб вони цілком завантажувалися в пам'ять або були належним чином розділені на сегменти. Інакше кажучи, діалогова система (однопрограмна або мультипрограмна) може надати кожному з своїх користувачів віртуальну пам'ять.

Три організаційні координати, відмічені в табл. 2.1, не залежні одна від іншої; будь-яка з восьми комбінацій напрямів (по трьох координатах) принципово можлива. У деяких системах обидва варіанти, вказані у табл. 2.1 для певної координати, співіснують. Наприклад, є багато операційних систем, що забезпечують пакетну обробку разом з діалоговою. Можливо також автоматичне управління частиною ієрархії пам'яті одночасно з ручним управлінням рештою частини.

Важливо відзначити, що мультипрограмування було введено в основному для збільшення кількості роботи, що виконується центральним процесором, - отже, для збільшення продуктивності системи, - і його наявність приховано від користувача. З іншого боку, метод розділення часу обгрунтовується міркуваннями швидкості відповіді на команди користувача. Більш того, користувач бачить мікроскопічну різницю між пакетною обробкою і діалоговим рахунком. Наявність віртуальної пам'яті також впливає на користувача, але не так глибоко і безпосередньо, як спосіб обробки.

3 Етапи роботи за оцінкою

Корисно розрізняти роботи за оцінкою продуктивності і безперервне спостереження за станом системи. Хоча обидва види діяльності обмежені за тривалістю, безперервне спостереження за станом звичайно виконується для значної частини часу існування працюючої системи.

Його метою є постійне спостереження за продуктивністю системи, щоб виявити проблеми продуктивності, як тільки вони виникнуть.

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

Рис. 2.3. Етапи роботи за оцінкою продуктивності

Етап I. Виникає необхідність проведення роботи.

Етап II. Формулюються цілі роботи.

Етап III. Готується план роботи.

Етап IV. План виконується.

Етап V. Інтерпретуються результати.

Зосередимося на дослідженнях з метою оцінки.

Види діяльності за оцінкою можуть бути згруповані в п'ять етапів, наочно представлених на блок-схемі рис. 2.3.

Рисунок 2.3 показує також деякі з можливих шляхів, які можуть бути пройдені в ході роботи за оцінкою.

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

Інше, можливо очевидне, але істотне зауваження полягає в тому, що важливо якомога ясніше визначити область дослідження і його мети перш, ніж буде зроблено що-небудь ще. Отже, ця специфікація повинна бути зроблена на етапі II. Ці цілі і, можливо, цілі, що виникають в ході дослідження, повинні служити орієнтиром для тих, що проводять оцінку впродовж всіх етапів і повторень роботи. Іншими словами, практична робота за оцінкою (на противагу теоретичному проекту оцінки продуктивності) повинна бути по можливості цілеспрямованою. Під час етапу II належить також вибрати відповідний набір індексів продуктивності.

Етапи III, IV, V можуть розглядатися як компоненти ітеративної процедури, що знаходиться в основі наукового методу: формулюється деяка гіпотеза, потім вона перевіряється, і якщо результат негативний, то модифікується. У оцінці продуктивності гіпотези не завжди перевіряються експериментально. Проте експериментальне підтвердження залишається найважливішим критерієм істинності. Слід також відмітити, що оцінювачі можуть формулювати гіпотези з великими шансами на успіх, якщо вони знають внутрішню організацію і поведінку системи. Не існує реальної заміни знанню, а підхід «чорного ящика» не завжди такий вже ефективний за вартістю. Чим глибше розуміння системи, тим, взагалі кажучи, дешевшим і швидшим виявиться дослідження. Іноді фахівець з системи може безпомилково відповісти на такі питання, які зажадали б від інших людей тривалих і дорогих досліджень.

Кожний з перерахованих вище етапів включає діяльність, направлену на накопичення інформації про систему, а саме:

читання керівництва по системі;

вивчення логічних діаграм, блок-схем, лістингів програм;

опитування операторів і іншого обслуговуючого персоналу;

бесіди з користувачами;

вимірювання параметрів робочого навантаження;

збір даних про використання системи;

інтерпретація облікових даних.

4 Індекси продуктивності

Розглянемо технічні індекси продуктивності. Ці індекси, якщо вони акуратно визначені, могли б бути об'єктивними засобами деяких аспектів продуктивності системи. Таким чином, суб'єктивність оцінки могла б бути в значній мірі обмежена їх вибором і відносною вагою, що додається їм. Вагові коефіцієнти будуть, взагалі кажучи, відрізнятися з погляду різних категорій людей (виробників, адміністрації установки, представників компанії, галузевих інженерів, системних програмістів, операторів, прикладних програмістів) і іноді від індивідуума до індивідуума.

Проте ряду важливих індексів продуктивності важко або неможливо надати кількісного вигляду, наприклад легкість користування системою, структурованість програми або мови, потужність набору команд. У цій роботі приймемо обмежене визначення продуктивності, яке пропонує індекси, що легко приймають кількісну форму. Тільки ефективність системи, її швидкість виконання даного завдання або набору завдань, швидкість відповіді на зовнішні сигнали розглядатимуться з аспектів широкого визначення продуктивності Таким чином, ми зарезервуємо термін продуктивність для цих аспектів і називатимемо інші (правильність, легкість використання, структурна, надійність і т. д.) функціональними аспектами.

Найбільш широко поширені класи кількісних індексів продуктивності для обчислювальних систем перераховані у табл. 2.2. Із загальних визначень, даних в тій же таблиці, має бути очевидно, що індекси продуктивності мають розмірність: об'єм*час, індекси реактивності — розмірність часу, а індекси використання безрозмірні. В даний час не існує стандартизованого єдиного способу вимірювання об'єму, або кількості інформації, переробленою системою.

Таблиця 2.2 Основні класи кількісних індексів продуктивності обчислювальних систем

Клас індексу	Приклади індексів	Загальне визначення
Продуктивність	Пропускна спроможність	Об'єм інформації, оброблюваною системою в одиницю часу
	Максимальне вироблення (максимум пропускної спроможності)
	Швидкість виконання команд
	Швидкість обробки даних
Реактивність	Час відповіді	Час між пред'явленням системі вхідних даних і появою відповідної вихідної інформації
	Час проходження
	Час реакції
Використання	Коефіцієнти використання	Відношення часу исполь зования вказаної частини системи (або її использо
	устаткування (центральний процесор, канал введення-виведення, пристрій введення-виведення)	вания для заданої мети) протягом заданого інтервалу часу до тривалості цього інтервалу
	Коефіцієнт використання операційної системи
	Коефіцієнт використання загального модуля програмного забезпечення (наприклад, компілятора)
	Коефіцієнт використання бази даних

Таким чином, залежно від системи і від її робочого навантаження використовуватимуться різні міри об'єму; серед найбільш поширених можна назвати: завдання, програма, процес, крок завдання, взаємодію (обмін повідомленнями). Перерахувати всі значення, приписані раніше і приписувані нині цим термінам в літературі по обчислювальних системах [7, 8, 9] неможливо. Тут відзначимо, що всі вони до деякої міри залежать від природи робочого навантаження, від мови, на якій програмісти описують свої алгоритми для обчислювальної машини, від внутрішньої мови машини і від способу організації системи. Таким чином, жоден з цих заходів не володіє властивістю незалежності від робочого навантаження і властивістю незалежності від системи — це дві властивості, необхідні для того, щоб можна було встановити деяку міру об'єму інформації як універсальної.

У наступному прикладі обговоримо вибір індексів продуктивності для діалогової системи.

Приклад 2.1. Діаграма на рис. 2.4 характеризує діалогову установку з погляду окремого користувача, що взаємодіє з системою через термінал.

Рис. 2.4. Визначення часу взаємодії і часу відповіді для діалогової системи

Відмітимо, що частина циклу взаємодії, протягом якої машина чекає повідомлення від терміналу, часто називається часом обдумування, навіть якщо вона включає також час введення і частину часу виведення. Для користувача найбільш важливим аспектом продуктивності (відповідно до нашого обмеженого визначення цього терміну) буде реактивність системи. Діаграма на рис. 2.4 дозволяє точно визначити індекс реактивності, званий часом відповіді. Наприклад, час відповіді буде визначено як інтервал між моментом, коли користувач набирає останній символ вхідного повідомлення, і моментом появи першого символу вихідного повідомлення на терміналі. Це тільки одне з декількох можливих визначень, які можна було б запропонувати. У деяких системах воно може опинитися навіть двозначним і потребує модифікації, принаймні в уточненні.

Важливо відзначити, що співвідношення між індексами продуктивності системи і цінністю (у економічному сенсі), приписаною їм людьми, що беруть участь в оцінці, не обов'язково є лінійним. Наприклад, ніяк не можна вважати вірним, що час відповіді 4 секунди на дане повідомлення приблизно удвічі менш бажано, ніж час відповіді 2 секунди на те ж повідомлення. Форма цієї залежності, яка міняється від користувача до користувача і від зміни типу повідомлення, швидше схожа на криву, зображену на рис. 2.5. Нижче певного порогу користувачі не в змозі навіть відчувати різницю в часі відповіді. Вище за інший поріг рівень задоволення різко падає, і переважає відчуття розчарування і безсилля.

Які параметри установки впливають на час відповіді? Час відповіді залежить від даного повідомлення, від системи і від решти частини робочого навантаження, яке обробляє система під час прийому повідомлення. Щоб користуватися часом відповіді як індексом продуктивності системи, ми повинні специфікувати повідомлення і решту частини робочого навантаження. Його значення не має сенсу без цієї додаткової інформації. Проте охарактеризувати робоче навантаження в достатньо компактному вигляді вельми важко. Поліпшення одного індексу не завжди покращує інші індекси, як показано в наступному прикладі.

Приклад 2.2. У діалоговій ПРОП-системі, розглянутій в прикладі 2.1, зменшимо квант часу з 2 одиниць часу до 1 одиниці. Нова часова діаграма зображена на рис. 2.6(b). Використовуючи ті ж самі індекси продуктивності, що і в прикладі 2.1, знайдемо, що середній час відповіді зменшується з 8.16 до 7.6 одиниці часу. Проте середня пропускна спроможність також падає з 0.447 до 0.422 взаємодії в одиницю часу. Відмітимо, що стандартне відхилення часу відповіді збільшується з 9.55 до 11.35 одиниці часу. Середній час відповіді для команд редагування убуває з 6.1 до 4.6 одиниці часу, тоді як для команд компіляції воно збільшується з 12.3 до 13.6 одиниці часу.

У роботі за оцінкою можна розглядати вторинні індекси продуктивності разом з первинними. Первинні індекси — це ті, якими дійсно цікавиться оцінювач. Специфікації продуктивності системи звичайно виражаються в термінах первинних індексів. Взагалі метою роботи за оцінкою на існуючій системі є поліпшення первинних індексів. Ці індекси змінюються залежно від типу системи, завдання і від оцінювача. Наприклад, для користувачів, як правило, первинний індекс — це індекс реактивності. З іншого боку, адміністрація установки звичайно зацікавлена в продуктивності разом з реактивністю. Залежно від обставин адміністратор приділятиме більше уваги то одному, то іншому показнику, але обидва типу індексів завжди гратимуть головну роль в оцінці системи адміністратором. Таким чином, навіть у тих роботах, цілі яких формулюються в термінах одного типу індексів, іншому типу завжди слід приділяти належну увагу.

Вторинні індекси звичайно висуваються в процесі самої роботи за оцінкою. Їх значення можуть бути корисні для виявлення симптомів неефективності або для знаходження причин цієї неефективності. Як приклад для ряду таких робіт можна назвати індекси коефіцієнта використання (табл. 2.2).

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

2.5 Класифікація робіт за оцінкою

Цілі роботи за оцінкою повинні бути ясно і чітко сформульовані на її початку на етапі, який був названий етапом II. Роботи за оцінкою можуть бути класифіковані за різними координатами відповідно до їх цілей. Можливо, найбільш поширеною є класифікація, відповідно до якої роботи діляться на наступні три категорії:

• роботи з вибору;

• роботи з удосконалення;

• роботи з проектування.

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

Роботи з вибору пов'язані з проблемами, що зустрічаються при проектуванні установки і при покупці системи. Ці проблеми включають вибір способу обробки, вибір системи, яка буде встановлена, з варіантів, запропонованих різними постачальниками, вибір мови для написання певної програми і вибір пакету системних програм. У цілому роботи з вибору можуть бути визначені як роботи, що здійснюються для визначення найбільш відповідної альтернативи для даного застосування серед різних доступних варіантів (наприклад, з наявних у продажу). Робота з вибору проводиться для досягнення певної мети за допомогою вибору існуючої системи, яка найбільш відповідає деяким певним критеріям вибору.

Роботи з удосконалення відносяться до модифікацій існуючих систем для поліпшення їх продуктивності або зниження ціни, або для того і іншого. Настройка системи, тобто підбір параметрів з метою пристосувати її до робочого навантаження установки, потрапляє в цю категорію робіт. Сюди входять також роботи, що призводять до розвитку системи, який полягає в заміні або додаванні одного або більше апаратних компонентів. Наприклад, система може розвиватися шляхом розширення основної пам'яті, додавання центрального процесора або заміни центрального процесора на швидший. До інших типів змін, які можуть розглядатися як модифікації системи, відносяться упорядкування інформації усередині одного з накопичувачів або серед декількох накопичувачів, і модифікація зв'язків між пристроями і процесорами введення-виведення. Роботи цього класу можуть бути названі оптимізаційними дослідженнями, якщо не надавати терміну оптимізація строгого математичного значення, яке в даному випадку виявиться таким, що дезорієнтує.

Мета робіт з проектування полягає у відповіді на питання, що виникають при розробці обчислювальних машин, їх компонентів, операційних систем, програм і мов. Ці дослідження зазвичай здійснюються тими, хто створює системи, а не її користувачами. Частини, з яких буде складена система, можуть існувати наперед чи ні. В останньому випадку вони будуть спроектовані і виготовлені відповідно до специфікацій, що диктуються розробником системи. При розробці обчислювальної системи її застосування часто визначаються ширше і більш розпливчато, чим в роботі по вибору. Наприклад, система може бути створена для комерційних застосувань (без подальшого уточнення цього поняття). Проте в процесі вибору ця система буде піддана випробуванню, заснованому на знанні (можливо, розпливчатому, але багато точнішому, ніж володів розробник) специфічних комерційних застосувань установки, для яких і проводиться вибір.

6 Огляд методів оцінки

Робота за оцінкою завжди направлена на отримання відповідей на питання про продуктивність даної системи. Щоб зробити це, оцінювач повинен одержати інформацію про продуктивність. Звичайно ця інформація складається із значень індексів продуктивності системи при заданому робочому навантаженні і при певних значеннях параметрів системи. Іншими словами, це інформація, одержана в результаті аналізу продуктивності. Методи, за допомогою яких може бути одержана ця інформація, мають назву методів оцінки. Відомі методи можуть бути класифіковані різними способами. Найпоширеніша класифікація, яка і буде прийнята в цій роботі, вводиться нижче.

Інформація про продуктивність, необхідна для дослідження, може бути одержана як від самої системи (методи вимірювання), так і від моделі системи (методи моделювання).

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

Модель може розглядатися як система. Різні моделі деякої системи відповідають різним способам ділення її на компоненти і описи взаємодії між компонентами або з середовищем системи. Можливість і зручність представлення системи багатьма різними способами не повинні дивувати; адже знання світу засноване на уявних моделях «систем» навколо нас (які включають інших людей і нас самих), а науковий прогрес може розглядатися як створення нових, кращих моделей світу. Описи ПРОП-системи, що надані в розд. 2.1, можуть розглядатися як словесні і до деякої міри поверхневі моделі ряду реальних систем. Ми називатимемо ці моделі, які існують в думках оцінювачів, концептуальними моделями.

Концептуальні моделі обчислювальних систем грають фундаментальну роль в оцінці продуктивності таких систем. Вони складаються зі всієї інформації, яку має в своєму розпорядженні оцінювач про їх структуру і поведінку. Ця інформація необхідна, або принаймні дуже корисна на всіх етапах роботи за оцінкою. Чим глибше наше знання системи, тобто чим краща наша концептуальна модель цієї системи, тим легше і успішніше може бути здійснено дослідження. Фахівці з системи часто можуть відповісти на такі питання за оцінкою продуктивності, які зажадали б тривалої і дорогої роботи; таким чином, іноді зручна концептуальна модель — все, що потрібне для роботи. Отже, концептуальні моделі є основою методів вимірювання і двох типів методів моделювання: імітації і аналітичних методів.

Дуже поширений і зручний опис поведінки системи (не тільки обчислювальної системи) грунтується на концепціях стану н переходу між станами. Стан системи у момент t визначається як безліч значень параметрів системи, що цікавлять нас, у момент t. Будь-яка зміна цих значень може розглядатися як перехід до іншого стану. Очевидно, що для будь-якої даної системи існує нескінченна безліч таких описів.

Цей опис, мабуть, залежить від вибору параметрів системи, що цікавлять нас.

Якщо поведінка моделі в часі в основному відтворює поведінку системи згідно деяким умовам відповідності між різними аспектами моделі і системи (зокрема, між станами і переходами), маємо імітаційну модель. Імітаційна модель працює «точно так, як і сама система»; спостерігається її поведінка в часі під зовнішньою дією, яка представляє середовище системи, і вимірюються індекси продуктивності. Таким чином, існує концептуальна подібність між імітацією і вимірюванням. Важливим наслідком цієї подібності є те, що проблеми, що виникають при плануванні вимірювальних експериментів, ідентичні або вельми схожі на проблеми, які доводиться вирішувати для імітаційних експериментів. Рішення, справедливі для одного типу експерименту, часто можуть бути застосовані до іншого експерименту.

З математичної точки зору імітаційна модель може розглядатися як така, що складається з рівнянь, які розв'язуються шляхом дослідження еволюції їх рішень на деякому відрізку часу. Обчислювальні системи звичайно розглядаються як дискретні системи (з дискретними станами), які змінюють свої стани за допомогою наказаних дискретних переходів, званих подіями. Таким чином, їх імітаційні моделі включатимуть рівняння, що виражають логічні умови, при яких виникають ці переходи. Рішення рівнянь методом імітаційного моделювання означає визначення хронологічної послідовності подій, що виникають в даній системі, і визначення відповідної послідовності станів системи. Цей метод рішення є, очевидно, чисельним.

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

Приклад 2.3. У прикладі 2.1 була використана украй проста імітаційна модель, одержана з концептуальної моделі діалогової ПРОП-системи. Значення двох індексів продуктивності t і Т обчислювалися за допомогою моделювання (олівцем на папері) обробки шести-командного робочого навантаження (рис. 2.6). Імітаційна модель, показана у вигляді блок-схеми на рис. 2.7, концептуально може трактуватися подібно до системи, яку вона замінює для цілей нашого дослідження. Це означає, що якщо ми забезпечимо цю модель відповідним представленням робочого навантаження, відповіді моделі відтворюватимуть відповіді реальної системи. Відповідна модель робочого навантаження тут складається з послідовності процесів, кожний з яких характеризується часом надходження і запитом на процесорний час. Відмітимемо, що відтворення поведінки системи залежатиме від точності моделей системи і робочого навантаження.

Аналітична модель цієї ж системи складається з набору математичних співвідношень, які можуть бути використані для обчислень (будь-яким методом, окрім імітації) значень наших індексів продуктивності по заданих значеннях параметрів системи і робочого навантаження.

Загальною проблемою всіх методів моделювання є проблема точності, тобто відповідності модельованій системі. Будь-яка аналітична або імітаційна модель повинна бути перевірена, перш ніж її можна буде використовувати для отримання інформації, потрібної для оцінки. Перевірка моделі часто важка, а іноді і неможлива. Вона може спиратися на попередні теоретичні результати або результати моделювання, але якщо модельована система існує, остаточне обгрунтування процедури вивіряння повинне бути емпіричним. Довіра до моделі може виходити з упевненості в її розумній концептуальній основі і з використання коректної процедури для її побудови. Проте немає кращого способу (можливо, ніякого іншого способу) підтвердження упевненості, ніж експеримент. Таким чином, у деякому розумінні, вимірювання є найбільш важливий метод оцінки, оскільки його потребують інші методи. Проте він не може бути використаний, якщо система не існує або недоступна, наприклад на початку проектування. У цих випадках, оскільки правильність моделі не може бути встановлена емпірично, наша віра в модель повинна грунтуватися на довірі до правильності її початкових концепцій і конструкції.

Рис. 2.7. Представлення імітаційної моделі у вигляді блок-схеми

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

Типовими пристроями введення-виведення системи пакетної обробки (у тому числі і конфігурації ПРОП) є пристрої читання з магнітної стрічки і пристрої друку. Користувачі пред'являють свої завдання (програми і дані) оформленими на магнітній стрічці. Файли читаються пристроєм читання записів, і після перетворення кодів їх вміст переноситься в буферну область в основній пам'яті М через Р4. Коли буфер наповниться, його вміст переноситься на диск через Р3.

На диску завдання чекають своєї черги на завантаження в пам'ять. Як тільки завдання завантажене через Р3, воно може оброблятися центральним процесором P1. Під час виконання завдання буде вимагати інформацію, розташовану на магнітній стрічці або на диску. Операційна система, розташована в пам'яті М (хоча б частково), піклуватиметься про обміни. Завдання також генеруватиме вихідне повідомлення для користувача, яке накопичується на диску, а в кінці виконання завдання друкується, проходячи через Р3, М і Р4. Користувачі системи пакетної обробки повідомляють операційній системі свої запити ресурсів на мові управління завданнями за допомогою колоди карт завдання. У одному завданні, тобто в одній і тій же колоді, може задаватися послідовне виконання декількох кроків завдання. Крок завдання є етап виконання завдання, логічно відмінний від інших і явно специфікований пропозицією мови управління завданнями. Типові кроки завдання: компіляція, виконання програми, копіювання файлу з диска на барабан або, навпаки, друк вмісту файлу. Коли крок завдання закінчується, відведена йому область пам'яті звільняється, а наступний крок того ж завдання додається до списку кроків, що чекають завантаження в М.

Якщо всі процесори на рис. 2.2 насправді представляють один і той же фізичний процесор, скажімо Р*, то поєднання в часі неможливе. У той час коли Р* діє як Р4, він не може діяти як Р1, Р2 або Р3. У цьому випадку завдання виконуються строго послідовно; було б незручно починати виконання нового завдання, перш ніж завершиться попереднє. Таку організацію, в якій не допускається поєднання, слід було б назвати чисто однопрограмною.

СТРУКТУРА МОДЕЛІ

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

Вихідна модель розглянута в роботі Мак-Дугалла [ ].

1 Опис моделі

Приклад 3.1. Потрібно побудувати просту модель ПРОП-системи пакетної обробки. Головна мета цієї роботи полягає в прогнозуванні зміни продуктивності устаткування на середню пропускну спроможність системи і середній час проходження завдання.

З периферійних пристроїв розглядатимемо пристрій читання записів з магнітної стрічки ПЧ і пристрій друку ПД. Обидва пристрої управляються процесором Р4, причому вважається, що він не створює конфліктів між ними. Іншими словами, ситуація така, неначе ПЧ і ПД управляються двома контроллерами.

Завдання складається з ряду кроків:

• компіляція;

• виконання;

• друк файлу записів.

Програма і дані для завдання читаються пристроєм читання записів на магнітній стрічці ПЧ і через вхідний буфер в пам'яті М переносяться на диск.

Якщо розмір пам'яті достатній, інформація для першого кроку завдання просто поміщується в пам'ять і чекає центрального процесора.

Коли наступає її черга, вона обробляється до тих пір, поки не видасть запиту на робочий диск Диск2 або на системний диск.

Тоді як завдання чекає задоволення свого запиту, центральний процесор обробляє, якщо вони є, інші завдання, готові до роботи.

Коли запит до магнітної стрічки задоволений, завдання знов починає чекати центральний процесор у відповідній черзі.

Коли запит на диск задоволений, завдання знову поступає в чергу до центрального процесора, якщо тільки не завершився поточний крок цього завдання. У останньому випадку завдання розвантажується з пам'яті і, якщо є наступний крок, стає в чергу до пам'яті.

Слід зазначити, що завдання ніколи не розвантажуються з пам'яті під час кроку завдання. Їх вихідні повідомлення накопичуються на диску і врешті-решт поступають на друк ПД через виділений вихідний буфер в пам'яті М. Простір, зайнятий ними в М, звільняється тільки після закінчення кроку завдання.

Диск використовується для програм, їх вхідних даних і вихідних повідомлень кроків завдання. Робочий диск містить нерезидентну частину операційної системи, бібліотеку загальних програм і підпрограм, а також особисті файли.

Передбачається, що компілятор весь час знаходиться в основній пам'яті. Для зручності викладу із самого початку нехтуватимемо впливом спотворень в пам'яті і накладних витрат операційної системи на індекси продуктивності системи.

Зміна продуктивності компоненту устаткування впливає на якийсь час, що витрачається завданням на роботу з цим компонентом. Розглядатимемо компоненти устаткування як ресурси системи. Деякі ресурси, наприклад Рь Р2, Р3, ПЧ і ПД, не можна експлуатувати в режимі розділення часу. Їх можна використовувати тільки в одному завданні в даний момент часу. Інші можна розділяти між декількома завданнями. Наприклад, Р4 може спільно використовуватися завданням, яке читається з магнітної стрічки, і завданням, результати якого виводяться на друк. Аналогічно, простір в пам'яті М може використовуватися декількома завданнями одночасно. Завдання може (або повинно) використовувати в кожен момент часу більш ніж один ресурс, наприклад центральний процесор і основну пам'ять.

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

Таким чином, ресурси, які перераховані вище, можна звести до зображених на рис. 3.1

Рис. 3.1. Ресурси і шляхи проходження завдань в ПРОП-системі пакетної обробки

Оскільки вхідний і вихідний буфери можна об'єднати з ПЧ і ПД відповідно, наша модель матиме справу явно з наступними шістьма ресурсами: ЦП, М, Робочий диск (ДИСК2), Системний диск (ДИСК), ПЧ (пристрій читання з магнітної стрічки) і ПД.

Для кожної пари «завдання — ресурс» ми хочемо визначити, як довго завдання J використовує ресурс R. Іншими словами, потрібно визначити інтервал часу між моментом, коли завданню J призначений ресурс R, і моментом, коли завдання J звільняє ресурс R.

Проте перш, ніж ресурс R буде призначений, він повинен бути зажаданим завданням J, яке в загальному випадку повинне чекати в черзі виконання свого замовлення.

Таким чином, маємо ситуацію, зображену на рис. 3.2, a, де три введені класи подій (запит, призначення, звільнення) представлені прямокутниками, а послідовність дій між ними — стрілками.

Написи на стрілках відносяться до діяльності, що виконується завданням між попереднім і подальшим подіями.

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

3.2. Організація моделі системи

Модель цієї системи може бути організована відповідно до наступних двох принципів:

будується і безперервно підтримується хронологічно упорядкований список подій;

існує програма обробки події для кожного типу події (ця програма викликається, як тільки подія цього типа виявиться черговою в списку подій).

Таким чином, для кожного ресурсу R в цій системі повинні існувати три програми:

R_ ЗАПИТ

R_ ПРИЗНАЧЕННЯ

R_ЗВІЛЬНЕННЯ.

Ці програми одержують ім'я завдання J як аргумент і можуть виконувати наступні завдання:

Завдання R_ЗАПИТ(J): якщо ресурс R можна негайно призначити завданню J

тоді створити подію «призначити ресурс R завданню J» і змінити стан R

інакше поставити завдання J в чергу до відповідного ресурсу R.

Завдання R _ ПРИЗНАЧЕННЯ (J): планувати наступну подію для завдання J (яке не обов'язково буде подією «звільнення R»).

Завдання R_ЗВІЛЬНЕННЯ (J):

модифікувати стан ресурсу R;

планувати наступну подію для завдання J;

якщо ресурс R можна негайно призначити завданню К, що в черзі до ресурсу R

то планувати подію «призначити ресурс R завданню К» і виключити завдання з черги до ресурсу R;

інакше нічого не робити.

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

Легко бачити, що програма R.ПРИЗНАЧЕННЯ (J) може бути об'єднана з програмою R.ЗАПИТ(J), як показано на рис. 3.2, б, за умови, що основні операції визначених вище програм модифіковані, наприклад, таким чином:

R-ЗАПИТ/ПРИЗН (J): якщо ресурс R можна негайно призначити завданню J

то змінити стан ресурсу R і планувати наступну подію для завдання J;

інакше поставити запит від завдання J в чергу до ресурсу R;

R_ЗВІЛЬНЕННЯ (J):

змінити стан ресурсу R;

планувати наступну подію для завдання J;

якщо черга до ресурсу R не порожня

то планувати подію «запит/призначення ресурсу R завданню К» і прибрати завдання з черги до ресурсу R;

інакше нічого не робити.

Рис. 3.2. Типи подій в завданнях і типи дій, що відносяться до ресурсу R

Слід відмітити, що в цій схемі постановка в чергу до ресурсу R проводиться програмою R _ЗАПИТ/ПРИЗН (J), а виключення − програмою R-ЗВІЛЬНЕННЯ (J).

Стратегії планування і призначення ресурсу R здійснюються програмою R_.ЗВІЛЬНЕННЯ (J).

Коли ця програма вибирає завдання для негайного призначення ресурсу R, потрібна гарантія від повторного приміщення в чергу цього ж завдання програмою R. ЗВІЛЬНЕННЯ. Таку гарантію можна одержати, наприклад, помітивши особливим чином ім'я завдання (К), яке передається програмі R_3AПP/HA3H.

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

Щоб відповісти на це питання, ми повинні детальніше визначити шлях, прохідний завданням через нашу систему. Для цієї мети необхідно додати до типів подій, зображених на рис. 3.2, б, ще два: події надходження і відхід.

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

Якщо ми розглянемо всю систему як єдиний ресурс, то побачимо, що цей ресурс негайно призначається будь-якому завданню, що поступає, незалежно від відходу завдань (відмітимо, що це не так для чисто діалогової системи).

Таким чином програма НАДХОДЖЕННЯ повинна планувати появу наступного завдання, а програма ВІДХІД виявляється набагато простішою за програму ЗВІЛЬНЕННЯ.

Два важливі зауваження.

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

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

Завдання НАДХОДЖЕННЯ (J):

готує характеристику завдання J;

планує наступну подію для J;

планує прибуття наступного завдання, скажемо К;

ВІДХІД(J): знищує характеристику J.

Тепер можна побудувати те, що назвемо картою подій нашої системи. Ця карта, показана на рис. 3.3, відображає шлях завдання через систему, яку ми хочемо моделювати. Деякі припущення щодо поведінки системи були згадані вище, але легко можуть бути одержані з карти.

Рис. 3.3. Карта подій ПРОП-системи

(написи біля стрілок описують дії; написи у фігурних дужках містять умови, при яких виконується дана дія)

На карті подій, зображеній на рис. 3.3, є 20 прямокутників, які відповідають подіям. Чотирнадцять прямокутників (по два на кожний з шести ресурсів плюс «надходження» і «відхід») відповідають різним типам подій.

Модель формулюється на 14 програмах, що оброблюють ці типи подій.

Програми можна організувати згідно блок-схемі рис. 3.2.

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

Програма управління моделлю (ПУМ) виконує два основні завдання, а саме:

вибрати наступну подію і викликати відповідну програму обробки події;

перевести годинник моделі, який вимірює час моделі.

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

Кожен запис в списку містить тип події, який використовується для виклику відповідної програми обробки події (наприклад, ЦП-.ЗВІЛЬНЕННЯ), ім'я завдання, яке потрібно передати як аргумент програмі обробки події, а також час події, яка повинна бути завантажена в годинник моделі програмою управління моделлю.

Момент виникнення події визначається програмою обробки події, яка його генерує. Наприклад, програма ЦП_ЗАПИТ/ /ПРИЗН (J) в деяких випадках обчислює момент часу моделі, коли буде припинене виконання завдання J із-за запиту на системний диск або робочий диск (закінчення кроку завдання викликає запит системного диска). Це обчислення засноване на поточному значенні часу моделі і на тривалості наступного обчисленого інтервалу для завдання J, який можна одержати з опису завдання.

McDougall M.H. 1970 Computer system simulation: An introduction. Comp. Surveys 2, 3 (Sept), 191-209

http://dl.acm.org/citation.cfm?id=802498

Дата добавления: 2015-10-21