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

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

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

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

Термин контролируемое выполнение обозначает процесс функционирования сложной системы, при котором она имеет возможность выполнить свою миссию, несмотря на возможное проявление ошибок, атаки и отказы (см.: В.А. Галатенко, К.А. Костюхин. Отладка и мониторинг распределенных разнородных систем. // Программирование. 2002. № 1). Концепция контролируемого выполнения реализована в разработанном в НИИ системных исследований РАН (НИИСИ РАН) инструментальном комплексе «Система отладки/мониторинга» – СОМ (см.: Н.И. Вьюкова, В.А. Галатенко, К.А. Костюхин, Н.В. Шмырев. Организация отладочного комплекса для целевых систем со сложной архитектурой. М.: НИИСИ РАН. 2004).

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

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

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

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

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

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

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

Средства самоконтроля можно рассматривать и как один из инструментов отладки, и как инструмент защиты от атак на доступность, трактуя их как средства самозащиты систем.

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

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

Прикладной программный интерфейс для измерения производительности (PAPI)

Современные процессоры, например, семейства x86, IA-64, Power, MIPS, поддерживают профилирование программ посредством использования аппаратных счетчиков – специальных регистров, фиксирующих аппаратные события определенного типа.

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

Целью проекта PAPI (Perfomance Application Programming Interface) является разработка, стандартизация и реализация переносимого и эффективного прикладного программного интерфейса для доступа к аппаратным счетчикам (см.: http://icl.cs.utk.edu/pro­jects/papi/). Проект PAPI поддерживается консорциумом Parallel Tools Consortium (http://www ptools. org). PAPI, по сути,  является стандартом для разработчиков ПО, осуществляющего профилирование кода.

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

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

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

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

Реализация профилирования в инструментальном комплексе СОМ

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

БП реализует дополненный вариант стандарта PAPI. А именно, кроме функций интерфейса верхнего уровня PAPI реализованы функции настройки параметров профилирования и управления сбором событий в среде ППС. Такой подход позволяет комбинировать программные средства с имеющимися аппаратными возможностями целевой платформы (см.: Eric Chi, A. Michael Salem, R. Iris Bahar Combining Software and Hardware Monitoring for Improved Power and Perfomance Tuning. 2003).

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

Использование БП предполагает ручную инструментовку профилируемой программы. В начале программы надо вставить вызов функции PAPI_li­brary_init, указав в качестве параметра значение PAPI_VER_CURRENT, определенное в заголовочном файле. Эта функция инициализирует таймер и создает кольцевой буфер, в который будет сохраняться информация о событиях профилирования. В случае успеха функция возвращает PAPI_VER_CURRENT.

Кольцевой буфер создается в локальной памяти процессора, позволяя осуществлять профилирование разных процессоров на одном модуле обработки сигналов. Для управления параметрами буфера (размер и адрес) предназначены функции PAPI_set_ buffer_size, PAPI_get_buffer_size, PAPI_set_buffer_ addr и PAPI_get_buffer_addr.

Рассмотрим пример применения БП для следующей задачи.

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

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

Для решения поставленной задачи средствами профилирования необходимо выполнить инструментовку исходного кода компонентов МОС1 и МОС2. А именно, вставить в код вызовы функций PAPI_event_create перед кодом и после него, реализующего ожидание события, извещающего об отправке данных с ПД, а также перед кодом и после него, реализующего обработку данных.

На листинге 1 показан фрагмент инструментованного исходного кода приложения, выполняющегося на МОС1 и МОС2. Здесь интервал между событиями типа 1 соответствует времени ожидания данных с ПД. Интервал между событиями типа 2 соответствует времени обработки данных.

Листинг 1.

if (PAPI_library_init (PAPI_VER_CURRENT) !=

!= PAPI_VER_CURRENT)

{

   exit (1);

}

/* ... */

PAPI_event_create (1, 0); /* Событие с номером 1

соответствует времени

ожидания данных с ПД */

ge_wait (EV_READY);

PAPI_event_create (1, 0);

PAPI_event_create (2, 0); /* Событие с номером 2

соответствует времени

обработки данных */

do_calcs ();

PAPI_event_create (2, 0);

ge_set (EV_FINISHED);

/* ... */

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

На листинге 2 представлена информация о событиях, созданных при помощи функции PAPI_event_ create на МОС1. В первом столбце указаны адреса в локальной памяти ЦПОС. Во втором – информация о событии, то есть номер события, время его наступления в процессорных тиках (временная метка события) и ассоциированные данные (в данном случае дополнительных данных нет, поэтому – ноль). Из листинга видно, первое событие с номером 1 наступает в момент времени 2. Второе событие с номером 1 наступает в момент времени 34698. Первое и второе события с номером 2 наступают в моменты времени соответственно 34699 и 145045.

Листинг 2. Дамп памяти процессора ППС с сохраненной информацией о событиях профилирования

----- Area ----- 2-SP:A y:10070000..c

y:10070000 1 2          0

y:10070003 1 34698   0

y:10070006 2 34699   0

y:10070009 2    145045  0

Теперь есть вся информация для оптимизации работы приложения. Вычислим среднюю скорость v1 обработки данных на первом модуле, поделив размер пачки данных на среднее значение времени обработки (разность значений временных меток события 2). Аналогичным образом из данных о событиях на втором модуле вычисляется его скорость обработки данных v2. Отношение скоростей (v2/v1) и будет коэффициентом, на который необходимо умножать размер пачки для МОС2, чтобы минимизировать время простоя приложения на МОС1.

Наряду с БП в инструментальном комплексе СОМ реализован графический компонент профилирования, осуществляющий стохастический анализ работы программ.

Через заранее выбранный интервал времени производится остановка целевой программы и считываются значения счетчика команд. Затем приложение опять запускается. В результате получается профиль выполнения программы, из которого видно, какие фрагменты кода выполнялись наиболее часто. Если ранее с помощью инструмента загрузки модулей в систему была загружена символьная (отладочная) информация о пользовательской программе, инструмент профилирования отобразит для каждого адреса также имя функции, в которой программа находилась, и номер строки исходного текста. При отсутствии отладочной информации инструмент профилирования выведет имя функции, предположительно содержащей указанный адрес. В этом случае за именем функции будет стоять вопросительный знак, например, «Fge_wait?».

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

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