Теорія операційної системи

:: Меню ::

Головна
Представлення даних в обчислювальних системах
Машинні мови
Завантаження програм
Управління оперативною пам'яттю
Сегментна і сторінкова віртуальна пам'ять
Комп'ютер і зовнішні події
Паралелізм з точки зору програміста
Реалізація багатозадачності на однопроцесорних комп'ютерах  
Зовнішні пристрої
Драйвери зовнішніх пристроїв
Файлові системи
Безпека
Огляд архітектури сучасних ОС

:: Друзі ::

Карта сайту
 

:: Статистика ::

 

 

 

 

 

ДИВАН58 - купить диваны в пензе по не дорогой цене | система пылеподавления на дорогах в Ялте

Дисковий кеш

Функції і принципи роботи дискового кеша істотно відрізняються від спільних алгоритмів кешування, що обговорювалися в разд. Сторінковий обмін. Річ у тому, що характер звернення до файлів зазвичай істотно відрізняється від звернень до областей коди і даних завдання. Наприклад, компілятор З і макропроцесор ТИХ розглядають вхідні і вихідні файли як потоки дані. Вхідні файли прочитуються строго послідовно і повністю, від початку до кінця. Аналогічно, вихідні файли повністю перезаписуються, і перезапис теж відбувається строго послідовно. Спроба виділити аналог робочої області при такому характері звернень приречена на провал незалежно від алгоритму, хіба що робочою областю вважатимуться всі вхідні і вихідні файли.
Проте кешування або, точніше, буферизація даних при роботі з диском має сенс і у багатьох випадках може приводити до значного підвищення продуктивності системи. Якщо відсортувати механізми підвищення продуктивності в порядку їх важливості, ми отримаємо наступний список.

  1. 1. Розміщення в пам'яті структур файлової системи — каталогів, FAT плі таблиці інодов (ці поняття детальніше обговорюються в главі І) і так далі Це основне джерело підвищення продуктивності при використанні дискових кешів під Ms/dr DOS.
  2. 2. Відкладений запис. Само по собі відкладання запису не підвищує швидкості обміну з диском, але дозволяє більш рівномірно розподілити за часом завантаження дискового контроллера.
  3. 3 Угрупування запитів на запис. Система має пул буферів відкладеного запису, який і називається дисковим кешем. Під час вступу запиту на запис, система виділяє буфер з цього пулу і ставить його в чергу до драйвера. Якщо за час знаходження буфера в черзі в те ж місце на диску буде проведений ще один запис, система може дописати дані в наявний буфер замість установки в чергу другого запиту. Це значно підвищує швидкість, якщо запис відбувається масивами, не кратними розміру фізичного блоку на диску.
  4. 4 Власне кешування. Після того, як драйвер виконав запит, буфер не відразу використовується повторно, тому деякий час він містить копію записаних або прочитаних даних. Якщо за цей час станеться звернення на читання відповідної області диска, система може віддати вміст буфера замість фізичного читання.
  5. 5. Випереджаюче прочитування. При послідовному зверненні до даних читання з якого-небудь блоку значно підвищує вірогідність того, що наступний блок також буде лічений. Теоретично випереджаюче читання повинне мати той же ефект, що і відкладений запис, тобто забезпечувати більш рівномірне завантаження дискового каналу і його роботу паралельно з центральним процесором. На практиці, проте, часто виявляється, що лічений з випередженням блок виявляється нікому не потрібний, тому ефективність такого читання помітно нижче, ніж у відкладеного запису.
  6. 6. Сортування запитів по номеру блоку на диску. Вірогідно, таке сортування повинне приводити до зменшення часу позиціювання голівок чтенія/запіси (див. разд. Продуктивність жорстких дисків). Крім того, якщо черга запитів буде відсортована, це полегшить роботу алгоритмам кешування, які проводять пошук буферів по номеру блоку.


Кешування значно підвищує продуктивність дискової підсистеми, але створює ряд проблем, причому деякі з них досить неприємної властивості.
Перша з проблем — та ж, що і у відкладеного запису. При використанні відкладеного запису програма не знає, чи успішно завершився фізичний запис. При роботі з дисками одне з основних джерел помилок — фізичні помилки диска. Проте багато сучасних файлових систем підтримують так званий hotfixing (гаряче лагодження) — механізм, що забезпечує динамічну заміну "поганих" логічних блоків на "хороших", що значною мірою компенсує цю проблему.
Друга проблема набагато серйозніше і теж властива всім механізмам відкладеного запису: якщо в проміжку між запитом і фізичним записом станеться збій всієї системи, то дані будуть втрачені. Наприклад, користувач зберігає відредагований файл і. не діждавшись закінчення фізичного запису, вимикає живлення — вміст файлу виявляється втрачений або пошкоджено. Інша ситуація, до болю знайома всім користувачам Dos/windows З.х/windows 95: користувач зберігає файт і в цей час система зависає — результат той же. Аналогічного результату можна досягти, не вчасно діставши дискету або інший носите-ц, що видаляється, з приводу (щоб уникнути цього, механіка багатьох сучасних дисководів дозволяє програмно заблокувати носій в приводі).
Дуже забавно спостерігати, як користувач, хоч би раз неприємний досвід спілкування, що мав, з дисковим кешем SMARTDRV, копіює дані з чужого комп'ютера на дискету. Перед тим, як витягувати її з дисковода, він озирається на господаря машини і з побоюванням запитує: "У тебе там жодних кешів немає?". У епоху MS DOS авторам доводилося спостерігати таку поведінку в декількох десятків людей.
Якщо відкладається запис не лише призначених для користувача даних, але і модифікованих структур файлової системи, ситуація ще гірша: системний збій може привести не лише до втрати даних, що знаходилися в кеші, але і до руйнування файлової системи, тобто у гіршому разі, до втрати всіх даних на диску.
Методи забезпечення цілісності даних при системному збої детальніше обговорюються в разд. Стійкість ФС до збоїв. Що знаходилися в кеші дані при фатальному збої гинуть завжди, але існують способи ізбежать.поврежденія системних структур даних на диску без відмови від використання відкладеного запису.
Третя проблема, пов'язана з дисковим кешем, — це виділення пам'яті під нього. Зменшення кеша призводить до зниження продуктивності дискової підсистеми, збільшення ж кеша віднімає пам'ять в призначених для користувача процесів. У системах з віртуальною пам'яттю це може привести до збільшення дискової активності за рахунок збільшення об'єму підкочування, що веде до зниження як дискової, так і спільної продуктивності системи. Перед адміністратором системи встає нетривіальне завдання: знайти точку оптимуму. Положення цієї крапки залежить від наступних параметрів:

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

При цьому залежність кількості сторінкових відмов від об'єму пам'яті, доступної додаткам, має істотно нелінійний вигляд. Це ж твердження справедливе для зв'язку між розміром дискового кеша і відповідною економією звернень до диска. Таким чином, завдання підбору оптимального розміру кеша — це завдання нелінійної оптимізації. Найнеприємніше, що ключовий вихідний параметр — характер звернень до диска — не кількісний, а якісний; точніше сказати, його можна виміряти лише за допомогою дуже великого числа незалежних кількісних параметрів.
У багатьох ситуаціях неможливо теоретично оцінити положення оптимальної крапки, і єдиним способом виявляється експеримент: прогін типовою для даної машини суміші завдань при різних об'ємах кеша. При цьому потрібно мати можливість розрізняти дискову активність, пов'язану із зверненнями до файлів і із сторінковим обміном. Більшість сучасних ОС надають для цієї мети різні інструменти системного моніторингу. Чаші, проте, об'єм кеша виставляється на око, а до додаткового налаштування удаються, лише якщо продуктивність виявляється дуже низькою.
Виникає цілком природне бажання покласти підбір розміру кеша на саму систему, тобто міняти розмір кеша динамічно залежно від робочого навантаження. Окрім спрощення роботи адміністратора, таке рішення має ще одна велика перевага: система починає "автомагичеськи" підстроюватися під зміни навантаження.
Але далеко не все так просто. Якщо об'єм пам'яті в системі перевершує потреби прикладних програм, то динамічний дисковий кеш може формуватися за дуже простим "залишковим" принципом — все, що не згодилося додаткам, віддається під кеш. Проте оперативна пам'ять до цих пір відносно дорога і є дефіцитним ресурсом, тому найбільший практичний інтерес представляє ситуація, коли пам'яті не вистачає навіть додаткам, не говорячи вже про кеш. Проте і в цій ситуації кеш деякого об'єму буває потрібний.
Розумною політикою було б підстроювання кеша залежно від кількості сторінкових відмов: якщо число відмов стає дуже великим, система зменшує кеш; якщо ж число відмов мале, а йдуть інтенсивні звернення до диска, система збільшує кеш. Виходить саморегульована система з негативним зворотним зв'язком. Проте, якщо вдуматися, то видно, що замість однієї довільної змінної (об'єму статичного кеша) ми вимушені ввести як мінімум три:

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

На практиці, часто також вводяться параметри, що обмежують мінімальний і максимальний розміри кеша.
Оптимальні значення цих змінних залежать практично від тих же самих параметрів, що і об'єм статичного кеша, але підбір значень експериментальним дорогою виявляється значно складнішим, бо замість одновимірної нелінійної оптимізації ми вимушені займати тривимірною нелінійною оптимізацією.
Крім того, читач, знайомий з теорією управління, повинен знати чт невдалий підбір параметрів в системи з негативною зворотною зв'язок може приводити до коливального процесу замість саморегуляції, в дм куссиях USENET news приводилися приклади розвитку таких коливань динамічному кеші системи Windows NT при компіляції великого проекту в умовах недоліку пам'яті.
Цілком можливо, що низька продуктивність Windows Nt/2000/xp на машинах з невеликою кількістю пам'яті пояснюється зовсім не низькою якістю реалізації і навіть не секретною змовою між фірмою Microsoft і виробниками оперативної пам'яті, а просто погано збалансованим динамічним кешем.

 

:: Реклама ::

 

:: Посилання ::


 

 

 


Copyright © Kivik, 2017