a. протоколирование переключения контекстов
b. протоколирование состояний задач
c. протоколирование статусов системных объектов.
3) Профилирование системы
Под профилированием понимается один из способов мониторинга, позволяющий следить за выполнением некоторого множества задач (или всей системы) и предоставляющий пользователю информацию о том, как конкретная задача использует процессор (включая распределение времени в задаче).
Профилирование заключается в том, что с некоторой частотой производятся выборки данных об активных в этот промежуток времени задачах. При детальном профилировании собираются данные о каждой функции (количество ее вызовов, время выполнения). Приведем описание модуля ScopeProfile, входящего в StethoScope и представляющего собой типичный образец агента профилирования.
Сбор данных запускается либо специальной высокоприоритетной задачей, либо посредством ISR (Interrupt Service Routine). Существует два уровня профилирования: профилирование задачи способом «процедура за процедурой» (procedure-by-procedure) и профилирование системы способом «задача за задачей» (task-by-task). Основные параметры профилирования: частота выборки (sample rate) — частота, с которой производится сбор данных; частота анализа (analysis rate) — частота, с которой производится анализ имеющихся в буфере выборок. Анализирующая процедура представляет собой низкоприоритетную задачу, которая подсчитывает среднее из значений для задач и функций из всех выборок буфера и значений, полученных в ходе предыдущего анализа.
Цель профилирования задачи — выявить наиболее часто исполняемые блоки для последующей их оптимизации. Для этого служит способ «процедура за процедурой», позволяющий получать информацию о каждой вызываемой в процессе профилирования функции. Эта информация состоит из среднего времени, которое функция выполнялась, с учетом и без учета времени вызова из нее других функций. Также подсчитывается число ее вызовов. В результате анализа стека строится так называемое дерево выполнения (execution tree), показывающее маршрут вызова каждой функции.
Способ «задача за задачей» служит для сбора информации об активности системы в целом, а именно, какое процессорное время использует каждая задача.
4) «Посмертный» (post-mortem) анализ
Подобный анализ производится в том случае, если в работе системы произошел сбой. Тогда пользователя интересуют не все события, а только те, которые произошли за некоторое время до «обвала» системы. В этом случае, чтобы влияние отладчика на систему было сведено к минимуму, все данные сохраняются в некотором буфере и обновляются по мере его заполнения, но не пересылаются на инструментальную сторону. Адрес для буфера надо выбирать так, чтобы при перезагрузке системы его содержимое не уничтожалось. В VxWorks это можно реализовать следующим образом: надо изменить функцию sysMemTop(), определяющую верхний адрес локальной памяти, так, чтобы она возвращала значение, меньшее действительного адреса. Тогда в образовавшемся адресном пространстве, недоступном системе, можно расположить буфер данных. В результате после перезагрузки в распоряжение отладчика поступают данные о последних событиях, произошедших в системе и, возможно, повлекших ее сбой.
3.3. Пользовательский интерфейс
При анализе данных или профилировании важную роль играет представление полученной информации. Как и в случае активной отладки пользовательский интерфейс делится на три составляющих: графический интерфейс, режим командной строки и команды представления данных.
Графическое представление данных — наиболее важная часть пользовательского интерфейса при мониторинге. Поскольку, как правило, анализируется взаимодействие задач в системе, то нужна визуализация всех событий и задач системы. В WindView для этого служит специальное окно View Graph. По горизонтали откладывается время (единичный интервал времени может меняться), по вертикали приведен список всех задач в системе и уровни прерываний. В такой системе координат легко увидеть, какая задача в какой момент времени в каком состоянии находилась. Особыми значками отмечаются происходящие события, подробности о которых (также как и о задачах) можно увидеть в другом окне.
При мониторинге текущего состояния системы удобно пользоваться графическим интерфейсом, но при анализе сохраненных ранее данных, а также при «посмертной» отладке, можно использовать режим командной строки. Требования к нему предъявляются аналогичные тем, что были у средств активной отладки.
Помимо описанных в предыдущей главе команд представления данных у активных отладчиков средства мониторинга могут располагать также такими командами:
• исполнение некоторой последовательности действий при произошедшем событии, поступившем сигнале или наступлении определенного момента времени;
• определение пользователем собственных событий (eventpoints в WindView) и сигналов (комбинации известных сигналов «derived signals» в StethoScope).
3.4. Интеграция со средствами разработки ПО
При мониторинге особое внимание уделяется работе псевдоагентов, которые закладываются в код программы на этапе компиляции. Для их успешной работы по сбору необходимой информации требуется наличие на целевой машине ряда функций, вызываемых псевдо-агентами. Эти функции могут быть собраны в одну библиотеку, так называемую библиотеку доступа (access library). В [20] описывается средство работы с псевдо-агентами — «Alamo monitor». На Рис. 5 приведена его архитектура.
Рис. 5. Alamo monitor
Координатор мониторинга посылает запросы псевдо-агенту и производит фильтрацию полученной информации.
Рис. 6. Получение информации от псевдо-агента
В зависимости от возможностей, предоставляемых библиотекой доступа, изменяется и роль псевдо-агентов. Возможна ситуация, когда на целевой стороне присутствует только агент доставки данных из буфера, а все данные поставляются псевдо-агентами. Такой подход уменьшает воздействие отладчика на систему, так как все отладочные действия заложены при компиляции, и агент отладки только передает данные менеджеру по мере заполнения буфера, то есть не влияет на ход выполнения отлаживаемых задач.
Имеется и другое применение псевдо-агентов. При помощи встраивания в код программы некоторого некорректно работающего блока, можно моделировать критические ситуации и анализировать поведение задачи или всей системы в таких ситуациях.
4. Особенности отладки многоплатформных распределенных систем
4.1. Особенности архитектуры
Если раньше система реального времени рассматривалась нами как один процесс (с точки зрения ресурсов), то распределенные СРВ представляют уже набор взаимодействующих процессов.