Профилирование системы VxWorks

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

Я могу только догадываться, откуда взялась «известная» идея, что для поиска проблем с производительностью нужно измерять производительность различных частей. Это нисходящий подход, аналогичный тому, как правительства пытаются контролировать бюджетные траты путем разделения. ИМХО, не очень получается. Измерение годится для того, чтобы увидеть, повлияло ли то, что вы сделали, но оно плохо говорит вам, что нужно исправить.

Что хорошо, чтобы сказать вам, что нужно исправить, так это восходящий подход, при котором вы исследуете репрезентативную выборку микроскопических единиц того, что тратится, и находите полное объяснение того, почему каждый тратится. Это работает по простой статистической причине. Если есть причина, по которой можно сохранить какой-то процент (например, 40%) сэмплов, то в среднем 40% сэмплов покажут это, и для этого не требуется огромное количество сэмплов. Это требует тщательного изучения каждого образца, а не просто объединения их в более крупные группы.

В качестве исторического примера, это то, что сделал Гарри Трумэн в начале участия США во Второй мировой войне. В оборонной промышленности были потрясающие растраты. Он просто сел в машину, поехал на фабрики и опросил стоявших вокруг людей. Затем он вернулся в Сенат США, объяснил, в чем именно заключались проблемы, и добился их устранения.

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

ДОБАВЛЕНО: Я думаю, что идея поиска путем измерения просто естественна. Примерно в 1982 году я работал над встроенной системой, и мне нужно было немного настроить производительность. Аппаратчик предложил поставить на плату таймер, который я мог бы читать (предоставив его избыток). IOW он предположил, что поиск проблем с производительностью требует времени. Я поблагодарил его и отказался, потому что к тому времени я знал и доверял технике случайной остановки (сделанной с помощью внутрисхемного эмулятора).

Если у вас есть дополнительные часы, вы можете использовать утилиту SPY (настраиваемую через файл config.h), которая дает вам очень приблизительное представление о том, какие задачи используют ЦП.

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

В противном случае предложение btpierre использовать taskHookAdd успешно использовалось в прошлом.

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

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

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

Чтобы увидеть, какой запас у вас есть, добавьте «бездействующую» задачу с самым низким приоритетом, которая просто выполняет «пока (1) {}», и посмотрите, сколько % ЦП ей назначено. Грубо говоря, это ваш запас.