Влияние величины кванта времени операционной системы на производительность СУБД 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

v_total NUMBER;

BEGIN

v_total := 0;

FOR f IN 1..n LOOP

v_total:= sqrt(v_total+f);

END LOOP;

RETURN v_total;

END;

SQL> begin

2 for i in 1..256 loop

3 insert into test values(i,"1","2");

4 insert into test values(513-i,"1","2");

5 end loop;

6 commit;

7 end;

8 /

PL/SQL procedure successfully completed.

SQL>

Затем на уровне ОС устанавливалось одно из значений кванта - 10, 20, 340 или 400. Измерение длительности выполнения процедуры выполнялось следующим запросом:

---------------------

bash-3.00$ cat sql.sql

set feedback off

set heading off

set timing on

SELECT double (10000000) FROM dual

exit

---------------------

Методика первого эксперимента

Для первой серии экспериментов в системе создается большая частота переключения контекстов (одновременно в БД запускаются несколько длительных сессий) и на их фоне изучается длительность выполнения некоторой выбранной пользовательской сессии:

-----------------------------

/ooo/sql/sql.sh &

time /ooo/sql/sql.sh

------------------------------

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	Время выполнения одного процесса (s)	Среднее по 10 сессиям		Min (s)	Max (s)	Delta (s)	Delta/Q
			Sqlplus(s)	Time (s)
10мс	340	133,61	134,38	133,46	133,25	133,76	0,51	0,050
20мс	262	132,4	134	133,3	132,87	133,76	0,89	0,045
340мс	200	119,79	124,72	125,63	113,38	131,89	18,51	0,054
400мс	116	118,14	124,08	122,13	108,37	132,54	24,17	0,06
Разница в %	55%	13%	8%	9%	18,5%	0,9%
Разница в секундах	14 сек	10 сек	11,2 сек

В результате увеличения величины кванта с 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 сессий

Ради эксперимента было решино запустить 30 одновременных сессий. В результате выполнения скрипта start.sh получено 30 значений, которые были просуммированы и поделены на 30 (т.е. получено среднее арифметическое значение). Для 30 одновременных активных сессий в БД (15 сессий/ процессор) результаты еще более впечатляющими:

• sqlplus показывает уменьшение длительности каждой сессии приблизительно на 21% ;

• time показывает уменьшение длительности каждой сессии в среднем на 16%;

• средняя длина сессии Ave30 снизилась на 20%;

• возрос разброс значений Delta увеличился. Однако, если соотнести Delta к величине кванта Delta/quant, то получается почти константа. Таким образом,планировщик ОС не ошибается в планировании, как это могло показаться.

Размер кванта Q	Context switches / s	Время выполнения одного процесса (s)	Среднее по 30 сессиям		Min (s)	Max (s)	Delta (s)
			Sqlplus(s)	Time (s)
20мс	331,2	397,4	399,4	399,1	394,32	401,21	6,89
400мс	110,2	312,5	335,29	319,84	282,68	368,21	85,53
Разница в сек.		84,9	64,13	79,31	111,64	33	79,31
Разница в %		21,4%	16,1%	19,9%	28,3%	8,2%	19,9%

Второй эксперимент

В предыдущем эксперименте использовались исключительно регистры процессора, и результаты касаются прироста производительности на регистровых (математических) операциях. Однако, интересно рассмотреть влияние величины кванта на производительность операций с памятью - т.е. чтение данных из кеша блоков. В данном случае изучалось поведение именно операций SELECT по следующим причинам:

• их можно запускать параллельно в любом количестве, и они не будет блокировать друг друга, т.е. на первый план выходят простота и наглядность эксперимента;

• около 80% выполняемых SQL-выражений в БД - это SELECT;

• в данном эксперименте хотелось избежать операций ввода-вывода, которые вносят свои поправки в результат.

Для нового эксперимента в БД была создана тестовая таблица размером 46Мб:create table test as select * from dba_sources; Параметр db_cache_size был установлен в 180Мб.

Функция в БД была изменена следующим образом:

CREATE OR REPLACE FUNCTION test_select RETURN

NUMBER IS

delta NUMBER(10,3);

owner VARCHAR2(30);

name VARCHAR2(30);

line NUMBER;

text VARCHAR2(4000);

startdate number;

BEGIN

startdate := dbms_utility.get_time;

for f in 1..25 LOOP

FOR rec IN (select * from test) LOOP

owner:=rec.owner;

name :=rec.name ;

line :=rec.line ;

text :=rec.text ;

END LOOP;

delta := dbms_utility.get_time-startdate;

RETURN delta/100;

END;

Подробная таблица для одной и десяти одновременных сессий:

Q	Ave 1	Ave 10	Min	Max	Delta (s)	Delta%

20мс	33,98	173,12	172,48	173,98	1,5	0,9%
400мс	33,93	161,58	153,18	171,42	18,24	10,6%
Разница в сек.	0,05	11,54	19,30	2,56
Разница в %	0,1%	6,7%	11,2%	1,5%

Подробная таблица для 30 одновременных сессий:

Q	Ave 30	Min	Max	Delta (s)	Delta%

20мс	519,98	515,97	523,29	7,32	1,4%
400мс	422,64	350,11	479,25	129,14	27%
Разница в сек.	97,34	165,86	44,04
Разница в %	18,7%	32,1%	8,4%

Итоговая таблица:

	AWE 1	AVE 10	AWE 30
20мс	33,98	173,12	519,98
400мс	33,93	161,58	422,64

Третий эксперимент

Поскольку тенденция уменьшения времени наметилась достаточно явная, то стало интересно еще более глубоко промерить производительность для 1, 5, 10 и 15 сессий/процессор. Вот что получилось:

Q	1 Ses/CPU	5 Ses/CPU	10 Ses/CPU	15 Ses/CPU
20мс	33,98	173,12	346,68	519,98
400мс	33,96	161,58	305,62	422,64
In Sec	0,02	11,54	41,06	97,34
In %	0,06%	6,67%	11,84%	18,72%

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

Q	1 Ses/CPU	5 Ses/CPU	10 Ses/CPU	15 Ses/CPU
20мс	33,98	34,62	34,67	34,66
400мс	33,93	32,32	30,56	28,18
In Sec	0,05	2,308	4,108	6,489
In %	0,15%	6,67%	11,85%	18,72%

Выводы:

• увеличение кванта с 20мс до 400мс положительно сказывается на производительности СУБД Oracle. Ощутимый результат порядка 20% заметен только в периоды пиковых нагрузок и справедлив для 100% загруженных серверов. (Поскольку значение 15 активных сессий на процессор достаточно необычно, то такой сервер можно классифицировать не просто "нагруженый", а скорее как "супер-перегруженный". Ранее этот эффект не был обнаружен, видимо потому, что считается, что 15 одновременно активных сессий/ процессор - это чересчур много). На серверах как с небольшим числом так и с большим числом ЦПУ можно получить пользу от этой технологии;

• выигрыш во времени пропорционален числу одновременно активных сессий и величине кванта. Стандартные значения кванта для операционных систем выбраны для удовлетворения интерактивных приложений, и их число в среде СУБД Oracle можно значительно увеличивать. По-видимому, наибольшая польза от данного результата будет достигнута на базах данных типа DSS и DataWarehouse;

• обнаруженный эффект открывает новые возможности для разработчиков;

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

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

• величина кванта непосредственно отражает противоречие между "интерактивностью" и "пакетностью" ОС. Малая величина кванта полезна для интерактивных приложений, потому что это дает возможность процессу быстро получить процессорный ресурс и выполнить некоторое небольшое действие, например, обработать прерывание от нажатия клавиши на клавиатуре. Системы с большими квантами болееинертны,в них более заметна задержка между действием пользователя и реакцией системы. Инертность системы уменьшается с ростом числа ядер, а интерактивность возрастает.

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

• в системе должна наблюдаться высокая частота переключения контекста, которая возникает при высокой загруженности ЦПУ (100% или близкой к 100%);

• пользовательские сессии должны проводить на процессоре бОльшую часть своего времени, я бы сказал не менее 80%. Учитывая резкий всплеск в ближайшие 2-3 года числа ядер в процессорах, рискну предположить увеличение в несколько раз величины кванта практически для всех ОС в ближайшие 5 лет.

Ссылки по теме