CC BY
30
№ 5 (35) 2011
Ю. В. Тименков, Д. В. Тименкова, аспиранты Московского физико-технического института (государственного университета)
А. Г. Тормасов, докт. физ.-мат. наук, профессор Московского физико-технического института (государственного университета)
Моделирование операции резервного копирования на нагруженной системе
Одной из ключевых задач в работе хостинг-провайдеров является обеспечение качества предоставляемых услуг. Для достижения этого применяется ряд мер, многие из которых противоречат друг другу.
Введение
Обеспечение качества услуг хостинг-провайдеров, с одной стороны, требует постоянно поддерживать заявленный уровень SLA (Service Level Agreement), т. е. выделять потребителям (процессам или виртуальным машинам клиентов) столько ресурсов, сколько положено по договору. С другой стороны, должно производиться регулярное профилактическое обслуживание центра обработки данных — резервное копирование данных или обновление конфигурации серверов.
Как показывают исследования [14], большинство клиентов использует на 100% выделенные им ресурсы только достаточно ограниченное время, поэтому гораздо выгоднее использовать немного перегруженные сервера и уметь управлять критическими ситуациями. Одной из таких ситуаций является проведение резервного копирования или архивирование [15]. Это достаточно требовательный к различным ресурсам процесс, ведь, по сути, это не что иное, как пересылка по сети большого объема данных, считанных с диска. Для уменьшения расходов на хранение и повышение безопасности системы данные могут подвергаться дополнительной обработке: сжатию и шифрованию. Данная работа выполняется за счет ресурсов процессора. В некоторых случаях, например при работе сервера баз дан-
ных, файлы могут активно модифицироваться. В результате данные в архиве могут оказаться поврежденными, если архиватор обработал часть файла, а затем он полностью поменялся. Чтобы этого избежать, необходимо «заморозить» состояние диска на момент начала операции, для чего требуется большое количество оперативной памяти, в которой хранятся изменившиеся, но еще не обработанные участки диска.
Как показывает практика, именно интенсивное использование диска архиватором может существенно замедлить работу всей системы, вплоть до возникновения отказов в обслуживании. Наиболее распространенный способ повышения отзывчивости в этом случае — понизить приоритет операции резервирования. К сожалению, данный способ может работать не всегда, так как потребление некоторых ресурсов растет с уменьшением приоритета. К таким ресурсам относятся объекты синхронизации, файловые дескрипторы и оперативная память, содержащая изменившиеся файлы, ведь чем быстрее архиватор обработает данные, тем скорее освободится память, в которой они хранятся. Именно поэтому важно уметь правильно управлять подобными операциями, для чего необходимо правильно прогнозировать время, требуемое на их завершение. К сожалению, простые линейные оценки не всегда точны (например, измерить, за какое время выполнится часть операции, а затем экст-
№ 5 (35) 2011
раполировать до полного завершения). Это связано с тем, что на разных этапах требуется разный набор и количество ресурсов, и на начальном этапе, к примеру, их может быть достаточно, а затем начнется конкуренция. Также и наличие ресурсов не постоянно — другие процессы могут менять свои «аппетиты».
1. Обзор существующих работ
Об актуальности данного вопроса говорит и большое количество работ, посвященных этой теме. Но большинство из них предназначены для моделирования «физического» компьютера, и в большинстве рассматривают только отдельно взятый ресурс (чаще всего сеть). Например, в подходе, изложенном в [1] и [5], предлагается численное моделирование временных рядов на основе нелинейных преобразований случайных гауссовских процессов. Данный метод следует применять для анализа и построения вычислительных сетей, но он не рассматривает зависимости сетевой нагрузки | от состояния приложений, выполняющихся § на отдельных узлах.
^ Другой класс работ, посвященных этой | тематике, рассматривает вычислительные Ц системы с точки зрения теории массово-& го обслуживания. Например, работа [2] по* священа вопросу определения минимально достаточной производительности комплек-| са, осуществляющего поддержку функций <5 управления деятельностью на предприятии. | Подобные модели рассматривают вычис-5 лительную систему как обработчик потока § запросов, поступающих от клиентов. В ре-^ зультате расчетов получаются зависимости скорости или времени обработки запросов <1 от их характера и количества. Подобные мо-^ дели более всего подходят для оценки про-§ изводительности системы, когда процессы | в ней не испытывают жесткой конкуренции £§ за ресурсы.
^ Наиболее близкой к предлагаемому методу является модель, описанная в [7]. В ней ?! также работа вычислительной системы рас-
сматривается как процесс распределения ресурсов между потребителями. Но в отличие от данной статьи, в [7] процессы описываются с помощью дифференциальных уравнений гиперболического типа. В настоящей статье предлагается способ моделирования работы нескольких конкурирующих за ресурсы процессов, с целью определения времени их завершения. В качестве таких процессов выбраны операции компиляции и архивирования. Они достаточно требовательны как к диску, так и к процессору. Конкуренция за эти ресурсы и является предметом моделирования.
2. Математическая модель процесса
2.1. Ресурсы операционной системы и исполнение программ
В процессе работы приложение пользуется некоторыми ресурсами компьютера и операционной системы. К ним относятся жесткий диск (при чтении/записи информации), сеть (для передачи данных) и др., но основным является, конечно, процессор. Без получения доли времени не может исполняться ни одна программа. Можно даже считать его основным ресурсом, гарантирующим исполнение программы [7]. Однако в данной статье будет показано, как можно рассматривать процессор в качестве ресурса наравне с остальными видами.
Исполнение программы можно разбить на несколько участков или стадий. Они могут быть как логические (получение запроса, его обработка и т. д.), так и физические (исполнение функции или нескольких команд процессора). Рассмотрим исполнение процесса как последовательный переход из одной стадии в другую. При этом полагаем, что последовательность исполнения стадий известна заранее. Это означает, что рассматривается такой вариант исполнения программы, в котором известны все условные переходы (а циклы автоматически превращаются в несколько последовательных
86 у
ПРИКЛАДНАЯ ИНФОРМАТИКА /-
' № 5 (35) 2011
стадий). Тогда для перехода из одной стадии в другую процессу необходим некоторый набор ресурсов. Причем если не хватает хотя бы одного ресурса, то переход в следующую стадию состояться не может, и процесс не потребляет другие виды ресурсов, даже если они ему предоставлены.
Рассмотрим, к примеру, процесс, которому для обработки запроса необходимо исполняться 2 с на процессоре и считать 1 Мб с диска. Предположим, что ему выделили достаточный квант процессорного времени, но диск в это время оказался занят. Тогда приложение прервет исполнение до завершения операции ввода-вывода, а освободившееся процессорное время будет отдано другим программам, готовым к исполнению. И наоборот, если с диска никто не читает, но процессор перегружен задачами, то программа просто не сможет отправить запрос на чтение данных, т. к. для этого ей необходимо находиться в состоянии исполнения на процессоре.
В данных утверждениях скрыты еще два ключевых положения, лежащих в основе предлагаемой автором модели. Во-первых, процессы считаются однопоточными и независимыми друг от друга. Во-вторых, в реальности исполнение стадии не является атомарной операцией, т. е. работа программы может быть прервана в любой момент, а затем продолжена, зачастую с другой скоростью. Конечно, можно выбирать очень маленькие стадии (исполнение одной инструкции процессора или чтение блока с диска). Но в этом случае модель вырождается до вида, когда для исполнения каждой стадии нужен только один вид ресурсов. В решаемой задаче наиболее рациональным является размер стадии в несколько квантов планирования. В разных операционных системах используются различные величины квантов планировщика [6], более того, данные параметры могут настраиваться как пользователем, так и динамически, в зависимости от текущих условий. В системе, на которой ставился эксперимент, процесс может непрерывно исполняться 20 мс, по-
этому вполне разумно выбрать размер ста- | дии в 100 мс. ^
2.2. Аналогия исполнения программы Ч
с движением автомобиля §
|
Исполнение процесса (переход от од- | ной стадии к другой) можно представить ^ как движение автомобиля. При нажатии с^ на педаль акселератора автомобиль полу- |* чает больше топлива и начинает двигать- ;Б ся быстрее. Также и программа исполня- й ется быстрее, когда получает больше ресурсов от планировщика. Операционная ® система, как и водитель, учитывает квоты на ресурсы — предельно допустимые скорости и дистанции между автомобилями. Аналогию можно провести и между плотностью потока машин и количеством работающих процессов — чем их больше, тем меньше будет выдаваться ресурсов каждому отдельному участнику.
3. Формализация модели
3.1. Скорость исполнения
Рассмотрим процесс исполнения программы как движение вдоль некоторой «оси исполнения» х. В начальный момент времени программа находится в точке с координатой 0. В простейшем случае можно считать, что х — это процент выполненных команд при условии, что все циклы в программе развернуты. Скорость продвижения по данной оси определяется как
dx и=—. dt
Для исполнения программе необходим некоторый набор ресурсов й. В общем случае он может зависеть от многих факторов, в том числе от внешних. Скажем, потребность в вычислительной мощности для web-сервера пропорциональна нагрузке на него. Но для упрощения будем рассматривать работу программы после ее завершения, когда нам заранее известно ее поведение. В этом
-ч ПРИКЛАДНАЯ ИНФОРМАТИКА
№ 5 (35) 2011 ' -
случае можно предположить, что необходимый набор ресурсов в каждый момент исполнения зависит только от внутреннего состояния процесса, т. е.
D=D( х).
(1)
I Й
I
'S о
Ig
& ig
I
S
t §
12
0
t £
1 £
о
Ii
S 00 О
! 5
С другой стороны, ресурсы выделяются (и распределяются между потребителями) внешней сущностью — планировщиком. Также доступный набор ресурсов ограничен некоторым максимальным значением — производительностью процессора или скоростью работы сети. Очевидно, что скорость исполнения программы будет тем больше, чем больше доступно ресурсов.
Вполне очевидно, что для исполнения процессу необходимы не просто какие-то ресурсы — они нужны в определенном соотношении, поэтому для определения скорости важно не абсолютное значение количества каждого ресурса, а их относительные величины. Понятно, что возможность потребления ресурсов программой ограничивается наименее доступным для нее ресурсом. Например, если работает программа математического моделирования, которой требуется только процессор, то бессмысленно улучшать в системе сетевой контроллер — программа работать быстрее не станет. И, с другой стороны, если программе нужны два ресурса (скажем, процессор и диск), но один из ресурсов ограничен, то и второй в полном объеме она потребить не сможет. Таким образом, можно считать, что скорость исполнения программы пропорциональна количеству наименее доступного ресурса.
Отвлечемся от конкретных алгоритмов, по которым планировщик выделяет ресурсы, и предположим, что нашей программе был выделен набор ресурсов P={р}, где i соответствует типу ресурса (процессор, диск и т. д.). Тогда наименее доступным будет ресурс, у которого достигает минимума соотношение
D
— ^ min.
Соответственно, скорость будет изменена пропорционально этому «коэффициенту голодания»:
■ D
и=иот1Пр,
где и0 — «эталонная» скорость исполнения программы.
Для определения значений и единиц измерения модельных переменных воспользуемся следующим предположением. Будем считать, что у нас есть некоторые «эталонные» условия исполнения программы, где она исполняется монопольно и не испытывает недостатка в ресурсах. В этом случае считаем, что скорость исполнения программы была постоянной. Также нам известно время ее исполнения Г0, поэтому можно легко вычислить эталонную скорость:
X
uo = у,
П
(2)
P
i
где X=1 — считаем, что программа исполнилась от начала и до конца. Вообще, аналогично можно предположить, что в данном случае программа выполнялась со скоростью 1, тогда бы мы вычисляли X — ее размер (или длину). Попутно можем снять графики потребления ресурсов, например с помощью утилиты рег^гюп или аналогичных ей. Таким образом, мы знаем зависимость D( х) — внутреннюю потребность процесса в ресурсах в каждый момент его исполнения.
3.2. Описание планировщика
За распределение ресурсов в операционных системах отвечает специальный модуль — планировщик. Существуют разные стратегии выделения ресурсов (более подробно можно прочитать в [6], [13], [8], [12]). Администратор может выбирать наиболее подходящую для конкретных задач.
Важно отметить, что в данной статье рассмотрим не сам планировщик или его алгоритм, а наблюдаемые результаты его работы.
88 у
№ 5 (35) 2011
Это позволяет описать функцию, показывающую распределение сразу всех типов ресурсов, потребление которых взаимосвязано. Например, при попытке выполнить операцию чтения с диска программа «отпускает» процессор, и если диск ей не выделили, фактически будем наблюдать в том числе снижение уровня потребления процессора. Обратное тоже верно — если программе не выделили процессорное время, она не сможет выполнить запрос к диску, несмотря на то, что он может быть вполне доступен.
В настоящей статье рассмотрим работу планировщика, который распределяет ресурсы между потребителями пропорционально их весам. Несмотря на простоту, данный тип планировщиков наиболее распространен в операционных системах, а усложненные варианты все равно пытаются свести свой результат к этому виду, учитывая различные физические особенности (например время позиционирования головки диска). Таким образом, каждому из N процессов достанется количество ресурса, равное
р =Р"
Ж
j=0
(3)
где} — номер процесса, Ж — его вес. Фактически Рта — это предельные возможности системы (максимальная производительность диска, полная ширина сетевого канала и т. д.).
Предположим, что имеется набор ресурсов Я, которые необходимо распределить между N потребителями. Алгоритм распределения итеративный и состоит из следующих шагов.
1. Из уравнения (3) вычисляем вектор доступных ресурсов р, полагая Ргпах = Я, где } е1..М — номер потребителя.
2. Для каждого потребителя считаем коэффициент недостаточности по всем ресурсам и находим среди них минимальный:
У, =1Г11П
(4)
Важно отметить, что из рассмотрения исключаются ресурсы, которые не требуются процессу в данный момент (т. е. такие, для которых й=0).
3. Процесс с наименьшим коэффициентом (пусть его индекс к) исключается из дальнейшего рассмотрения. При этом:
— вычисляем его долю ресурсов:
йк=А;
(5)
— вычитаем потребленные рассматриваемым процессом ресурсы из Я :
Я=Я - а.
(6)
4. Для оставшихся процессов проделываем те же операции с шага 2.
Таким образом, для всех процессов мы получили коэффициенты, показывающие, насколько в указанных условиях процесс будет исполняться медленнее (или быстрее — в зависимости от соотношения значений Ртах на текущей и эталонной системах). Тогда можно вычислить мгновенную скорость исполнения процесса в данный момент времени:
и = у и,0.
(7)
А прогресс исполнения программы получается интегрированием по t:
ху. = ¡и Л. (8)
Задача легко решается численными методами, верхним пределом интегрирования будет следующее значение:
х=X.
(9)
Это условие означает, что рассматриваемый процесс прошел все стадии исполнения и успешно завершился. При х > X процесс считается завершившимся и больше не потребляет ресурсы.
4. Описание эксперимента
Для подтверждения идей, заложенных в основу описанной выше модели, был поставлен опыт, позволяющий оценить, на-
Л
Й* со
1
со
I
1 со £
89
№ 5 (35) 2011
сколько точно численное решение соответствует наблюдаемому.
4.1. Идея эксперимента
Как уже говорилось, смоделируем одновременное исполнение полезной нагрузки и операции резервного копирования. В качестве первой был выбран процесс компиляции как одна из типовых нагрузок, встречающихся в реальной жизни. В данной работе рассматриваются всего два ресурса — диск и процессор. И, как мы увидим далее, компиляция программы из исходных текстов в высокой степени подходит для нашей задачи моделирования, т. к. является достаточно требовательной к обоим видам ресурсов. Для начала необходимо определить внутренние потребности обоих процессов в ресурсах — правую часть уравнения (1). Как уже было сказано, существует определенная свобода выбора базисных модельных величин. В этом случае удобнее выбрать скорость исполнения процесса при монопольном доступе к ресурсам за единицу, т. е.
I ио =1, (10) ё
тогда из уравнения (7) получается, что ско-
| рость исполнения программы при наличии
Ц конкуренции за ресурсы есть не что иное,
& как «коэффициент голодания» (вычисляе-
* мый с помощью уравнения (4))
I и1 = уу (11)
§
<э и, подставляя (10) в (2), получаем грани-
| цу для условия исполнения процесса (9):
5 Х] =Г0 . Другими словами, профиль потреб-
§ ления ресурсов для процесса, при наличии
^ конкуренции за ресурсы, будет выглядеть следующим образом: D¡(t)=D0 (х(0), где
| D0 (t) и есть тот самый профиль потребле-
^ ния ресурсов при монопольном исполнении,
§ который мы рассматриваем.
| Зная внутреннюю потребность процес-
§ са в ресурсах, в зависимости от стадии его
^ исполнения, можно рассчитать потребление ресурсов (и, что важно, время исполне-
?! ния) при конкурентном исполнении по фор-
мулам, описанным в разделе 3.2. С другой стороны, аналогично измерению D0(t) получаем зависимость Dj(t), которую и сравним с расчетной.
4.2. Технические особенности
Скажем несколько слов об условиях, в которых ставился данный эксперимент, — было преодолено несколько технических трудностей. Используемая ОС Linux предоставляет обширные средства для мониторинга с помощью файловой системы /proc [10]. Минусом является отсутствие штатных средств, позволяющих записывать информацию о потребленных ресурсах в файл для дальнейшей обработки. Анализ же всех процессов в системе может оказаться достаточно ресурсоемким занятием, поэтому утилиты вроде top и atop стараются ограничивать частоту съема контрольных значений [9], в связи с чем был написан небольшой скрипт, который следил за состоянием дочерних процессов и записывал в файл потребление ими процессора (используя /proc/pid/schedstat) и диска (опрашивая /proc/pid/io).
В качестве единиц потребления процессора использовалась доля времени (от общего системного), которое процесс находился в состоянии исполнения. То есть если в момент времени t значение счетчика было C1, а в момент времени t+At, соот-
C - C
ветственно, C2, то Dcpu(t)= ^ 1 ■ Для диска же просто считалась сумма считанных и записанных байт за интервал времени: Ddjsk(t)=(Rb2 -Rb1)+(Wb2 -Wb1), где Rb — количество считанных байт, а Wb — записанных. Причем учитывается только количество байт, считанных именно с диска, а не взятых из буфера, поэтому перед каждым запуском производилось обнуление с помощью записи команды в файл /proc/sys/vm/ drop_caches.
Известно, что для сборки серьезного проекта используется не один компилятор, а целый набор утилит (например оболочка
№ 5 (35) 2011
make, компилятор, компоновщик и т. д.), которые запускаются по несколько раз, поэтому при вычислении D(t) необходимо считать потребителем не отдельный процесс, а все процессы, ответственные за данную задачу.
Таким образом, Dmake (0=^Д (t), где Dt (t) —
/
профиль потребления дочернего процесса. Причем необходимо понимать, что Di (t)=0 во всех точках, где процесс либо еще не существовал, либо уже закончил свое исполнение. Здесь и возникают определенные сложности, т. к. в Linux можно измерить потребление только одного процесса, а здесь необходимо следить за неизвестным априори рождением и завершением процессов. Кажущийся логичным вариант — измерять общую загрузку процессора — не подходит, т. к. не позволяет оценить долю, потребленную при параллельном запуске с нагрузкой, поэтому для данной задачи был применен следующий «трюк»: вместо полноценной сборки получили список конечных команд (например, с помощью параметра -n для make), которые затем последовательно исполнялись. В данном эксперименте мы не измеряем абсолютную скорость исполнения задачи. Нам лишь важно, чтобы нагрузка была одинаковая при каждом запуске, что выполняется при применении данной техники.
При проведении эксперимента большое внимание уделялось удобности воспроизведения и минимизации случайных отклонений. Для обеспечения первого критерия запуск всех тестов был автоматизирован. Это дало возможность без особых усилий повторить эксперимент необходимое количество раз, если в процессе обнаружилась какая-то ошибка. Для уменьшения случайных воздействий производилось несколько запусков. Для каждой точки отбрасывались значения, сильно выбивающиеся из нормального распределения (не удовлетворяющие Q-критерию):
IY - У I
Q= ? nearest '
_ IX - X Г
max min
где х? — проверяемое значение, xnearest — | ближайшее к нему, xmax и xmп — максималь- i
J max тип ^^
ное и минимальное значение в выборке, со- ¡^
ответственно. В качестве порогового зна- ^
чения Q было выбрано 0,412, что соответ- [§
ствует доверительной вероятности 90% для ^
выборок из десяти элементов. g
со
Точки, прошедшие отбор, далее исполь- ^ зовались для вычисления усредненного зна- |* чения функций D(t): ig
5
N ¿S
YPep, (t) 00
D(t)={Dexp (t)> = =1 N , (12) 5j
где D — функции потребления ресурсов в -м эксперименте, N — количество запусков (в данном случае N=10 ).
4.3. Вычислительный алгоритм
Конечная задача численного моделирования — вычисление интеграла. Отметим, что он является несколько нестандартным для вычисления. Во-первых, функция x(t) — интеграл с переменным верхним пределом. Во-вторых, подынтегральное выражение имеет разрывы первого рода. Решение подобных задач описано в [3]. Покажем, как предлагаемые методы можно использовать в нашем случае.
Для упрощения дальнейших выкладок обозначим алгоритм, описанный выше в разделе 3.2, как функцию о :
o(D):[Dj }, (13)
где D=\jDj ] — матрица потребности процессов в ресурсах, а у={} — вектор коэффициентов недостаточности ресурсов.
Необходимо отметить, что до этого момента подразумевалось, что j — номер процесса в системе, i — номер ресурса. Далее будет использоваться классическая нотация для вычислительной математики, и под i будет подразумеваться номер шага интегрирования, если не оговорено иное.
№ 5 (35) 2011
Используемая в данной модели функция о^) зависит только от заказанных уровней потребления всех процессов и не зависит ни от времени, ни от предыдущих значений. Отметим также, что о^) — параметрическая функция, параметрами которой, согласно уравнению (3), являются вектор максимальной производительности источников ресурсов Ртах и набор весовых коэффициентов ^. Функции потребности в ресурсах D(x) заданы численно, в табличной форме и получены из экспериментов, как описано выше, в разделе 4.2, уравнение (12):
К 8 о ё
& Её
I
I §
12
0
1
I £
ё
0
1
со
0
1
I
D(Хо) ОД D(хг)
Как увидим в дальнейшем, для аппроксимации функции D(x) удобно использовать ступенчатую интерполяцию:
D (X )=D (X,.),/: X е[ х ,х(+1).
Таким образом, функции D(x) будут кусочно-постоянными, а следовательно, бесконечно интегрируемыми на каждом интервале. При таком подходе функции о0) также будут кусочно-постоянными по х. Значит, любой промежуток времени можно разбить на участки, на которых подынтегральное выражение в (8) является константой. На каждом из таких интервалов функция х(0 будет линейной и может вычисляться аналитически. Все сложности вычисления интеграла (8) сводятся к определению этих отрезков непрерывности функции о0). Для каждого процесса вычисляется время до изменения потребности Dj при условии, что скорости исполнения постоянны:
Хп - Х1
здесь Atj — шаг по времени для /-го процесса, хп — координата следующего значения в таблице Dj, х- и и/ — текущие прогресс и скорость исполнения программы. Далее берется наименьшее из значений Atj и счи-
тается интеграл на промежутке ^^+А0. Затем пересчитываются скорости и «коэффициенты голодания» по формулам (4) и (5). Интегрирование останавливается при выполнении условия (9).
Рассмотрим определения скорости (7) и «коэффициента голодания» (4). Так как отрицательного количества ресурсов просто не бывает, то функции потребления не отрицательные во всех точках по определению. Другими словами, D(х) 0,Ухе[0,+~). Поэтому интеграл (8) будет монотонно неубывающей и непрерывной функцией от t (как интеграл с переменным верхним пределом) [4]. Таким образом, условие (9) рано или поздно выполнится, т. е. алгоритм конечен. Для вычисления интеграла на каждом участке используется метод левых прямоугольников, являющийся методом Рунге-Кутты первого порядка: х(+1= х1 + и 1 At, где и/ вычисляется с помощью формулы (11) и описанной выше функции о^), (13): и 1 =о^(х()). Здесь функции D, а также переменные и1 и х1 являются векторами, каждый элемент которых соответствует отдельному процессу.
Выпишем конечную систему, используемую для вычислений:
D(х)=D(хк),к:х, е[хк,хк+1)
и, =о(Р (х))
х,+1= х; + и,А t=t+At.
В уравнении, описывающем и , опущен единичный множитель размерностью прогресс исполнения/секунда. На каждом шаге проверяется условие (9), и процессы, для которых оно не выполняется, исключаются из рассмотрения. Другими словами, считаем, что D( х 1 )=0,х > X. Процесс интегрирования останавливается, когда условие (9) выполнится для всех процессов.
4.4. Оценка точности численного метода
Как показано выше, при выбранном способе интерполяции исходных функций подын-
92
№ 5 (35) 2011
тегральное выражение представляется кусочно-постоянными функциями, а сам интеграл можно вычислять аналитически. Таким образом точность решения определяется только точностью аппроксимации D(x). Большинство методов, такие как правило Рунге, требуют гладкости исходных функций [3]. К сожалению, нам ничего не известно о свойствах D( x), так как они заданы таблично и получены экспериментально, поэтому нельзя дать какие-то количественные оценки точности. Но в данной работе гораздо важнее качественное поведение получившихся функций.
4.5. Результаты эксперимента
В этом разделе приводятся графики, полученные как в ходе эксперимента, так и в результате численного моделирования.
На рисунке 1 показана зависимость потребления процессора и диска при эксклюзивном запуске (когда нет других потребителей ресурсов). Как видно, потребление ресурсов при сборке программы из исходных текстов можно разделить на 3 этапа. Первый этап характеризуется практически полным отсутствием нагрузки по процессору, но зато большими объемами обмена с диском. Это связано с тем, что данных в дисковом буфере еще нет и происходит его наполнение. В это время компилятор занимается активным поиском включаемых системных файлов (included headers), поэтому выполняется большое количество запросов к диску (как для чтения файлов, так и для поиска их в каталогах). На втором этапе (до 30-й с) наиболее часто используемые данные попали в буфер, поэтому у компилятора есть возможность загрузить процессор полностью. На том же этапе можно наблюдать небольшие провалы в потреблении процессора, связанные с тем, что программа отвлекается на чтение с диска. Для более полного представления ширину пиков можно сравнить со средним временем компиляции одного файла, которое в данном эксперименте получилось равным 0,83 с.
Со временем буфер записи заполняется, | и начинается достаточно активный сброс ^ буферов на диск. При этом процессор уже ¡^ не может загрузиться полностью, так как ^ компилятор вынужден проводить время, ожидая завершения операции ввода-выво- ^ да. Следует иметь в виду, что провалы по- g требления процессора не полностью соот- ^ ветствуют по времени пикам потребления ^ диска, так как на этом графике приведены |* усредненные данные по нескольким про- ig гонам теста. В результате усреднения экс- g тремумы могут немного размываться и смещаться. Что же касается работы архивато- ^ ра, то у него в начале также наблюдается некоторый период разогрева, когда потребность в диске намного больше, чем в процессоре. Это связано с тем, что архиватор в начале работы обходит дерево каталогов и рассчитывает необходимые параметры сжатия, а также предстоящий объем работы. Из-за отсутствия данных в дисковом буфере происходит интенсивное чтение.
На рисунке 2 показаны зависимости потребления процессора и диска при одновременном запуске обеих программ, когда имеет место конкуренция за ресурсы. При ее наличии существенно увеличивается период разогрева (время, когда потребление процессора очень низкое, а вся нагрузка идет на диск). Если при монопольном исполнении он составлял 2 - 2,5 с, то при конкурентном запуске он равен примерно 7 - 8 с. Таким образом, наблюдается нелинейная зависимость. Это связано с тем, что при возрастании нагрузки на диск снижается эффективность выполнения операций чтения в результате увеличения числа перемещений головки. В данном эксперименте использовался обычный жесткий диск, для твердотельных накопителей результаты могут быть совершенно другими [11]. Если при монопольном исполнении make после заполнения дискового буфера мог загрузить процессор на полную мощность, то теперь он вынужден делить ресурсы с архиватором, в результате чего второй этап практически исчезает. Причем это происходит как из-за недостат-
№ 5 (35) 2011
Загрузка диска
Рис. 1. Потребление ресурсов при эксклюзивном запуске. Верхний график — обмен с диском, Мб/с. Нижний — загрузка процессора, %
Загрузка диска
— таке ■-■ длр
60
время, с
94
Рис. 2. Потребление ресурсов при одновременном запуске. Верхний график — обмен с диском, Мб/с. Нижний — загрузка процессора, %
№ 5 (35) 2011
Загрузка диска
— эксперимент
- - модель
60
время, с
Загрузка процессора
60
время, с
Рис. 3. Сравнение экспериментальных и численных данных для компиляции. Верхний график — обмен с диском, Мб/с. Нижний — загрузка процессора, %
Загрузка диска
Рис. 4. Сравнение экспериментальных и численных данных для архиватора. Верхний график — обмен с диском, Мб/с. Нижний — загрузка процессора, %
со
0
л
Й* со
1
со
I
1 со £
95
№ 5 (35) 2011
ка процессора, так и из-за большего числа промахов мимо дискового буфера.
Теперь сравним описанные выше результаты с полученными с помощью численного моделирования. Графики приведены на рис. 3 и 4. Хотя точного совпадения функций потребления ресурсов не получилось, характер зависимостей (расположение и форма выпадов) в обоих случаях одинаковый.
Вернемся к изначальной практической задаче, которая ставилась при разработке этой математической модели, а именно — оценка времени завершения процесса. С ней модель справилась достаточно хорошо: расхождение во времени завершения процесса архивации составляет всего 4,7%. Для процесса компиляции точность чуть ниже — 7,3%. Тем не менее для практических задач погрешность в 10% является хорошей и вполне допустимой. Также можно наблюдать небольшое расхождение по времени всплесков потребления. Это можно объяснить тем, что данная модель не учитывает использование дискового буфера. В результате при конкурентном исполнении процес-| сов чтение с диска может происходить как § раньше по времени (так как промах мимо буфера получается с большей вероятно-| стью), так и позже. В последнем случае, хо-Ц тя процесс и считывает большое количест-& во данных, скорость их чтения будет ниже * из-за необходимости перемещения головки. Этот эффект особенно хорошо виден | на участках, где оба процесса нуждаются
<5 в обмене данными с диском. §
§
£2 4.6. Область применимости модели
^ Как видно из графиков на рис. 3, после завершения архивирования модельное пове-|| дение компилятора существенно отличается ^ от реального. Мы столкнулись с ограниче-§ нием рассматриваемой модели. Дело в том, | что при монопольном исполнении к этому Е§ моменту у компилятора есть все необхо-^ димые данные в буфере диска. При конкурентном же исполнении, несмотря на то что ?! нет видимых потребителей, может происхо-
дить сброс буферов на диск, т. е. фактически, вместо процесса архиватора, появился новый системный процесс (по аналогии с System Idle Process в Windows), который также начал требовать ресурсы. В данной модели он не учитывается. Также расхождение в графиках получается из-за разных условий, при которых процесс выходит на эту стадию. Если при монопольном исполнении в буфере находились данные, с которыми компилятор активно работал, то при параллельном с архиватором запуске происходило регулярное вытеснение данных, поэтому вместо того, чтобы использовать быструю оперативную память, система вынуждена обращаться к диску. Не следует забывать, что объем переданных данных не является единственным критерием интенсивности обмена. При чтении данных из разных областей диска необходимо позиционировать головку, что может занимать существенное время. Именно это мы и наблюдаем на графиках: нет больших объемов считываемых данных, и процессор недогружен (в отличие от результатов численного моделирования).
Учесть описанные выше эффекты можно, если ввести дополнительные штрафы за повышенную конкуренцию в уравнения (3) и (4). К примеру, время чтения с диска складывается из времен позиционирования и самого чтения, поэтому при большом количестве потребителей реальная скорость передачи падает. Это снижение и необходимо отразить в уравнении (3), введя зависимость от числа потребителей или соотношения между количеством и объемом запросов. Также модель необходимо дополнить памятью, чтобы учитывать не только текущие потребности, но и то, как ресурсы распределялись ранее. Это позволит описать следующие эффекты:
1) увеличение числа промахов мимо буфера диска;
2) динамические приоритеты в планировщике процессора (когда эффективный приоритет процесса растет со временем его нахождения в состоянии готовности);
№ 5 (35) 2011
3) различные стратегии планирования диска (например anticipatory scheduler, fair scheduler) [13], [8], [12].
Из неучтенных моментов отметим также то, что могут иметь место нелинейные зависимости между ресурсами. К примеру, при определенном уровне потребления памяти начинается процесс выгрузки неиспользуемых страниц в файл подкачки. Это приводит к тому, что потребность в памяти влечет потребность в диске. При большом количестве процессов вероятность возникновения описанных выше ситуаций резко возрастает, поэтому можно утверждать, что модель эффективно работает на относительно небольшом количестве процессов.
Заключение
Несмотря на описанные выше ограничения, модель вполне адекватно описывает рассматриваемый процесс. Как было показано, результаты численного моделирования в достаточной степени сходятся с экспериментом как количественно (время завершения процессов), так и качественно (зависимость выделенных процессу ресурсов от времени). К достоинствам предлагаемого решения стоит отнести также его простоту и универсальность. С помощью данного метода можно легко прогнозировать не только исполнение операции резервного копирования, но и другие сервисные операции, такие как проверка антивирусом, дефрагментация диска и даже живая миграция процессов. Кроме того, в качестве нагрузки системы могут выступать различные бизнес-сервисы, часто выполняющиеся в «облачной» среде: базы данных, web-сервера, сервера приложений. В качестве дальнейшего развития модели были упомянуты более сложные функции распределения ресурсов, обладающие «памятью». Также было предложено рассмотреть варианты введения штрафов и поощрений для процесса за некоторые особенности его поведения.
Список литературы §
§
1. Белов С. Д., Ломакин С. В., Огородников В. А.
[и др.]. Анализ и моделирование трафика в вы- ¡^
сокопроизводительных компьютерных сетях // ^ Вестник НГУ. Т. 6. Новосибирск, 2008.
g
2. Голяндин А. Н, Шабанов А. П. Определение про- [g изводительности вычислительного комплекса § автоматизированной системы с централизован- ^ ным управлением. В кн.: Сборник тезисов докладов первой научно-практической конференции § «Информационные бизнес-системы». М., 2009. <§
5
3. Калиткин Н. Н. Численные методы. М.: Наука, g 1978. оо
4. Кудрявцев Л. Д. Краткий курс математического ® анализа. 3-е изд. М.: Физматлит, 2005.
5. Огородников В. А., Пригарин С. М., Родионов А. С. Квазигауссовская модель сетевого трафика // Автоматика и телемеханика. М., 2010.
6. Олифер В. Г., Олифер Н. А. Сетевые операционные системы: учеб. для вузов. СПб.: Питер, 2009.
7. Тормасов А. Г. Модель потребления ресурсов вычислительной системы // Вестник НГУ. Т. 4. Новосибирск, 2006.
8. GargAnkita. Real-Time Linux kernel scheduler // Linux Journal. 2009. URL: www.linuxjournal.com.
9. Gavin David. Performance monitoring tools for Linux // Linux Journal. 1998. URL: www.linuxjournal.com.
10. Kemp Juliet. Monitor linux system load and processes with atop // Linux Planet. 2009. URL: www.linuxplanet.com.
11. Layton Jeffrey B. Anatomy of SSDs // Linux Magazine. 2009. URL: www.linux-mag.com.
12. Layton Jeffrey B. I have a schedule to keep — IO schedulers // Linux Magazine. 2009. URL: www.linux-mag.com.
13. Love Robert. Kernel Korner — I/O schedulers // Linux Journal. 2004. URL: www.linuxjournal.com.
14. Dan Williams, Hani Jamjoom, Yew-Huey Liu, Hakim Weatherspoon. Overdriver: handling memory overload in an oversubscribed cloud // Proceedings of the 7th ACM SIGPLAN / SIGOPS international conference on Virtual execution environments. VEE'11. NewYork, NY, USA: ACM, 2011.
15. Rolland Dennis. 3 top trends in data protection for 2011 // Enterprise Systems Journal. 2011. URL: esj.com.
