Математическое моделирование изменения рабочего набора процесса для интегральной живой миграции (1187402), страница 5
Текст из файла (страница 5)
Оно решается, например, с помощью алгоритма Левенберга-Марквардта [10]. Таким образомполучается аналитическая апроксимация графика насыщения рабочегонабора.3.3.2. Модель процесса живой миграцииНа основе найденной приближенной функции можно смоделироватьпроцесс миграции, предполагая что эта функция слабо меняется во времени. То-есть на каждой итерации есть некоторый размер накопленнойпамяти для передачи, время передачи этих данных можно оценить по ихразмеру и средней скорости передачи данных соединения. По полученному времени используя приближенную функцию можно определить объемновых данных который будет накоплен к началу следующей итерации. Итак получается модель реального итеративного процесса происходящегопри итеративной миграции.
Гдена i-той итерации,( )- объем грязной памяти накопленнойвремя на передачу блока памяти объемом M, aи d - найденные при аппроксимации параметры.+1 = × ( )( ) + (3.4)Этот итеративный процесс сходится. Так как приближенная функциянасыщения рабочего набора процесса непрерывна, монотонно возрастаети ограничена M(t) < 1, значит получающаяся последовательность времени передачи данных на каждой итерации, монотонно убывает и ограничена снизу нулем, что и значит сходимость процесса.26Так же необходимо учесть, что времени передачи блока данных непропорционально размеру этого блока. Есть некоторая задержка l(latency)при передаче данных в реальной сети. То-есть если M - размер данных,v - теоретическая скорость соединения, то время на передачу будет:( ) = × + +1 =(3.5) × ( × + ) × + + (3.6)Таким образом проведя достаточное количество итераций, можно определить приближенный инфимум необходимого для передачи времени, иколичество итераций для его достижения с некоторой заданной точностью.3.3.3.
ОптимизацияПри рассмотрении модели итераций пока не учитывалось, что дляснятия снимка на каждой итерации требуется некоторый интервал времени. Если включить его в модель, то можно посчитать такую характеристику процесса как суммарное время простоя мигрируемой программы-∑︀ .Время для снятия снимка можно считать не изменяющимся от ите-рации к итерации, так как основную нагрузку создает то, что при снятии снимка необходимо делать полный обход памяти процесса и проверять каждую страницу на предмет ее изменения с момента предыдущегоснимка.Тогда суммарное время простоя на i итерации будет:∑︀ () = ( − 1) × Δ + ().ГдеΔ— время простоя для снятия снимка,()(3.7)— время для передачи() сходится к инфимуму при( − 1)Δ линейно возрастает, то угрязной памяти на i итерации.
Так какi стремящемуся к бесконечности апоследовательности∑︀ ()сумм, существует минимум.То-есть используя предложенную модель можно определить количество итераций в процессе миграции необходимое для минимизации суммарного времени простоя. Суммарное время простоя, в свою очередь27характеризует влияние процесса миграции на среднюю скорость работыпроцесса.
Таким образом минимизация этого влияния является важнымпараметром для живой миграции, так как живая миграция это миграцияпроцесса при которой не происходит разрыва соединения.3.3.4. Выбор функцииТак же для аппроксимации графика насыщения рабочего набора можно использовать другие “подходящие” аналитические функции. Процесснасыщения рабочего набора приложения в начале имеет большую скорость насыщения, это обосновано тем, что вся память которая ему доступна в начале “чистая” и каждый запрос на запись добавляет грязныестраницы. Но со временем когда большая часть памяти уже стала “грязной” вероятность, что запрос на запись попадет в “чистую” страницустановится пропорционально меньше, в предположении, что распределение вероятности попасть в некоторую определенную страницу равномерное.
Таким образом аппроксимирующая функция должна быть выпуклавверх. Так же функция должна монотонно возрастать, так как размергрязной памяти не может уменьшится1и быть ограничена сверху. Былирассмотрены различные функции например: () = × ( × ); ⊂ [0, ∞]1 () = × − × ; ⊂ [0, ∞](3.9)⎧⎨ × , ⊂ [0, ]; () =⎩ × , ⊂ [, ∞];(3.10) () =1 Хотя(3.8)×; ⊂ [0, ∞]+(3.11)на практике это не так, например если приложение освобождает память, но в рамках этойработы рассмотрена упрощенная модель взаимодействия с памятью.28Рис. 3.1: Мониторинг и аппроксимация29память(Мб)010020030040050060070080000.51время(сек)1.522.5Размер грязной памятиРазмер рабочего набораПриближение функцией a*t/(t+d)Зависимость насыщения рабочего набора процесса от времяни3Рис.
3.2: Модель миграции30размер накопленной грязной памяти(MB)010020030040050060070080000.51время(сек)1.522.5Насыщение грязной памятиГрафик миграции, параметры d = 2.730000, a = 1748.0000003Рис. 3.3: Оптимизация миграции31Глава 4. Практическая частьВ рамках данной дипломной работы были решены три практическихзадачи:1. Добавление поддержки Posix-таймеров в CRIU;2. Добавление дедупликации итеративных снимков в CRIU;3. Написание системы предсказания окончания миграции.Первая задача является вводной задачей для изучения архитектуры проекта CRIU, вторая задача имеет непосредственную важность для использования оперативной памяти при создании и хранении итеративных снимков, что необходимо для ускорения процесса миграции.
Третьязадача заключалась в написании алгоритма на основе полученной математической модели с целью ее обоснования.4.1. POSIX-ТаймерыВ CRIU, в рамках подготовительного изучения системы и вводного задания была добавлена поддержка posix-таймеров. То-есть добавлена функциональность сохранения и восстановления таймеров стандартаPOSIX.POSIX-таймеры это интервальные таймеры поддерживаемые операционной системой Линукс. Они имеют ряд преимуществ перед обычнымитаймерами UNIX:1.
Процесс может иметь несколько таймеров.2. Лучшая точность таймеров. Таймеры могут использовать значенияс точностью до наносекунд.3. Уведомление о завершении работы таймера может быть сделанолибо с помощью любого произвольного сигнала (реального времени) или с помощью потоков. Для уведомление о завершении работы32таймера в обычных таймерах UNIX есть лишь ограниченный наборсигналов.4. Таймеры POSIX.1b предоставляют поддержку различных типовчасов, таких как CLOCK_REALTIME, CLOCK_MONOTONIC, итак далее, которые могут иметь различные источники с различнымразрешением. Обычный таймер UNIX, с другой стороны, связан ссистемными часами.Функциональность сохранения и восстановления posix-таймеров разрабатывалась с оглядкой на реализацию подобной функциональностидля itimers(обычные интервальные таймеры), в которой, в процессе работы, были найдены и исправлены ошибки, и на основе функциональности для POSIX-часов.
В начале CRIU при сохранении состояния деревапроцессов, для каждого процесса, для объектов ядра для которых этонеобходимо, вызывает модули получения информации из файловой системы proc.4.1.1. Использование файловой системы procfsФайловая система procfs является основным используемым интерфейсом Для сохранения состояния posix-таймеров из пространства пользователя, весной 2013 года был принят патч [7] в ядро Линукс, отображающий основную информацию объектов struct k_itimer хранящих состояние posix-таймеров, с помощью интерфейса seq_file. Таким образомчитая файл /proc/<pid>/timers получаем список таймеров используемых процессом.
Для каждого posix-таймера, считывается уникальныйномер таймера - ID, информация о способе прихода оповещения о срабатывании таймера и информация о часах с которыми связан таймер. Всеэто сохраняется в динамический список и CRIU переходит на следущийэтап.Патч в ядро LinuxДля отображения ClockID - уникального номера часов к которымпривязан posix-таймер, необходимого для восстановления таймера, был33написан патч [8] в ядро Линукс. Так как предыдущая реализация /proc/<pid>/timers не содержала этой критичной информации и другие интерфейсы ядра не предоставляли к ней доступа, то полностью восстановить таймеры было не возможно.
По этому было решено расширитьфункциональность ядра.Пример содержимого файла, для процесса с двумя таймерами:cat / proc / < pid >/ timersID : 21signal : 12/( null )notify : signal / pid .25907ClockID : 1ID : 10signal : 10/00000000006062 a0notify : signal / pid .25907ClockID : 04.1.2. Системные вызовыПосле считывания основной информации о таймерах из файловойсистемы Procfs, используя интерфейс ptrace, CRIU встраивается в сохраняемый процесс. Список с информацией о posix-таймерах необходим для работы с ними из под контекста сохраняемого процесса, соответственно был добавлен перенос этих данных в память процесса используя аналогичные механизмы для других объектов.
Далее зная какие есть таймеры можно используя системные вызовы timer_gettime() иtimer_getoverrun() получить значения оставшегося времени до срабатывания таймера и количество итераций таймера, когда таймер не сработализ-за блокировки сигналов. После этого данные возвращаются в контекстCRIU, а контекст сохраняемого процесса чистится от инъекций памятии приводится в свое состояние до подключения к нему CRIU. Все данныесохраняются в снимки с использованием формата Google Protobuf.При восстановлении воссоздается дерево процессов и для каждогопроцесса по очереди восстанавливаются все per-process объекты. Длявосстановления posix-таймеров используются системные вызовы работыс таймерами timer_create() и timer_settime(), с параметрами полученными при сохранении процесса, для воссоздания и запуска таймеров.34Основной сложностью при восстановлении posix-таймеров являетсято, что ядро Линукс не предоставляет интерфейса для восстановлениятаймера с определенным идентификационным номером, по этому предложенный алгоритм использует то что таймеры ядром создаются в порядке возрастания ID(timer_create()).
То-есть, сохраненные таймеры сортируются в порядке возрастания ID, и CRIU пытается восстанавливатьих в этом порядке. Пусть например наименьший ID = 5, тогда чтобыего восстановить создаются таймеры 1-4, а потом воссоздается пятый. Вконце все лишние таймеры удаляются.4.1.3.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
