Г. Долгопрудный 2014



Скачать 488.1 Kb.
страница1/4
Дата17.11.2018
Размер488.1 Kb.
ТипДиссертация
  1   2   3   4


Министерство образования и науки Российской Федерации

МОСКОВСКИЙ ФИЗИКО-ТЕХНИЧЕСКИЙ ИНСТИТУТ
(государственный университет)


ФАКУЛЬТЕТ УПРАВЛЕНИЯ И ПРИКЛАДНОЙ МАТЕМАТИКИ

КАФЕДРА ТЕОРЕТИЧЕСКОЙ И ПРИКЛАДНОЙ ИНФОРМАТИКИ

Специализация 010956 «Математические и информационные технологии»


ПРОФИЛИРОВАНИЕ ЭНЕРГОПОТРЕБЛЕНИЯ ВИРТУАЛЬНЫХ МАШИН

Магистерская диссертация

студента 873 группы

Карпова Дмитрия Викторовича

Научный руководитель

Мелехова А.Л.


г. Долгопрудный

2014

Содержание

Введение………………………………………………………………………………8

  1. Постановка задачи

    1. Структура энергопотребления ……………………………………………….9

    2. Обзор средств и методик профилирования энергопотребления…………...9

    3. Устройство техник профилирования энергопотребления………………….13

    4. Инструменты Power-management, доступные разработчику ………………17

    5. Инструмены энергопрофилирования ………………………………………..19

    6. Утилиты измерения энергопотребления……………………………………..20

    7. Ряд техник по улучшению энергоэффективности ……………………….....23

  2. Разработка алгоритма мониторинга энергопотребления

    1. Критерии эффективности алгоритма ………………………………………..25

    2. Составные части энергопотребления ………………………………………..26

    3. Методы, регулирующие объем энергопотребления………………………...26

    4. Основные инструменты измерения и профилирования энергопотребления 28

    5. Анализ существующих алгоритмов мониторинга энергопотребления …...28

  3. Описание алгоритма

3.1.Контексты исполнения……………………………………………………….29

3.2.Размещение в контексте хостовой ОС……………………………………....30

3.3.Размещение в гостевом контексте и в гостевой ОС………………………..31

3.4.Размещение в контексте монитора виртуальных машин…………………..31

3.5.Переключение контекста……………………………………………………..31

3.6.Обработка прерываний……………………………………………………….32

3.7.Описание механизма подсчета……………………………………………….32


  1. Тестирование алгоритма

4.1. Описание тестового стенда…………………………………………………..34

4.2. Тестовые сценарии и результаты тестирования…………………………....34

4.3. График отклонения измерений……………………………………………....34

4.4. Обоснование и выводы………………………………………………………39



  1. Задача разработки энергоэффективного ПО

5.1. Определение энергоэффективности ПО…………………………………….41

5.2. Описание экспериментов…………………………………………………….41

5.3. Математическая модель……………………………………………………....45

5.4. Оптимальное энергоэффективное распределение виртуальных процессов/сервисов по серверам, смоделированное многомерной задачей упаковки в контейнеры……………………………………………………………47



  1. Заключение………………………………………………………………………..49

  2. Список литературы……………………………………………………………....51

Глоссарий

Понятие

Сокращение

Определение понятия

Виртуальное окружение




изолированная среда для исполнения системного программного обеспечения и прикладного программного обеспечения клиента

Хостинг




предоставление аппаратных и системных ресурсов клиенту

Гостевая операционная система

гостевая ОС

системное программное обеспечение запущенное внутри виртуального окружения

Ядро операционной системы

ядро ОС

центральная программа операционной системы (ОС), обеспечивающая приложениям координированный доступ к ресурсам

Модуль ядра операционной системы

модуль ядра ОС

программа, содержащая код, расширяющий возможности ядра операционной системы, исполняемая, как и ядро ОС, в привелегированном режиме

Хостовая операционная система

хостовая ОС

системное программное обеспечение, в котором работает программное обеспечение виртуализации

Монитор виртуальных машин




Программное обеспечение, непосредственно создающее изолированные среды, запускающее виртуальное окружение и обеспечивающее получение ресурсов для виртуального окружения от гипервизора (хостовой ОС)

Гипервизор




Программное обеспечение, позволяющее одновременное исполнение нескольких виртуальных окружений на одной и той же физической машине (является выделенной частью хостовой ОС)

Миграция




перенос ИПР или виртуального окружения с ИПР с одного физического сервера на другой

Живая миграция




перенос ИПР или виртуального окружения с ИПР с одного физического сервера на другой без остановки работы ИПР

Горячая миграция




см. живая миграция

Архитектура микропроцессора




аппаратная организация и логическая структура микропроцессора, регистры, управляющие схемы, арифметико-логические устройства, запоминающие устройства и связывающие их информационные магистрали

Микроархитектура




способ, которым набор команд (инструкций) реализован в микропроцессоре

Ядро микропроцессора




часть микропроцессора, осуществляющая выполнение одного потока команд. Многоядерные микропроцессоры имеют несколько ядер и поэтому способны осуществлять независимое параллельное выполнение нескольких потоков команд одновременно

Архитектура микропроцессоров семейства x86

Архитектура x86, семейство микропроцессоров х86

архитектура микропроцессоров c одноимённым набором команд и правилами их исполнения, впервые реализованная вмикропроцессорах компании Intel

Платформа х86




аппаратная модель вычислительной системы на основе семейства микропроцессоров х86

Module Specific Register

MSR

Паравиртуализованные моделеспецифичные регистры

Регистры микропроцессора




специальные ячейки памяти, образующие сверхбыструю оперативную память внутри микропроцессора и расположенные физически внутри него

ACPI




усовершенствованный интерфейс управления конфигурацией и питанием платформы х86

Running Average Power Limit

RAPL

Скользящее среднее предельное значение мощности

RAPL – итерфейс




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

Контекст исполнения программного модуля

Контекст исполнения

Каждый программный модуль связан с остальной частью программных модулей, выполняющих определенный круг задач и имеющих определенные уровни привелегий. Эта связь называется контекстом исполнения программного модуля.

Контекст процесса




состояние исполняемой программы (или программ), определяемое информационными структурами, значениями используемых регистров микропроцессора, значениями, хранимыми в специальных таблицах параметров процесса, текущими значениями переменных, а также содержимым стэков (специальной памяти) задачи и операционной системы, относящихся к данному процессу.

Переключение контекста




прекращения выполнения микропроцессором одной задачи (процесса) или контекста исполнения с сохранением всей необходимой информации и состояния, необходимых для последующего продолжения с прерванного места, и восстановления состояния другой задачи или контекста исполнения, к выполнению которой переходит микропроцессор.

Введение

Проблемы энергосбережения и оптимизации энергопотребления наряду с проблемами экологии наиболее значимы в современном мире. И вопрос энергопотребления стоит очень остро, особенно для разработчиков программного обеспечения, которым всегда необходимо понимать, сколько энергии потребляется приложениями и операционной системой. Традиционные методы оценки использования энергии и энергопотребления платформы всегда оставались довольно тяжелой задачей, включающей в себя специальные средства, инструментарий аппаратной платформы и оборудование сторонних производителей. Не каждый может себе позволить такие аппаратные измерители мощности. Поэтому, появился повод создать программные средства для измерения и профилирования энергопотребления, предназначенные для конечных пользователей и разработчиков, которым нужна точная оценка энергопотребления на программном уровне без включения каких-либо аппаратных инструментов.



Постановка задачи

В современных облачных технологиях одним из важных вопросов является управление вычислительными ресурсами. Одним из направлений такого управления ресурсами является управление энергопотреблением. Этот вопрос является очень актуальным в свете высоких показателей затрат, связанных с электроснабжением облачных систем и их охлаждением. Это значит, что увеличение энергоэффективности облачных систем даже на несколько процентов позволить высвободить значительные денежные суммы.

Задача нахождения оптимального управления энергопотреблением виртуального окружения включала в себя следующие этапы:

Для начала был разработан алгоритм учета энергопотребления виртуальной машиной. Затем с помощью него были получены данные о реальном энергопотреблении (произведен мониторинг) виртуального окружения. Далее полученные данные исследовались на предмет увеличения энергоэффективности виртуальных машин и виртуальных сервисов, с целью оптимальной организации энергопотребления как отдельных виртуальных машин, так и всей облачной инфраструктуры в целом.



    1. Структура энергопотребления.

В работе [30] было показано, что энергопотребление платформы можно структурировать, разделив его на две части:

Статическая часть включает в себя затраты на поддержание платформы в рабочем состоянии (например, энергия, потребляемая кулером, материнской платой, и т. Д.). Она имеет слабую корреляцию с природой исполняемых приложений, поэтому интересует нас в меньшей степени – мы не можем контролировать эту часть энергопотребления.

Динамическая часть связана с исполнением приложений. Поскольку эта часть сильно зависит от характеристик загрузки, степени утилизации ресурсов и политики энергопотребления, она может сильно варьироваться. Именно здесь имеется большой простор для оптимизации, так как ПО вносит серьезный вклад в общее энергопотребление системы [2][5].

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



    1. Обзор средств и методик профилирования энергопотребления

Во многих работах [24] описывается использование Hardware Performance Counter для построения энергозатратной модели и расчета потребления энергии в системе. Там установлено, что целочисленные операции, операции с плавающей точкой, строб адреса и операции обращения к памяти сильно связаны с расходом энергии процессором. Также, в других работах [25]

используются иные HPC для построения модели энергопотребления – число выполненных инструкции, промахи кэша и промахи tlb. Там также установлено, что IPC (instructions per cycle) сильно коррелирует с энергозатратами. Некоторые части ОС работают с постоянными энергозатратами, а затраты на другие части, например на планировщик и операции ввода-вывода, сильно зависят от IPC.

В [26] установлен метод вычисления энергопотребления отдельных задач. Для низкоуровневого анализа мощности и расхода энергии используются довольно точные средства, такие как Wattch и SimplePower.

Из высокоуровневого анализа есть средство pTopW (Process-Level Power Profiling Tool) для профилирования энергопотребления в Windows (на ее основе сделаны средства контроля энергопотребления – EnergyGuard и BatteryLife). pTopp – в Linux. pTopp и pTopW представляют информацию в реальном времени по потреблению энергии каждым процессом. Также они предоставляют API, с помощью которого любой процесс может определить, сколько энергии он потратил в предыдущий период времени. Там построена модель для измерения энергопотребления CPU, памяти, диска и сетевой карты. После измерения энергопотребления CPU, они делят его на каждый процесс, основываясь на отношении процессорного времени.



Есть средство CloudMonitor, которое также представляет информацию по энергопотреблению софта. Там строится модель оценки мощности, используя линейную регрессию.

В довольно большой работе [27] рассматривается майкрософтовское средство Joulemeter (http://research.microsoft.com/en-us/projects/joulemeter/) для измерения потребления энергии виртуальными машинами (и не только ими). Так как использование мощности процессором зависит от множества факторов, в качестве альтернативы они следят за активным и неактивным состоянием процессора, т.е. за загруженностью процессора U. Далее строят модель энергопотребления процессора как E_cpu = A * U + B, где A и B – постоянные параметры данной модели. Далее используют обучающий метод, основанный на линейной регрессии для оценки этих параметров. Для составления уравнений регрессии каждый ресурс (процессор, память и диск ) загружаются под контролируемой нагрузкой (workload). То есть когда загружается новая ВМ, использование ею ресурсов прослеживается в течение 200 секунд, и полученные данные используются в модели регрессии. Эта модель обучения хороша, когда энергозатраты есть линейная функция загруженности процессора. Но есть и другие случаи, поэтому в работе представлена улучшенная модель обучения с немного откорректированными уравнениями модели энергопотребления. В их подходе, они следят, когда виртуальная машина активна на процессоре. И количество используемой энергии вычисляется по формуле выше, во время периодов активности ВМ. Они пользуются тем фактом, что, например, гипервизор Hyper-V создает виртуальные процессоры, которые могут охватывать целый или дробную часть логического ядра, и передает специальные значения соответствующие этому, каждой ВМ. Также Hyper-V позволяет следить за использованием виртуальных процессоров из корневой ВМ с помощью его performance counters – Hyper-V Hypervisor Virtual Processor и Hyper-V Hypervisor Root Virtual Processor. Используя настройки гипервизора, которые соотносят виртуальные ядра с логическими, использование энергозатрат виртуальных процессоров может маппироваться (отображаться) на загруженность физических процессоров. Такие же данные доступны и для гипервизора Xen через Xentrace. Для данной конкретной загрузки процессора реальная используемая мощность может варьироваться в зависимости от типа используемой нагрузки (Workload). И различия могут быть довольно большими. Чтобы посмотреть на точность оценки используемой виртуальной машиной энергии, как мера точность используется разница между фактической мощностью физического сервера и суммой мощностей всех ВМ и idle server power usage. В этой работе для оценки параметров модели используется метод линейной регрессии, а в работе [28] используется метод построения модели, основанный на многомерных распределениях гаусса, превосходящий регрессионную модель, основанную на загруженности процессора, по точности более чем в 5 раз (как утверждают авторы). В данной работе представлен онлайн (в режиме реального времени) механизм предсказания энергопотребления в виртуализованной среде. Их система основана на модели, которая соотносит потребление мощности с системными метриками (IPC, частота доступа к памяти и д.р.) нагрузок, запущенных в ВМ. Эти метрики динамически собираются на уровне ВМ и пересылаются в модуль предсказания энергозатрат. Модель основана на Gaussian Mixture Models, использующей алгоритм обучения на небольшом количестве бенчмарков из SPEC_CPU2000. Они реализовали собственный performance counter manager внутри планировщика Xen для измерения IPC, MPC (memory accesses per cycle), CTPC (cache transactions per cycle) запущенных ВМ. Т.е. они динамически снимают эти метрики с каждого VCPU, когда они рассщедуливаются на физических cpu. Вся эта информация собирается приложением, сидящим в dom-0, группируется в метрические векторы и анализируется методом Gaussian Mixture Models (GMM), который состоит из набора распределений гаусса, используемых для нахождения всех возможных взаимодействий между собранными метриками. Далее у них представлен механизм, как эти метрики отображаются на реальное энергопотребление: идет тренировочная фаза, когда GMM работает на типичных бенчмарках, показывающих разные уровни взаимодействия метрик. Как только GMM сформирован, он используется для прогноза мощности в режиме реального времени.

В [29] приводится характеристика всех известных методов power profiling. Перечислено большое количество софтварных и хардварных методов. Но для виртуализации там ничего нового нет, кроме того что уже перечислено выше.



    1. Устройство техник профилирования энергопотребления

Известно, что наибольший вклад в энергопотребление платформы вносит процессор. В связи с этим компании Intel, Microsoft и некоторые другие представили свои средства измерения мощности. Каждое из них собирает различные данные разными способами. Для начала стоит немного сказать об основных аппаратных средствах измерения энергопотребления, предоставляемых платформой. В их число входят MSR (Model-Specific Registers) и HPC (Hardware Performance Counters). Со встроенных в оборудование датчиков и счетчиков HPC собираются данные для определения того, какие события сильно коррелируют с потреблением энергии. Далее, на основании того на сколько сильна эта взаимосвязь между данными HPC и энергопотреблением, строится модель прогнозирования будущих энергозатрат. MSR-ы используются для мониторинга производительности и контроля датчиков оборудования. Доступ к этим регистрам можно получить с помощью двух инструкций – rdmsr и wrmsr. Доступ к MSR из пространства пользователя в Linux осуществляется через модуль ядра, который называется msr. Когда этот модуль загружен, открывается доступ к интерфейсу /dev/cpu/x/msr. Этот файловый интерфейс предназначен для чтения и записи в любой MSR на данном CPU. MSR-ами программируется один из основных механизмов определения энергопотрбления - это RAPL интерфейс (Running Average Power Limit). RAPL MSR-ы предоставляют доступ к внутрипроцессорным датчикам мощности (поэтому поддерживаются процессоры Sandy Bridge, Ivy Bridge и более новые). Например, RAPL_PKG_ENERGY_STATUS MSR используется как счетчик, определяющий количество ватт, потребленное системой с момента запуска. А регистр RAPL_POWER_UNIT содержит данные, переводящие значение счетчика в реальные цифры потребляемой мощности и энергии. Помимо MSR и HPC, при замерах важно следить за частотой переключения уровней энергопотребления при помощи технологий Intel C-states и P-states, на основе которых определяется схема энергопотребления процессора с помощью стандарта Advanced Configuration and Power Interface (ACPI).

Самым простым инструментом измерения энергопотребления можно назвать Joulemeter от Microsoft. В основе его расчетов лежат данные о потреблении специфической программой или виртуальной машиной аппаратных ресурсов системы – центрального процессора, жестких дисков, памяти, дисплея и др. Эти сведения конвертируются в показатели фактического энергопотребления, что достигается за счет чтения значений некоторых MSR-ов, как например MSR_PKG_ENERGY_STATUS, MSR_FUNC_POWER, и некоторых HPC, например - CPU_CLK_UNHALTED.CORE и CPU_CLK_UNHALTED.REF (процент времени, в течение которого процессор активен за определенный интервал времени). Для оценки энергопотребления памяти используется last level cache (LLC) miss counter. Также для прогнозирования включен механизм использования P- и C-states, которые учитываются следующим образом: для данного состояния считается утилизация процессора через HPC, и тогда общее потребление за определенный промежуток времени - это произведение этой утилизации на некоторый коэффициент, для вычисления которого используется механизм обучения на основе линейной регрессии.

Joulemeter весьма неплохое средство, но оно все же уступает место следующему инструменту оценки энергопотребления - PowerTop в виду его большей информативности и открытому исходному коду. PowerTop предоставляет информацию по уровню потребления энергии каждым процессом в режиме реального времени. Это достигнуто с помощью деления общего потребления энергии в системе (берется из ACPI) по времени исполнения каждого процесса на процессоре в микросекундах за секунду. Механизм измерения построен на системных профилировщиках. PowerTop собирает информацию из различных источников ядра (таких как /proc, /sys, ACPI) и отображает результат работы системы в одном окне так, что можно увидеть насколько хорошо работает система, и какие компоненты наиболее проблемные. Одним из преимуществ PowerTop является то, что он может находить программные компоненты, которые вынуждают систему потреблять больше энергии, чем это необходимо, в то время как она находится в режиме ожидания. Также преимуществом является достаточно большая информативность: wakeups (пробуждение в секунду), информация о состоянии С- и P- states, потребляемая мощность, оценку, сколько часов работы от батареи осталось.

Самое точное и простое по устройству средство профилирования энергопотребления - это Intel PowerGadget. Для оценки используется работа с RAPL MSR-ами. Среди дополнительных функций - измерения потребляемой мощности многопроцессорными системами, а также вызываемые извне API для извлечения данных о потребляемой мощности в коде.

Далее кратко описаны еще несколько средств измерения энергопотребления, которые менее практичны из-за недоступной программной реализации. VMeter может прогнозировать общее потребление энергии, основан на Oprofile, следит за некоторыми HPC: CPU_CLK_UNHALTED, DRAM_ACCESSES, INSTRUCTION_CACHE_FETCHES, DATA_CACHE_FETCHES, которые имеют большую корреляцию с потреблением энергии, и проецирует их на реальное энергопотребление. К сожалению, вначале должен подключаться PDU (Power distribution units) и снимаются общие данные. CloudMonitor - может прогнозировать общее энергопотребление всей машины после того, как модель будет обучена на конкретной конфигурации железа. Модель потребления построена на основании использования ресурсов: CPU, память, диск, сеть.

Помимо средств профилирования, для создания энергоэффективных приложений разработчикам необходимо выполнять определенные условия. Например, согласно данным компании Intel, для уменьшения и оптимизации энергопотребления приложениям нужно соблюдать следующие требования:



  1. уменьшение количества ресурсов приложения при использовании батареи;

  2. использование аппаратных средств сбережения энергии: при помощи C3-state и координирования взаимодействия между ядрами одного процессора;

  3. корректное исполнение переходов между S1 - S4 состояниями;

  4. поддержка работы процессора на высоких P-states, когда не требуется слишком большая производительность;

  5. поддержка работы процессора на более глубоких С-states в отсутствие частой активности процессора.

Также необходимо перечислить некоторые платформозависимые возможности оптимизации энергопотребления:

1) выключение неиспользуемых устройств.

2) При разработке network-intensive приложений, это касается переключения на LAN с WLAN при подключении обоих, пересылка данных по WLAN большими частями, чтобы Wi-Fi карточка была в более низком режиме потребления.

3) Избегать частого обращения к диску.

Даже если у разработчика нет профилировщика энергопотребления или нет возможности его приобрести, для измерения потребляемой мощности разрабатываемых программ можно использовать программные средства, описанные выше. Каждое из них обладает разными возможностями, разными требованиями к системе, и отслеживает потребление электроэнергии разными программными и аппаратными компонентами.




    1. Поделитесь с Вашими друзьями:
  1   2   3   4


База данных защищена авторским правом ©vossta.ru 2019
обратиться к администрации

    Главная страница