Вплив величини кванта часу операційної системи на продуктивність СУБДOracle -
к.ф.-.м.н. Ю.Пудовченко, "Відкриті Технології"
Планувальник операційної системи (scheduler) відповідає за черговість виконання процесів у системі та розмір виділеної ним частки процесорного часу. Час процесів виділяється квантами. Після закінчення кванта користувальницький процес знімається з процесора, і процесорі запускається наступний по черзі процес. Цей механізм називається перемиканням контексту.
У різних ОС величина кванта часу значно відрізняється. Наприклад:
• у ОС Solaris для стандартної диспетчерської таблиці квант зменшується з 200 мс до 20мс і зазвичай коливається між 20 та 40 мс.;
• у ОС HP-UX 11.11, 11.23, 11.31 квант дорівнює 10 мс;
• у ОС Linux2.6 величина кванта становить 200 мс і динамічно змінюється у процесі виконання.
На перемикання контексту потрібен час, треба зберегти ресурси – регістри одного процесу (зберегти його контекст), а черговий процес завантажити на процесор. Мінімальна величина кванта означає, що операційна система часто знімає процеси з процесора, великий квант - рідше. Негативною стороною частого перемикання контексту є те, що операційна система виконує багато непотрібної роботи, занадто часто знімаючи процеси користувача з процесора, а потім повертаючи їх назад.
Ще один негативний момент полягає в тому, що кожен із процесів у ході своєї роботи набирає в кеш процесора необхідні йому дані. Новому, завантаженому процесу потрібні його власні дані. Тому перемикання контексту вважається тяжкою операцією.
Таким чином, ідея цього дослідження досить проста: якщо користувачам процесам дати можливістьпрацювати довше, то вони завершуватимуться швидше.
Виконуючи це дослідження, мені хотілося чисельно оцінити отримуваний виграш для того, щоб уточнити роль і місце цього методу серед решти наявних у нашому розпорядженні способів оптимізації систем обмежених ЦПУ.
Наші експерименти проводилися для квантів у 10мс, 20мс, 340мс та 400 мс:
• 10мс – для імітації виконання процесів на HP-UX, та й просто для порівняння та вивчення тенденції;
• 20мс – стандартний квант в ОС Solaris 8,9,10;
• 340мс – квант диспетчерської таблиці для популярних серверів Fujitsu Siemens PRIMEPOWER;
• 400мс – був обраний для порівняння та вивчення тенденції.
Експеримент проводився на SunFire V240: 2 ЦПУ Ultra-SPARC-IIIi по 1500МГц, 8Гб ВП, Oracle 10.2.0.3 64-bit.
У базі даних було створено невелику програму, що інтенсивно споживає час ЦПУ:
CREATE OR REPLACE FUNCTION double (n NUMBER)
RETURN NUMBER IS
FOR f IN 1..n LOOP
2 for i in 1..256 loop
3 insert в test values(i,"1","2");
4 insert в test values(513-i,"1","2");
PL/SQL процедура успішно здійснена.
Потім на рівні ОС встановлювалося одне із значень кванта - 10, 20, 340 або 400. Вимір тривалості виконання процедури виконувався наступним запитом:
bash-3.00$ cat sql.sql
set feedback off
set heading off
SELECT double (10000000) FROM dual
Методика першого експерименту
Для першої серії експериментів у системі створюється велика частота перемикання контекстів (одночасно в БД запускаються кілька тривалих сесій) і на їх тлі вивчається тривалість виконання деякої обраної сесії користувача:
bash-3.00$ cat sql.sh
/ooo/ora102/bin/sqlplus -s "/as sysdba" @/ooo/sql/sql.sql
В результаті запуску 10 сесій на двох процесорах ми отримуємо по 5 пар активних сесія/процесор. Швидкість роботи програми вимірювалася командою time за тривалістю останньої сесії. Для останньої сесії виходило два значення - одне виведене командою "set timing on" з SQLplus, а друге - командою time. Для решти 9 сесій виходило значення з sqlplus. Потім для всіх 10 сесій за значеннями sqlplus вважалося середнє Ave10. В результаті експерименту виходило три значення – два для однієї останньої сесії та Ave10 для всіх 10 сесій.
Розмір кванта Q
Context switches/s
Час виконання одного
Середнє по 10 сесіям
Різниця в секундах
Внаслідок збільшення величини кванта з 20 до 400мс отримано 13% приросту продуктивності (таблиця 1), а саме:
• за даними SQLPLUS тривалість однієї (останньої) сесії знизилася на 13% (з 132,4 сек. до 118,14 сек., Стовпець Sqlplus (s));
• за даними команди time тривалість сесії знизилася на 8% (зі 134 сек. до 124,08 сек., стовпець real (s));
• середня тривалість 10 сесій для сесію знизилася на 9% (з 133,3сек до 122,13 сек);
• кількість перемикань контексту/сек знизилася на 55% (з 262/с до 116/с).
За даними vmstat завантаження процесорів на всьому протязі експерименту знаходилося на рівні 100%, runqueue = 8 (два процеси на процесорах + 8 процесів стояли в черзі).
Цікавий факт, що зі збільшенням кванта зростає розкид тривалості сесій, тобто. різниця між мінімальною та максимальною тривалістю сесій. Максимальна різниця сягає 24 секунд. Для невеликих квантів тривалість сесій набагато "кучна", тобто. розкид значень щодо абсолютноївеличині набагато менше.
Заради експерименту було вирішено запустити 30 одночасних сесій. В результаті виконання скрипту start.sh отримано 30 значень, які були підсумовані та поділені на 30 (тобто отримано середнє арифметичне значення). Для 30 одночасних активних сесій у БД (15 сесій/процесор) результати ще більш вражаючими:
• sqlplus показує зменшення тривалості кожної сесії приблизно на 21%;
• time показує зменшення тривалості кожної сесії загалом на 16%;
• середня довжина сесії Ave30 знизилася на 20%;
• зріс розкид значень Delta збільшився. Проте, якщо співвіднести Delta до величини кванта Delta/quant, виходить майже константа. Таким чином, планувальник ОС не помиляється у плануванні, як це могло здатися.
Розмір кванта Q
Context switches/s
Час виконання одного
Середнє по 30 сесіям
У попередньому експерименті використовувалися виключно регістри процесора, і результати стосуються приросту продуктивності на регістрових (математичних) операціях. Проте, цікаво розглянути вплив величини кванта продуктивність операцій із пам'яттю - тобто. читання даних із кеша блоків. В даному випадку вивчалася поведінка саме операцій SELECT з таких причин:
• їх можна запускати паралельно у будь-якій кількості, і вони не будуть блокувати один одного, тобто. на перший план виходять простота та наочність експерименту;
• близько 80% виконуваних SQL-виразів у БД – це SELECT;
• в даному експерименті хотілося уникнути операцій введення-виведення, які вносять свої поправки до результату.
Для нового експерименту в БД було створено тестову таблицю розміром 46Мб: create table test as select * from dba_sources; Параметрdb_cache_size було встановлено в 180Мб.
Функція в БД була змінена так:
CREATE OR REPLACE FUNCTION test_select RETURN
for f in 1..25 LOOP
FOR rec IN (select * from test) LOOP
Детальна таблиця для однієї та десяти одночасних сесій:
Детальна таблиця для 30 одночасних сесій:
Оскільки тенденція зменшення часу намітилася досить явна, то цікаво ще глибше проміряти продуктивність для 1, 5, 10 і 15 сесій/процесор. Ось що вийшло:
Наступна таблиця отримано з попередньої показує зменшення середньої тривалості однієї сесії, тобто. значення для 5 сесій ділилося на 5 (173,12/5=34,624), значення 10 сесій ділилося на 10 (346,68/10=34,67) і т.д.
збільшення кванта з 20мс до 400мс позитивно позначається на продуктивності СУБД Oracle. Відчутний результат близько 20% помітний лише у періоди пікових навантажень і справедливий для 100% завантажених серверів. (Оскільки значення 15 активних сесій на процесор досить незвично, такий сервер можна класифікувати не просто "навантажений", а скоріше як "супер-перевантажений". Раніше цей ефект не був виявлений, мабуть тому, що вважається, що 15 одночасно активних сесій/ процесор – це надто багато). На серверах як із невеликим числом так і з великим числом ЦПУ можна отримати користь від цієї технології;
• виграш у часі пропорційний числу одночасно активних сесій та величині кванта. Стандартні значення кванта для операційних систем вибрано для задоволення інтерактивних додатків, і їх кількість у середовищі СУБД Oracle можна значно збільшувати. Очевидно, найбільшої користі від цього результату буде досягнуто на базах даних типу DSS і DataWarehouse;
• виявленийефект відкриває нові можливості для розробників;
• якщо завдання допускає розпаралелювання, то його слід максимально розпаралелити і запустити всі паралельні процеси одночасно. При великому кванті велика "пачка" процесів буде виконана швидше, ніж при малому кванті, або при послідовному виконанні. (Не бентежтеся тим, що завантаження ЦПУ досягне або навіть перевищить 100% ;-)) ).
• на інтерактивних додатках можливий негативний результат внаслідок уповільненої реакції системи при великій величині кванта, але в наших вимірах не вдалося зафіксувати погіршення продуктивності;
• величина кванта безпосередньо відбиває протиріччя між " інтерактивністю " і " пакетністю " ОС. Мала величина кванта корисна для інтерактивних додатків, тому що це дає можливість процесу швидко отримати процесорний ресурс і виконати деяку невелику дію, наприклад обробити переривання від натискання клавіші на клавіатурі. Системи з великими квантами більшінертні,в них більш помітна затримка між дією користувача та реакцією системи. Інертність системи зменшується зі зростанням кількості ядер, а інтерактивність зростає.
Необхідні умови для отримання ефекту від збільшення кванта:
• у системі має спостерігатися висока частота перемикання контексту, що виникає за високої завантаженості ЦПУ (100% або близької до 100%);
• сесії користувача повинні проводити на процесорі більшу частину свого часу, я б сказав не менше 80%. Враховуючи різкий сплеск у найближчі 2-3 роки числа ядер у процесорах, ризикну припустити збільшення у кілька разів величини кванта практично для всіх ОС у найближчі 5 років.