CC BY
15
расположения стержней, причем с находящимися на них устройствами как в конструкциях ESE-молниеотводов (Early Streamer Emission -ранняя стримерная эмиссия) и т. д.
Следует отметить, что для исследуемой задачи показана особенность выявления как области, из которой возможно появление нис-
ходящего стримера, так и вероятности определения возможной точки восходящего стримера на основе численных расчетов ЭП и с учетом подхода [4]. Полученные выводы определяются соотношениями размеров исследуемой системы и соответствующими допущениями при их расчетах.
список литературы
1. Yang, Y. The strip simulation method for computing electric field on conductor surfaces [Текст] / Y. Yang, D. Dallaire, J. Ma [et al.] // Proc. of the 3 IASTED International Conf. on Power and Energy Systems. -Spain, Sept. 3-5 2003. -P. 353-357.
2. Базелян, Э.М Физика молнии и молниезащиты [Текст] / Э.М. Базелян, Ю.П. Райзер. -М.: Физматлит, 2001. -320 с.
3. Aleksic, S.R. Determination of critical atmospheric electric field around Franklin's lightning protection rod that leads to break-down [Текст] / S.R. Aleksic, S.S. Ilic // Acta Electrotechnica et Informatica. -2007. -№ 2. -Vol. 7. -Р. 3-9.
4. D'Alessandro, F. Electric field modelling of structures under thunderstorm conditions [Текст] / F. D'Alessandro, J.R. Gumley // Proc. of ICLP'1998. -Birmingham, Britain, 1998. -Р. 457-462.
5. Резинкина, М.М Расчет трехмерных электрических полей в системах, содержащих тонкие проволоки [Текст] / М.М. Резинкина // Электричество. -2005. -№ 1. -С. 44-49.
6. Потапенко, А.Н. Математическое моделиро-
вание поля давлений в многоэлектродных разрядных блоках [Текст] / А.Н. Потапенко, М.И. Дыльков, А.И. Штифанов // Изв. высших учебных заведений. Проблемы энергетики. -2003. -№ 9-10. -С. 120-124.
7. Потапенко, А.Н. Численное моделирование электрических полей в системах «электрод-поверхность земли» для элементов молниезащит [Текст] / А.Н. Потапенко, Е.А. Канунникова, М.И. Дыльков // Изв. высших учебных заведений. Проблемы энергетики. -2008. -№ 11-12. -С.72-78.
8. D'Alessandro, F. A 'Collection Volume Method' for the placement of air terminals for the protection of structures against lightning [Текст] / F. D'Alessandro, J.R. Gumley // J. of Electrostatics. -2001. -№ 50. - Р. 279-302.
9. Потапенко, А.Н. Исследование распределенных элементов систем молниезащит на основе вычислительных экспериментов [Текст] / А.Н. Потапенко, А.И. Штифанов, Т.А. Потапенко // Изв. Самарского научного центра РАН. -2010. -Т12. -№ 4 (3). -С.591-595.
10. Мак-Кракен, Д. Численные методы и программирование на Фортране [Текст] / Д. Мак-Кракен, У Дорн. - М.: Мир, 1977. - 584 с.
УДК 519.876.5
Ю.В. Тименков, Д.В. Тименкова, Е.П. Антышев
модель потребления ресурсов для взаимозависимых процессов с учетом истории обращений
Согласно исследованиям Datamonitor Group [1], объем рынка предоставляемых услуг в области IT составил в 2009 г. более 2 млрд долл. USA. Действительно, многим компаниям удобнее заказывать сервисы по разработке и поддержке программ на стороне, чем держать в своем штате программистов или системных администраторов. При этом современные компьютеры настолько производительны, что большую часть времени простаивают или работают не на полную мощность. Поэтому такие технологии, как
виртуализация, позволяют поставщикам услуг оптимально использовать время, безопасно исполняя на одной машине приложения нескольких клиентов.
Фирмы, предоставляющие такие сервисы, как аутсорсинг 1Т-услуг или облачные вычисления, подвергаются большому риску: ведь если случится сбой в центре обработки данных, то пострадает не один клиент, что может грозить многомиллионными убытками. Поэтому очень важно уметь управлять подобными рисками.
Для оптимизации использования оборудования применяются такие сервисные операции, как резервное копирование или миграция приложений с одного компьютера на другой. Но все они требуют системных ресурсов и могут существенно повлиять на работу программ. Поэтому провайдеры вынуждены постоянно искать компромисс между заявленным уровнем предоставляемых услуг (доступность для приложения процессора, диска, сети и т. д.) и накладными расходами на его поддержание.
Данная статья является продолжением [2], показывает дополнительные способы использования описанной там математической модели. В самом деле, сейчас сложно представить бизнес-приложение, которое исполняется в изоляции. Почти все подобные программы взаимодействуют друг с другом, с серверами баз данных, вебсерверами и т. д. Это создает дополнительные трудности для прогнозирования их работы, ведь в таком случае на скорость исполнения процесса влияет не только количество ресурсов, выделенных ему системой, но и то, насколько быстро работают приложения, от которых он зависит. В статье изучается один из методов моделирования подобных ситуаций.
1. Модель исполнения процесса
Для начала опишем исполнение процессов, которые не взаимодействуют, но являются конкурентами за системные ресурсы.
Сразу отметим, что данная модель рассматривает наблюдаемое снаружи потребление ресурсов программой во время ее исполнения, причем порядок исполнения инструкций известен заранее. Таким образом, нам не важна внутренняя структура приложения: его условные переходы, циклы и т. д. Рассмотрим программу развернуто как линейную последовательность инструкций, обработанных процессором.
Исполнение программы можно разбить на несколько участков или стадий исполнения. Они могут быть как логическими (получение запроса, его обработка и т. д.), так и физическими (исполнение команды процессора). Для завершения каждой стадии необходимо потребить некоторое количество компьютерных ресурсов, предоставляемых операционной системой. К ним относятся процессор, жесткий диск (при чтении/записи информации), сеть (для передачи данных) и др.
Рассмотрим исполнение программы на некоторой системе в отсутствие других потребителей ресурсов, т. е. когда ей полностью доступны все ресурсы компьютера. Назовем эту систему эталонной, а такой вариант исполнения - монопольным или эксклюзивным. В этом случае приложение переходит от одной стадии исполнения к другой с постоянной скоростью:
йх
u = -
dt'
(1)
Наиболее удобно определить стадию dx как монопольное исполнение процесса на эталонной системе в течение фиксированного промежутка времени. С одной стороны, это время должно быть мало, чтобы можно было проследить изменения в потребностях ресурсов на разных стадиях. С другой стороны, оно должно быть достаточным большим, чтобы сгладить дискретность работы планировщика. Для моделирования современных систем на основе Windows и Linux подходит величина в 100 мс, это составляет несколько квантов планировщика процессора.
Для исполнения каждой стадии процессу необходимо потребить некоторый набор ресурсов D = (Д.}. Это может быть количество байт, считанных или записанных на диск, тактов (секунд) исполнения на процессоре и т. д.
Обозначим вектор доступных ресурсов при монопольном исполнении как
L = (L }.
(2)
Эта величина характеризует производительность компьютера (мощность процессора, скорость чтения с диска и т. д.) и может меняться от одной системы к другой.
Пусть процесс в данный момент может получить от системы некоторый набор Я Ф И . Это может быть связано с тем, что процесс испытывает конкуренцию за ресурсы, либо исполняется на другой конфигурации компьютера. Введем понятие коэффициента недостаточности ресурса или коэффициент голодания:
1 = ^. (3)
Б
Данная величина показывает насколько больше или меньше ресурсов доступно для программы по сравнению с ее монопольным исполнением.
Очевидно, что для исполнения процессу нужны ресурсы именно в той пропорции, в которой они присутствуют в Б . Поэтому скорость исполнения будет ограничена наиболее недостаточным
ресурсом, а потребление остальных уменьшится пропорционально наименьшему коэффициенту голодания:
Y = min уг (4)
При этом результирующие скорость и уровни потребления будут:
u' = YU, (5)
R' = уD. (6)
2. Модель распределения компьютерных ресурсов
Опишем теперь способ распределения системой ресурсов между различными потребителями. Как и ранее, рассмотрим наблюдаемый снаружи результат, а не низкоуровневые процессы, протекающие внутри планировщиков. Последних существует большое множество, причем для разных типов ресурсов могут использоваться совершенно разные стратегии [3].
Такой подход позволяет описать функцию, показывающую распределение сразу всех типов ресурсов (потребление которых взаимосвязано). Например, при попытке выполнить операцию чтения с диска программа «отпускает» процессор, и если диск ей не выделили, будет наблюдаться снижение потребления процессора. Обратное тоже верно - если программе не дали процессорное время, она не сможет выполнить запрос к диску, несмотря на то, что последний может быть вполне доступен.
Хотя планировщики очень разные внутри, и каждый обладает своими особенностями и характеристиками, на макроуровне они всего лишь распределяют ресурсы между исполнителями, согласно приоритетам. Основное отличие заключается в обработке критических случаев, или в общей скорости работы (например, исследование дисковых планировщиков Linux проведено в [4]). В рассматриваемой модели этими эффектами можно либо пренебречь, либо они неявно входят в определение доступных лимитов L .
Путь в системе исполняются N процессов, каждый из которых имеет вес или приоритет Wj (хотя, в общем случае, приоритет может задаваться для каждого типа ресурса). Тогда планировщик готов каждому выделить долю ресурсов, равную - - W
Rj = . (7)
ж
k=0
Как было указано выше, процесс может потреблять не все что ему предоставили. С другой стороны, если один процесс не может потребить ресурс, он предоставляется другому - в реальных системах процессор загружен не на 100 % только в том случае, если он никому не требуется. Опишем следующим алгоритмом результат распределения ресурсов планировщиком с учетом возможностей всех потребителей.
• Из уравнения (7) вычисляем векторы доступных ресурсов Rj, где j e1...N - номер потребителя.
• Для каждого потребителя считаем коэффициент недостаточности по всем ресурсам и находим среди них минимальный:
Y j= min j (8)
' DJ
Важно отметить, что из рассмотрения исключаются ресурсы, которые не требуются процессу в данный момент (т. е. такие, для которых D' = 0).
• Процесс с наименьшим коэффициентом исключается из дальнейшего рассмотрения:
j'mn = argmin Yk. (9)
k
При этом
по уравнению вычисляем реальное количество ресурсов R' , которые он потребит;
jmin —
уменьшаем мощность системы L на данную величину, т. к. эти ресурсы уже не доступны для потребления:
l = L - R' . (10)
jmin
• Для оставшихся процессов проделываем эти же операции.
Таким образом, для всех процессов получены коэффициенты у j, показывающие, насколько в данных условиях процесс будет исполняться медленнее (или быстрее, в зависимости от соотношения L на текущей и эталонной системах). Теперь, используя уравнение (5), запишем уравнение исполнения процесса:
xj = | ujdt = | Yjuj dt. (11)
3. Типы взаимодействий
Большинство взаимодействий сводится к обмену какой-либо информацией. Это может быть ожидание какого-то сигнала или действия. Бывает так, что процессы (или потоки) разделяют какой-то общий ресурс, к которому оба имеют доступ. В
этом случае исполнение программы блокируется, если доступ занят другим приложением.
Весьма распространен вариант, когда один процесс является поставщиком данных для другого (который, в свою очередь, может также являться поставщиком для третьего и т. д.): например, веб-сервер, потребляющий данные от CGI-скрипта, сам является поставщиком для клиента, а CGI-скрипт может обращаться к серверу баз данных.
При этом общая производительность (к примеру, время, через которое клиент сможет получить страницу) сильно зависит от того, насколько система эффективно распределяет ресурсы. В этом и заключается основная сложность при управлении подобными процессами - результаты могут быть самыми разными. Так, если не дать процессор (например, если в это время появился процесс с более высоким приоритетом) CGI-скрипту в тот момент, когда он делает запрос к удаленной базе данных, то это никак не повлияет на его работу. Но если это произойдет когда он формирует страничку с ответом, то общая скорость обработки формирования отчета может упасть в разы.
Процессы по способу взаимодействия можно разделить на три группы.
Несвязанные. Одно приложение никак не зависит от другого и обмен информацией между ними не происходит. В таком случае, если остановить один процесс, другой будет продолжать работать.
Последовательные. Один процесс ждет завершения другого. Обмен информацией здесь односторонний: один процесс ждет сигнала к продолжению работы. Типичный пример - запуск программ из командного файла. Сюда же можно отнести и веб-сервер, передавший обработку запроса CGI-скрипту и ждущий его завершения.
Связанные. В этом случае возможность одного приложения исполняться непосредственно влияет на работу другого. Если любой из процессов останавливается или недополучает ресурсов, второй также замедляет свою работу. То есть благодаря двустороннему обмену информацией скорости исполнения процессов должны быть согласованы. Данный способ взаимодействия характерен для схемы producer-consumer. Примером является потоковая обработка файлов в командной строке Unix [5].
4. Моделирование зависимостей
Рассмотрим более подробно аспекты, возникающие при описании взаимодействие каждого из типов, на примере модели, представленной ранее и в [2].
Невзаимодействующие процессы являются только конкурентами за системные ресурсы, поэтому кинематическая модель к ним применима напрямую, без каких-либо модификаций.
Случай, когда одно приложение ожидает завершения второго, можно описать другими словами: одновременно может исполняться только один процесс. При такой формулировке становится очевидным, что подобные процессы можно рассматривать как один. То есть запуск второго приложения можно рассматривать как блокирующий вызов функции (в большинстве систем это так и есть).
Для моделирования тесно связанных процессов необходим более тонкий подход. Основной критерий выбора математического описания взаимодействия - согласованность скоростей процессов. В частности, модель должна удовлетворять следующим условиям:
при недостатке ресурсов у любого из процессов второй также должен замедляться, вплоть до полной остановки;
при наличии свободных ресурсов процессы должны иметь возможность исполняться со скоростью большей оригинальной (например, при моделировании более мощной системы).
При этом, для модели поставщик-потребитель допускается некоторая задержка в синхронизации скоростей. Это становится очевидным, если вспомнить природу явления. При таком обмене данными между поставщиком и потребителем существует некоторое количество буферов, позволяющих процессам выполняться более эффективно. Обычно это области памяти в ядре операционной системы, но могут быть и явно реализованные в программах (в [6] рассматриваются примеры обоих случаев).
Достаточно близка и аналогия с конвейерными вычислениями, когда результат одной стадии поставляется на вход другой. Но хотя одна порция данных может обрабатываться строго последовательно, разные стадии обслуживаются независимо.
5. Формализация модели Рассмотрим два процесса, один из которых
поставляет какие-то данные второму. Назовем первый процесс производителем и в дальнейшем будем использовать для него индекс Р. Второй, соответственно, потребителем и обозначим его индексом С.
Введем специальный вид ресурса, отвечающий за взаимодействие этих процессов. Назовем его обменным ресурсом. Конкретная интерпретация зависит от моделируемой задачи. Это может быть количество байт, переданных от поставщика к потребителю, количество запросов и т. д. Важно только, чтобы все потребленные ресурсы (включая обменные) можно было измерить или оценить, и они соответствовали друг дугу.
Пусть в результате работы производителя в течение времени Л образовалось количество ресурса, равное Яр . За то же самое время потребитель из них использует ЯС . Тогда к следующему моменту времени будет накоплено Яр - ЯС ресурса. Если эта величина положительная, то у потребителя будет преимущество, т. к. у него появится больше свободного ресурса для работы. Производитель, наоборот, должен будет замедлить свою работу.
Понятно, что в реальной жизни эта разность не может быть отрицательной, т. к. нельзя потреблять то, чего нет. Но для моделирования подобная ситуация вполне допустима. Это означает, что недостаток произведенного ресурса будет скомпенсирован в следующий момент времени соответствующим изменением скоростей потребителя и производителя.
Таким образом, критерий согласованности скоростей в каждый момент времени можно выразить с помощью следующей целевой функции:
|Яр - Яс1^ 0. (12)
Другими словами, чем больше у нас избыток ресурса, тем сильнее модель должна компенсировать скорости исполнения.
Опишем влияние разности в уровне потребления и производства обменного ресурса на скорости работы программ. Пусть в предыдущий момент времени было фактически произведено Яр-1 ресурса и потреблено ЯС-1 соответственно (считаем уровни в начальный момент нулевыми). Таким образом, в результате баланс уровней производства и потребления в текущий момент времени будет:
Как покажем далее, данная величина будет динамическим аналогом мощности источника для обычных (системных) ресурсов. То есть она определяет доступный лимит в данный момент времени, но при этом зависит от состояния и истории исполнения.
Обозначим заявленные уровни потребления и производства в текущий момент времени как Dnc и Dp соответственно. При условии, что процессы получат достаточное количество ресурсов, образуется разность ресурса
(14)
которую будет пытаться скомпенсировать планировщик. Данное уравнения является аналогом уравнений непрерывности в физике. Для удовлетворения критерия согласованности необходимо замедлить приложение, в сторону которого смещен баланс, и ускорить другой.
Исходя из физики явления предлагаем оценивать коэффициент недостаточности для обменных ресурсов по следующим формулам: т'
^ Т ' с' 7"тах
ТГ^, L -L , (15)
0 L' > Lmax
Г = Г + DnPdt -DC,dt,
Y p
1 —
для производителя и L'
Yc
Lm
+1,
0
L' > -Lm L' < -Lm
(16)
in _ r>n-1 ПИ-1
= Rp - KC .
(13)
для потребителя.
Здесь £шах - нормировочный множитель, определяющий степень толерантности к дисбалансу ресурсов. Его физический смысл - размер буфера между процессами, выраженный в тех же единицах, что и обменный ресурс.
Полученные значения участвуют в определении ограничивающего ресурса наравне с системными в алгоритме из раздела 2. После того, как определены коэффициенты недостаточности для каждого процесса, вычисляются реальные значения потребленных и произведенных данных Яр = уРВр Ж, ЯС = уСОС Ж, которые используются в следующий момент времени для определения баланса уровней потребления.
Нетрудно представить, что предлагаемая математическая модель хорошо удовлетворяет описанным выше условиям согласованности скоростей. К примеру, если случилась такая ситуация, что один процесс недополучил системных ресурсов, а второму, наоборот, дали их в избытке, то мо-
дель отреагирует на это при расчете следующего момента времени. Причем, если дисбаланс будет существенный, то процесс просто остановится. В результате таких отложенных компенсаций могут возникать колебания, которые и наблюдаются в численном эксперименте.
Этот подход можно применять для моделирования взаимной блокировки приложений, если потребуется описание доступа к некоторому ресурсу или моделирование ожидания одного приложения другим. Для этого всего лишь необходимо принять Гпях =0 и разрешать неопреде-I'
ленность шах как 0 . Таким образом, процессы
будут продолжать исполнение только в том случае, когда они оба дошли до определенной стадии исполнения.
6. Вычислительный алгоритм
Суть численного решения заключается в нахождении зависимости уровней ресурсов, выделенных каждому процессу, от времени. Для определения потребностей приложения необходимо вычислять интеграл. Он же определяет и время завершения процесса.
Единицы измерения. Для описания алгоритма вычисления необходимо прежде всего разобраться с размерностями величин, входящих в уравнения, и со способом получения входных данных.
Как было сказано в разделе 1, скорость исполнения приложения на эталонной системе постоянна, поэтому удобно ее взять тождественно равной единице. Таким образом, для определения П(х- необходимо знать, как система выделяла процессу ресурсы при монопольном исполнении Я(5) и времени работы X. Тогда функция потребности ресурсов определяется как
_(Я(х)их, х е [0,X], ч 0, х е [0, X ].
Для уровней ресурсов и их предельных мощностей удобнее всего выбрать размерность скорости потребления, например такты/с, Мб/с и т. д. При таком подходе будет кор ре ктно пр (5 дпол оже-ние о том, что если стадия может не завершиться за шаг интегрирования, то потребление будет уменьшено пропорционально невыполненной части. Другими словами, будет выполняться аналог закона сохранения для потребленного ресурса:
D( x) = -
(17)
J R'(t)dt = const,
(18)
независимо от скорости исполнения процесса
u (t) .
Для обменного ресурса ситуация несколько иная: потребность D, как и для системных ресурсов, имеет размерность скорости. А вот предел потребления L' и Lmax должен быть выражен в абсолютных единицах (байты и т. д.), т. к. в уравнении уже заложен множитель с размерностью времени.
Все дело в том, что системные ресурсы являются возобновляемыми. То есть в любой момент времени t система готова предоставить приложениям процессор или диск со своей максимальной производительностью, вне зависимости от того, сколько было использовано в предыдущий момент времени. Обменный ресурс, напротив, зависит от того, сколько его было использовано до этого.
Таким образом, для вычисления потребления ресурсов исполняющимися одновременно процессами, необходимо знать:
• D( xn) - функции потребности в ресурсах, заданные таблично. Измеряются в ед/с с помощью системных утилит типа perfmon (или из файловой системы /proc на Unix). Зависимость снимается для каждого приложения в отдельности, при этом необходимо полагать x = t;
• L - мощность источника ресурсов. Измеряется в тех же единицах, что и D(x), с помощью специальных утилит, тестирующих производительность. Либо можно воспользоваться результатами предыдущего пункта и оценить L как
L = maxD( x), (19)
D, x
причем максимум берется для каждой компоненты независимо.
численный метод. Зная, как получить исходные функции, можно приступить непосредственно к вычислению уровней потребления (6).
Подставим все функции для j -го процесса в уравнение (6):
Rj (t) = у j (t) Dj (xj (t)) = у j (D (x (t)), ...,
Dn ( xn (t))) Dj (xj (t)).
Функции x1 (t), ..., xN (t) являются интегралами с переменным верхним пределом .
Получается кольцевая зависимость: для вычисления x необходимо знание y , но при этом, чтобы ее рассчитать требуются потребности в ресурсах, зависящих от текущего прогресса исполнения. Для разрешения этой проблемы пред-
лагается следующий метод, основанный на вычислении интеграла с переменным верхним пределом, описанным в [7]. В нем предлагается выполнять интегрирование один раз и при этом заносить промежуточные данные в таблицу.
Для аппроксимации функций х) используем ступенчатую интерполяцию:
Б(х) = Б(х), г: х е[х,, хм). (21)
Тогда область интегрирования можно так разбить на участки, что на каждом из них функции потребления для всех процессов постоянны. В этом случае вычисление продвижения для каждого процесса не составляет никакой сложности и считается алгебраически:
хп+1= хП +гП(хП, ..., х;ХГ1 - Г), (22)
где (?и+1 - ) - интервал, на котором функции потребления постоянны.
Пусть мы находимся в точке , при этом известны текущие состояния процессов К, ..., хп;}. Тогда, зная уровни потребления Д (хП), ..., (хп;), можно вычислить для каждого процесса коэффициент недостаточности ресурсов чП по алгоритму из раздела 2. Так как у зависит только от Б, то функции ) также будут ступенчатыми, благодаря выбранному способу интерполяции.
Для нахождения момента очередного перераспределения ресурсов ^+1 необходимо вычислить время до скачка запросов для каждого процесса:
где х'к - ближайшая справа к х" точка, в которой известно значение табличной функции Б.. Тогда время следующего перераспределения ресурсов будет:
Г+1= е + штДО. (24)
.
Можно возразить, что используемая аппроксимация функций Б. является не самой лучшей, и ее погрешность очень высока. Но здесь надо вспомнить, что мы имеем дело с системой, где все происходит дискретно. К примеру, потребление процессора 60 % означает, что из десяти квантов приложение исполнялось шесть. Более того, выбранное в разделе 1 определение стадии исполнения также подразумевает ступенчатое изменение потребностей.
7. Описание эксперимента
Рассмотрим варианты применения изученного метода для прогнозирования исполнения программ на нескольких примерах. Достоверность модели оценим по времени исполнения задач и общему виду графика потребления ресурсов -т. е. по тем параметрам, которые можно пронаблюдать на любой системе с помощью утилит типа top или perfmon. Сразу оговоримся, что нас интересует общий вид графиков потребления: критические точки, соотношение между потребляемыми ресурсами и т. д. - этого вполне достаточно для практического применения задач. Поэтому давать количественные оценки совпадения графиков не имеет смысла.
Для этого эксперимента в качестве взаимодействующих процессов выбран генератор случайных чисел и архиватор gzip, взаимодействующие через pipe. Как оказалось, очень удобно использовать встроенный в Linux генератор случайных чисел. В качестве производителя использовалась команда: dd if=/dev/urandom bs = 4k count=125000. Задачу можно описать так: в одном процессе необходимо сгенерировать 500 Мб случайных чисел, а во втором - сжать полученную информацию и записать в файл.
Данный пример хорош тем, что позволяет получить истинные желаемые уровни потребления D для каждого процесса. Для этого процессы запускали по очереди, причем выходные данные от генератора случайных чисел записывались в файл на RAM-диске, а затем использовались для входных данных для архиватора. Тем самым удалось избежать дополнительных погрешностей, т. к. данные в этом случае поставлялись мгновенно (по сравнению с остальными затратами). К примеру, если бы файл располагался на обычном диске, то наблюдалось бы избыточное снижение скорости работы из-за обращений к диску, которых нет в случае взаимодействия напрямую.
Для большей точности все эксперименты ставились по десять раз, а результаты усреднялись. При этом, чтобы исключить влияние случайных внешних факторов, для каждой точки по оси времени исключались значения, являющиеся выбросами с вероятностью 90 %. Для определения, подчиняется ли подозрительная точка в последовательности закону нормального распределения, использовался Q-критерий, описанный Диксоном в [8].
4
Рис. 1. Потребление ресурсов (--------) CPU;
В результате, для каждого процесса получили следующий набор функций:
Dcpu (x) - доля времени, которую приложение исполнялось на процессоре;
Ddr (x) (disk read) и Ddw (x) (disk write) - скорости чтения и записи на диск. Сюда относятся данные, обработанные драйвером диска, т. е. которых не оказалось в системном буфере;
Dar (x) (application read) и Dw (x) (application write) - количество байт в секунду, считанных или записанных приложением через системные
при монопольном исполнении (-) DISK
вызовы. Данные величины отличаются от Dr и Ddw тем, что сюда попадают также данные, полученные из системного буфера или от других приложений через FIFO.
Графики потребления ресурсов при монопольном исполнении представлены на рис. 1.
8. Модель с последовательным исполнением
Сперва исследуем поведение модели для случая, когда поставщик и потребитель ресурсов последовательно исполняются на одном процес-
Рис. 2. Потребление ресурсов в эксперименте при исполнении на одном процессоре
(--------) CPU; (-) DISK
соре, тем самым конкурируя за его время. Чтобы этого добиться оба приложения запускались с явной привязкой к нулевому процессору.
Результаты эксперимента представлены на рис. 2. Как видно из графиков, данный эксперимент хорошо согласуется со следствиями из закона Амдала [9]: т. к. исполнение у нас последовательное, то полное время завершения будет равно сумме времен каждого процесса
T = TP + TC, (25)
где TP - время работы производителя при эксклюзивном запуске; TC - потребителя.
Опишем параметры, использованные для численного моделирования.
Набор ресурсов: процессор (cpu), диск (disk) и обменный ресурс (inter). Причем для диска бралась сумма записанных и считанных данных.
Лимит ресурсов:
L = {cpu = 1,0, disk = 10Mb/c, inter = 5Mb}. (26)
Скорость диска выбрана как ср ед шш производительность при случайном чтении. Для обменного ресурса буфер подобран так, чтобы вмещать в себя порцию данных, произведенных за несколько шагов интегрирования. Если его сделать очень маленьким, то модель будет показывать гораздо худшую производительность, чем есть на самом деле, т. к. процессы будут постоянно тормозиться из-за ожидания данных. Как показано в [6], размер системного буфера в Linux составляет 64 Кб,
(27)
а размер атомарной записи - всего 4 Кб. Тем не менее, на практике система достаточно хорошо справляется с планированием процессов, ожидающих ввода-вывода, поэтому эффективный лимит обменного ресурса значительно выше.
Функция запроса ресурсов производителем:
DP ={cpu = Dpu, disk = Ddd + DdW, inter = - DdW }.
Так как диск этим приложением не используется, то фактически Dpsk (x) = 0 . Для обменного ресурса выбрано количество байт, отправляемое приложением на запись, т. к. единственная запись, которая производится приложением -передача данных потребителю. Знак «минус» показывает, что программа является поставщиком ресурса.
Для потребителя запишем функцию запроса в виде:
DC = {-pu = Dpp, disk = Dg,- + DW,
(28)
inter = D** }.
ar >
Здесь, аналогично, обменным ресурсом являются байты, считанные приложением, т. к. они все поступили от производителя.
Результаты моделирования приведены на рис. 3. При сравнении графика с тем, что получилось в результате эксперимента, видно очень хорошее совпадение как по времени исполнения, так и по виду функций. Также на модельном гра-
Рис. 3. Потребление ресурсов при исполнении на одном процессоре, численное моделирование
(--------) CPU; (-) DISK
Рис. 4. Потребление ресурсов в эксперименте при исполнении на одном процессоре
(--------) CPU; (-) DISK
фике видны колебания, вызванные задержкой перераспределения ресурсов, которые были предсказаны ранее.
9. Модель с параллельным исполнением
Отличие от предыдущего эксперимента состоит в том, что взаимодействующие программы исполняются на разных процессорах параллельно. Если посмотреть на результаты эксклюзивного исполнения приложений, то видно, что архиватор отрабатывает примерно в три раза быстрее. Поэтому цель данного опыта - изучение поведения модели в случае, когда процесс ограничивается только обменным ресурсом. Второй при этом, будет исполняться монопольно, т. к. программы конкурируют только за процессор, а он, в данном эксперименте, полностью доступен каждому.
Перед запуском каждый процесс явно привязывался к своему ядру для минимизации эффектов, возникающих при смене контекста на процессоре. Результаты эксперимента представлены на рис. 4. Они являются следствием закона Амдала [9]: т. к. исполнение у нас паэаллельэое, то полное время завершения будет равно максимальному времени исполнения процесса
T = max(TP, TC). (29)
Для моделирования этой ситуации применен специальный прием, позволяющий «распараллелить» исполнение программ. Вместо одного про-
цессора явно введено два (cpu1 и cpu2), при этом каждое приложение требует только один из этих двух типов ресурсов. Хотя данный шаг и выглядит искусственно, он вполне точно описывает природу явления: процессы не могут так просто «перепрыгивать» с одного ядра на другое, при этом нельзя загрузить каждое больше, чем на 100 %. Такой же метод можно применять для моделирования чтения с разных дисков или передачи данных по разным сетевым интерфейсам и т. д.
Остальные ресурсы были такие же, как и в предыдущем эксперименте. Мощность системы:
L = {cpu1 = 1,0, cpu2 = 1,0, (30)
disk = 10Mb/c, inter = 5Mb}.
Функция потребностей производителя: DP ={cpu1 = Dcpu, cpu2 = 0, disk = Ddd + DdW, inter = - D^ }.
Функция запросов потребителя:
Dc ={cpu1 = 0, cpu2 = Dpp, disk = DgT + DW, inter = Dg? }.
Результаты моделирования приведены на рис. 5. Как и в предыдущем случае, получено очень хорошее совпадение и по времени исполнения, и по виду функций.
Как было показано выше, результаты численного моделирования очень хорошо сходятся с экс-
(31)
Рис. 5. Потребление ресурсов при исполнении на одном процессоре, численное моделирование
(--------) CPU; (-) DISK
периментом как количественно (время завершения процессов), так и качественно (зависимость выделенных процессу ресурсов от времени). К достоинствам предложенного метода относятся его простота и универсальность. Вычислительный алгоритм легко адаптируется к различному типу задач, при этом изменяются только входные данные.
При построении модели предполагалось, что распределение ресурсов не зависит от истории их потребления. Если для процессора и сети это условие выполняется всегда, то для диска это не так. При наличии буферизации чтения возмож-
ность предоставления ресурсов сильно зависит от истории обращений. К примеру, если процесс начинает впервые обращаться к данным, то скорость чтения будет значительно ниже, чем при чтении из кэша. Скорость диска зависит также и от характера нагрузки: последовательное чтение происходит быстрее, т. к. время не тратится на позиционирование головки.
Несмотря на описанные ограничения, предлагаемый метод хорошо подходит для моделирования работы приложений, работающих по схеме поставщик-потребитель.
список литературы
1. Datamonitor Group. Global top 10 software and services companies - industry, financial and SWOT analysis [Электронный ресурс] / Режим доступа: http:// www.datamonitor.com/
2. Тименков, Ю.В. Кинематическая модель исполнения процесса [Текст] / Ю.В. Тименков, Д.В. Тимен-кова // Математические модели и задачи управления. -2011. -С. 177-185.
3. Таненбаум, Э. Современные операционные системы [Текст] / Э. Таненбаум. -2-е изд. -СПб.: Питер,
2007. -1038 с.
4. Carroll, Aaron I/O scheduling on RAID [Текст]/ Carroll Aaron // Master's thesis. -School of Electrical Engineering, University of NSW, Sydney 2052, Australia,
2008.
5. Siever, Ellen. Linux in a Nutshell [Текст] / Ellen Siever, Stephen Figgins, Robert Love [et al.]; 6 ed. -O'Reilly Media, 2009. -P. 944.
6. Коньков, К.А. Основы операционных систем: Курс лекций [Текст] / К.А. Коньков, В.Е. Карпов. -2-е изд. -Интернет-Университет информационных технологий, 2009. -536 с.
7. Калиткин, Н.Н. Численные методы [Текст] / Н.Н. Калиткин. -М.: Наука, 1978. -512 с.
8. Dean, R.B. Simplified statistics for small numbers of observations [Текст] / R.B. Dean, W.J. Dixon // Anal. Chem. -1951. -Vol. 23. -№ 4. -P. 636-638.
9. Amdahl Gene. Validity of the single processor approach to achieving large-scale computing capabilities [Текст] / Gene Amdahl // AFIPS Conf. Proc. -1967. -Vol. 30. -P. 483-485.
