Влияние на размера на времевия квант на операционната система върху производителността на СУБДOracle-

Доцент доктор Ю. Пудовченко, "Отворени технологии"

Планировчикът на операционната система (планировчик) отговаря за реда на изпълнение на процесите в системата и размера на разпределения за тях дял от процесорното време. На процесите се разпределя време в кванти. В края на кванта потребителският процес се премахва от процесора и следващият процес се стартира на процесора. Този механизъм се нарича контекстно превключване.

В различните операционни системи стойността на кванта на времето варира значително. Например:

• в Solaris OS, за стандартната диспечерска таблица, квантът намалява от 200 ms на 20 ms и обикновено варира между 20 и 40 ms.;

• в OS HP-UX 11.11, 11.23, 11.31 квантът е 10 ms;

• в OS Linux2.6 квантовата стойност е 200 ms и се променя динамично по време на изпълнение.

Отнема време за превключване на контекста, необходимо е да се спестят ресурси - регистрите на един процес (запазете неговия контекст) и да заредите следващия процес в процесора. Малка квантова стойност означава, че операционната система често премахва процеси от процесора, голяма квантова - по-рядко. Недостатъкът на честите превключвания на контекст е, че операционната система върши много ненужна работа, като премахва потребителските процеси от процесора твърде често и след това ги връща обратно.

Друг негативен момент е, че всеки от процесите в процеса на своята работа събира необходимите данни в кеша на процесора. Новият, новозареден процес се нуждае от собствени данни. Следователно превключването на контекст се счита за тежка операция.

По този начин идеята на това изследване е доста проста: ако на потребителските процеси е разрешенобягат по-дълго, те ще завършат по-бързо.

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

Нашите експерименти бяха проведени за 10ms, 20ms, 340ms и 400ms кванти:

• 10ms - за симулиране на изпълнението на процеси на HP-UX и просто за сравнение и проучване на тенденциите;

• 20ms - стандартен квант в OS Solaris 8,9,10;

• 340ms - квантова таблица за изпращане за популярни сървъри Fujitsu Siemens PRIMEPOWER;

• 400ms - беше избрано за сравнение и проучвания на тенденции.

Експериментът беше проведен на SunFire V240: 2 процесора Ultra-SPARC-IIIi на 1500MHz, 8GB RAM, Oracle 10.2.0.3 64-bit.

В базата данни е създадено малко приложение с интензивен процесор:

СЪЗДАВАНЕ ИЛИ ЗАМЕНЯНЕ НА ФУНКЦИЯ двойно (n ЧИСЛО)

ВЪРНАТ НОМЕР Е

ЗА f IN 1..n LOOP

2 за i в 1..256 цикъл

3 вмъкване в тестови стойности (i, "1", "2");

4 вмъкване в тестови стойности (513-i, "1", "2");

PL/SQL процедурата е завършена успешно.

След това на ниво ОС беше зададена една от квантовите стойности - 10, 20, 340 или 400. Измерването на продължителността на изпълнение на процедурата беше извършено чрез следната заявка:

bash-3.00$ cat sql.sql

изключете обратната връзка

потеглям

ИЗБЕРЕТЕ двойно (10000000) ОТ двойно

Метод на първия експеримент

За първата серия от експерименти в системата се създава висока честота на превключване на контекста (няколко дълги сесии се стартират едновременно в базата данни) и на техния фон се изследва продължителността на избрана потребителска сесия:

bash-3.00$ cat sql.sh

/ooo/ora102/bin/sqlplus -s "/as sysdba" @/ooo/sql/sql.sql

В резултат на изпълнение на 10 сесии на два процесора, получаваме по 5 активни двойки сесия/процесор. Скоростта на приложението се измерва с командата за време по продължителността на последната сесия. За последната сесия бяха получени две стойности - едната изведена от командата "set timing on" от sqlplus, а втората изведена от командата time. За останалите 9 сесии беше получена стойността от sqlplus След това за всичките 10 сесии средната Ave10 беше изчислена от стойностите на sqlplus. В резултат на експеримента бяха получени три стойности - две за една последна сесия и Ave10 за всичките 10 сесии.

Квантов размер Q

Контекстни превключватели / s

Време за изпълнение за един

Средно над 10 сесии

Разлика в секунди

В резултат на увеличаване на квантовата стойност от 20 на 400ms се получава 13% увеличение на производителността (Таблица 1), а именно:

• според SQLPLUS продължителността на една (последна) сесия е намаляла с 13% (от 132,4 секунди на 118,14 секунди, колона Sqlplus (s));

• според командата за време продължителността на сесията намаля с 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 сесии/CPU) резултатите са още по-впечатляващи:

• sqlplus показва намаляване на продължителността на всяка сесия с приблизително 21%;

• времето показва намаляване на продължителността на всяка сесия средно с 16%;

• средната продължителност на сесията Ave30 намалява с 20%;

• увеличено разпространение на делта стойностите се увеличават. Въпреки това, ако свържем Delta със стойността на квантовата Delta/quant, тогава получаваме почти константа. По този начин планировчикът на ОС не прави грешки при планирането, както може да изглежда.

Квантов размер Q

Контекстни превключватели / s

Време за изпълнение за един

Средно над 30 сесии

Предишният експеримент използва само регистри на процесора и резултатите се отнасят до повишаване на производителността на регистърни (математически) операции. Интересно е обаче да се разгледа влиянието на квантовия размер върху производителността на операциите с памет - т.е. четене на данни от блоковия кеш. В този случай поведението на операциите SELECT беше проучено поради следните причини:

• могат да се изпълняват паралелно в произволен брой и няма да се блокират взаимно, т.е. простотата и яснотата на експеримента излизат на преден план;

• около 80% от изпълнените SQL изрази в базата данни са SELECT;

• в този експеримент исках да избегна I/O операции, които правят свои собствени корекции на резултата.

За новия експеримент в базата данни беше създадена тестова таблица от 46MB: създайте тестова таблица като изберете * от dba_sources; Параметърdb_cache_size е зададен на 180MB.

Функцията в БД е променена, както следва:

СЪЗДАВАНЕ ИЛИ ЗАМЕНЯНЕ НА ФУНКЦИЯ test_select RETURN

за f в 1..25 ​​​​LOOP

FOR rec IN (изберете * от тест) LOOP

Подробна таблица за една и десет едновременни сесии:

Подробна таблица за 30 едновременни сесии:

Тъй като тенденцията за намаляване на времето стана съвсем ясна, стана интересно да се измери още по-задълбочено производителността за 1, 5, 10 и 15 сесии/процесор. Ето какво се случи:

Следващата таблица е извлечена от предишната и показва намаляването на средната продължителност на една сесия, т.е. стойността за 5 сесии беше разделена на 5 (173,12/5=34,624), стойността за 10 сесии беше разделена на 10 (346,68/10=34,67) и т.н.:

• увеличаването на кванта от 20ms на 400ms има положителен ефект върху производителността на СУБД Oracle. Осезаем резултат от около 20% се забелязва само в периоди на пикови натоварвания и е валиден за 100% натоварени сървъри. (Тъй като стойността от 15 активни сесии на процесор е доста необичайна, такъв сървър може да се класифицира не просто като „зает“, а по-скоро като „супер претоварен“. Този ефект не е бил открит преди, очевидно защото 15 едновременно активни сесии / процесор се счита за твърде много). Сървъри с нисък и висок брой CPU могат да се възползват от тази технология;

• Печалбата във времето е пропорционална на броя на едновременно активните сесии и квантовия размер. Стандартните квантови стойности за операционните системи са избрани така, че да отговарят на интерактивните приложения и техният брой в средата на Oracle DBMS може да бъде значително увеличен. Вероятно най-голямата полза от този резултат ще бъде постигната при бази данни като DSS и DataWarehouse;

• откритиефектът отваря нови възможности за разработчиците;

• ако една задача може да бъде паралелизирана, тогава тя трябва да бъде паралелизирана колкото е възможно повече и всички паралелни процеси трябва да бъдат стартирани едновременно. С голям квант голям "куп" процеси ще бъдат завършени по-бързо, отколкото с малък квант или с последователно изпълнение. (Не се смущавайте, ако използването на процесора достигне или дори надхвърли 100% ;-))) ).

• при интерактивни приложения е възможен отрицателен резултат поради бавна реакция на системата при голяма квантова стойност, но нашите измервания не успяха да коригират влошаване на производителността;

• Стойността на кванта директно отразява противоречието между "интерактивност" и "пакетна" ОС. Малката квантова стойност е полезна за интерактивни приложения, тъй като позволява на процеса бързо да придобие процесорен ресурс и да извърши малко действие, като например обработка на прекъсване при натискане на клавиш. Системите с големи кванти са по-инертни, имат по-забележимо забавяне между действието на потребителя и реакцията на системата. Инерцията на системата намалява с нарастването на броя на ядрата, а интерактивността се увеличава.

Необходими условия за получаване на ефекта на увеличаване на кванта:

• Системата трябва да има висока честота на превключване на контекста, което се случва, когато използването на процесора е високо (100% или близо до 100%);

• потребителските сесии трябва да прекарват на процесора по-голямата част от времето си, бих казал поне 80%. Предвид рязкото нарастване на броя на ядрата в процесорите през следващите 2-3 години, бих си позволил да предложа увеличение на квантовата стойност с няколко пъти за почти всички операционни системи през следващите 5 години.