Software & Systems

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

.

Рис. 1. Архитектура системы профилирования

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

В настоящее время в рамках разработанного в НИИСИ инструментального комплекса СОМ (система отладки/мониторинга) [1] ведутся работы по созданию системы профилирования целевых систем, функционирующих в условиях дефицита ресурсов. Требования к системе профилирования:

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

2)  обеспечение сбора информации о следующих целевых ресурсах:

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

-     память, используемая программой,

-     аппаратные события (при их наличии), возникающие в ходе выполнения программы,

-     сетевые интерфейсы, используемые программой;

3)  использование соответствующих интерфейсов при наличии аппаратной поддержки профилирования;

4)  использование стандартных средств и механизмов для возможности последующей интеграции с существующими решениями при реализации системы профилирования.

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

Система профилирования представляет собой распределенное приложение, состоящее из:

·     компонента ядра профилируемой системы (драйвера);

·     агента профилирования, выполняющегося на целевой машине (демона профилирования);

·     библиотеки профилирования, содержащей вызовы функций для инструментовки кода;

·     менеджера профилирования на инструментальной стороне;

·     базы данных для хранения собранной информации (БД событий);

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

Архитектура системы профилирования представлена на рисунке 1.

События профилирования. Различают простые и составные события профилирования. Простое событие содержит информацию ровно об одном атомарном событии профилирования (атомарными событиями являются аппаратное событие профилирования, отправка/получение одного сетевого пакета, одна операция выделения/освобождения памяти). Составное событие содержит более одного атомарного события, например: «с помощью данного сетевого интерфейса получено 52 пакета общим размером 3012 байт» или «произошло 103034 аппаратных события выполнения одной команды процессора». Составные события порождаются при помощи вызовов библиотеки профилирования, а также с использованием аппаратных возможностей целевой платформы. В частности, события, состоящие из аппаратных событий профилирования, порождаются при помощи специальных аппаратных счетчиков событий, генерирующих прерывание при переполнении.

Логически компоненты системы профилирования можно разделить на компоненты, осуществляющие:

-     сбор информации профилирования (драйвер, агент, библиотека профилирования на целевой стороне; менеджер профилирования на инструментальной стороне);

-     хранение информации (БД событий);

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

-     отображение информации (программы-анализаторы на инструментальной стороне).

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

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

На инструментальной ЭВМ управление сбором событий профилирования осуществляет менеджер профилирования, который является стандартным компонентом комплекса СОМ. Он взаимодействует с остальными компонентами комплекса (таблицей имен, компонентами среды выполнения). Менеджер профилирования передает агенту пользовательские запросы на запуск/останов/сброс профилирования, а также на изменение маски событий профилирования. Кроме того, менеджер профилирования сохраняет полученную информацию обо всех событиях целевых систем (включая события мониторинга) в едином формате в БД событий.

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

Целевая ЭВМ

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

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

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

Для учета аппаратных событий используется интерфейс PAPI [2].

Реализованы функции-обертки для работы с памятью и сетевыми интерфейсами, порождающие соответствующие события профилирования.

Инструментальная ЭВМ

Менеджер профилирования обеспечивает связь ровно с одним агентом профилирования для управления профилированием и получения информации о событиях профилирования.

Менеджер профилирования сохраняет информацию о событиях в БД событий, используя соответствующие интерфейсы.

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

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

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

В настоящее время вместе с системой профилирования используется набор утилит oprofile [3], позволяющий в режиме командной строки управлять счетчиками аппаратных событий целевой системы, а также осуществлять сбор событий профилирования, содержащих информацию об использовании динамически выделяемой памяти и сетевых интерфейсов целевой системы. Результат профилирования сохраняется в формате gmon.out (формат утилиты gprof [4]) для аппаратных событий и в формате hp (формат, используемый инструментом massif программного комплекса Valgrind [5]) для динамической памяти и сетевых интерфейсов.

Представим фрагмент результата выполнения стандартной утилиты gprof при обработке созданного системой профилирования файла gmon.out.

Flat profile:

Each sample counts as 1 samples.

% time	cumulative samples	self samples	calls	self T1/call	total T1/call	name
28.22	92.00	92.00				nfs_sndlock
17.79	150.00	58.00				copyto
14.11	196.00	46.00				_assert
13.80	241.00	45.00				fcntl
10.73	276.00	35.00				timer_settime
4.60	291.00	15.00				copyfrom
4.60	306.00	15.00				elfload
3.37	317.00	11.00				mtxLockInternal
2.78	326.00	9.00				mqSend

В приведенном примере выборка производилась через каждые 750 тыс. аппаратных событий выполнения команд процессора.

Рис. 2. Диаграмма использования памяти

Рис. 3. Диаграмма использования сетевых интерфейсов

Для отображения динамики использования памяти и сетевых интерфейсов целевой системой используется утилита hp2ps, входящая в состав Valgrind. На рисунках 2 и 3 приведены соответствующие диаграммы. По вертикали откладывается количество байтов, по горизонтали – время, в которое производился очередной срез профилирования (время отсчитывается от начала запуска профилирования на целевой системе). Следует отметить, что уникальным идентификатором для точки изменения распределения динамической памяти в целевой системе является пара поток: адрес вызова функции выделения/освобождения памяти. Именно так и обозначаются эти точки на диаграмме использования памяти. Для сетевых интерфейсов конкретный адрес в пользовательской программе, где происходит обращение к сетевому интерфейсу, не важен. Гораздо важнее протоколировать идентификатор потока, обращающегося к сетевому интерфейсу, и направление передачи пакета (от целевой системы/к целевой системе). Поэтому идентификатор точки изменения состояния сетевого интерфейса выглядит следующим образом: поток: число, где число может принимать значение 1 для входящих пакетов и 2 – для исходящих.

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

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

Список литературы

1.   Вьюкова Н.И., Галатенко В.А., Костюхин К.А., Шмырев Н.В. Организация отладочного комплекса для целевых систем со сложной архитектурой. – М.: НИИСИ РАН, 2004.

2.   PAPI User's Guide (http://icl.cs.utk.edu/projects/papi/).

3.   oprofile home page (http://oprofile.sourceforge.net).

4.   GNU binutils home page (http://www.gnu.org/software/binutils/binutils.html).

5.   Valgrind home page (http://vargrind.org).