Библиотека сайта rus-linux.net
Что каждый программист должен знать о памяти.
Часть 9: Приложения и библиография
| Назад | Оглавление | Вперед |
10 Несколько советов по использованию oprofile
Предлагаемое ниже описание не является руководством по использованию oprofile. Есть другая документация, касающаяся данной темы. Вместо этого здесь приводится несколько общих советов о том, как анализировать программы и искать места возможных проблем. Но перед этим мы должны привести, как минимум, некоторые базовые сведения.
10.1 Базовые сведения о oprofile
Работа oprofile осуществляется в в два этапа: сбор информации и ее анализ. Сбор информации выполняется ядром; это нельзя сделать на пользовательском уровне, так как для измерений используются счетчики производительности процессора. Для этих счетчиков требуется доступ к регистрам MSR (Machine State Registers — Регистры состояния машины), для доступа к которым, в свою очередь, требуются привилегии.
В каждом современном процессоре есть свой набор счетчиков производительности. Для некоторых вариантов архитектуры определенное подмножество счетчиков есть во всех реализациях процессоров, тогда как в других вариантах наличие счетчиков зависит от версии процессора. Из-за этого трудно дать общие рекомендации об использовании oprofile. К настоящему времени (еще) не разработаны абстракции высокого уровня, помогающие скрыть эти особенности.
Также от версии процессора зависит то, какое количество событий и в какой комбинации можно отслеживать в каждый момент времени. Это еще больше усложняет картину.
Если пользователю известны необходимые сведения о счетчиках производительности, то для выбора событий, которые должны учитываться, можно использовать программу opcontrol. Для каждого события необходимо указать "значение превышения" (количество событий, которые должны произойти, прежде чем работа процессора будет прервана для записи события), какие события будут подсчитываться на пользовательском уровне и / или в ядре, и, наконец, "маска устройства" (с ее помощью выбираются подфункции счетчика производительности).
Чтобы подсчитать циклы на процессорах x86 и x86-64, нужно выполнить следующую команду:
opcontrol --event CPU_CLK_UNHALTED:30000:0:1:1
Число 30000 является значением превышения. При определении возможностей системы и сборе данных важно выбрать разумное значение. Нельзя требовать получать данные о каждом наступлении конкретного события. Когда событий много, это может привести к остановке машины, поскольку все, что она сможет делать, это собирать данные, связанными с превышением значений для событий; вот почему нужно для oprofile задавать минимальное значение. Минимальные значения будут различными для каждого события, так как различные события имеют различную вероятность возникновения в обычном коде.
Выбор очень большого значения уменьшает разрешающую способность программы oprofile. При каждом превышении значения программа oprofile записывает адрес инструкции, которая выполняется в данный момент; для архитектур x86 и PowerPC можно, при определенных обстоятельствах, также выполнять трассировку и записывать ее результаты. {Мы надеемся, что с некоторого момента трассировка будет поддерживаться на любой архитектуре.} При низкой разрешающей способности можно не получить представительного количества значений; речь идет о вероятностностных значениях, именно поэтому программа oprofile называется вероятностным профилировщиком. Чем меньше значение превышения, тем сильнее его влияние на систему с точки зрения замедления системы, но тем выше разрешающая способность программы.
Если выполняется профилирование конкретной программы и система не используется в производственных целях, то часто будет более полезным использовать минимально возможное значение превышения. Точное значение для каждого события можно получить следующим образом
opcontrol --list-events
Если профилируемая программа взаимодействует к другим процессом, то могут возникнуть проблемы, а уменьшение скорости работы вызовет проблемы при взаимодействии. Проблемы могут также возникнуть в случае, если к процессу предъявляются некоторые требования режима реального времени, которые нельзя реализовать в случае, если процесс часто прерывается. В этом случае нужно найти золотую середину. То же самое справедливо в случае, если в течение длительных периодов времени осуществляется профилирование всей системы. Небольшое значение превышения может означать значительное замедление работы системы. В любом случае программа oprofile, как и любой другой способ профилирования, вносит неопределенность и неточность.
Профилирование можно запустить с помощью команды opcontrol --start и можно остановить с помощью команды opcontrol —stop. Когда программа oprofile собирает данные, эти данные сначала собираются в ядре, а затем в поточном режиме перенаправляются в демон пользовательского уровня, где они декодируются и записываются в файловую систему. С помощью команды opcontrol --dump можно сделать запрос всей информации, находящейся в буфере ядра, которая будет передана на пользовательский уровень.
В собранных данных могут быть данные событиях, полученных от других счетчиков производительности. В случае, если пользователь не указал стирать сохраненные данные между отдельными запусками программы oprofile, то все значения будут сохраняться вместе. Можно накапливать данные об одних и тех же событиях, возникающих в разных ситуациях. Когда событие возникает во время других профилирующих запусков, полученные значения будут добавляться в том случае, если это то, что выбрал пользователь.
Та часть процесса сбора данных, которая работает на пользовательском уровне, выполняет демультиплексирование данных. Данные для каждого файла сохраняются отдельно. Можно даже выделять различные DSO, используемые отдельными исполняемыми файлами, и даже данные отдельных потоков. С помощью команды oparchive данные, созданные таким образом, можно заархивировать. Файл, созданный этой командой, можно транспортировать на другую машину и там можно выполнить анализ данных.
С помощью программы opreport можно создавать отчеты о результатах профилирования. С помощью программы opannotate можно увидеть, где происходят различные события: в какой инструкции и, если имеются данные, в какой строке исходного кода. В результате легче найти проблемные места. Подсчет циклов процессора укажет, где тратится большая часть времени (сюда относятся промахи кэш-памяти), тогда как подсчет неиспользуемых инструкций позволяет найти место, где находится наибольшее количество исполняемых инструкций — они различаются существенно.
Одиночное попадание по некоторому адресу, обычно незначимо. Побочным эффектом статистического профилирования является то, что попадание может происходить и на инструкции, которые выполняются всего лишь несколько или даже только один раз. В подобном случае результаты необходимо проверять с помощью повторного сбора данных.
| Назад | Оглавление | Вперед |