perf-script-python - Интернет в облаке

ПРОГРАММА:

ИМЯ

perf-script-python - обрабатывает данные трассировки с помощью скрипта Python

СИНТАКСИС

перфорация скрипт [-s [Python]: скрипт [.py]]

ОПИСАНИЕ

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

A БЫСТРО ПРИМЕР

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

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

Скрипт syscall-counts - простой скрипт, но демонстрирует все основные идеи.
необходимо для создания полезного скрипта. Вот пример его вывода (имена системных вызовов
еще не поддерживаются, они будут отображаться в виде чисел):

фут С
системные вызовы:

количество событий
---------------------------------------- ---------- -
sys_write 455067
sys_getdent 4072
sys_close 3037
sys_swapoff 1769
sys_read 923
sys_sched_setparam 826
sys_open 331
sys_newfstat 326
sys_mmap 217
sys_munmap 216
sys_futex 141
sys_select 102
sys_poll 84
sys_setitimer 12
sys_writev 8
15 8
sys_lseek 7
sys_rt_sigprocмаска 6
sys_wait4 3
sys_ioctl 3
sys_set_robust_list 1
sys_exit 1
56 1
sys_access 1
фут

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

· Мы могли бы включить каждое событие в каталоге tracing / events / syscalls, но это
более 600 системных вызовов, что значительно превышает допустимое для perf. Эти индивидуальные системные вызовы
события, однако, будут полезны, если мы захотим позже использовать руководство, которое мы получаем от
универсальные скрипты для детализации и получения более подробной информации об отдельных системных вызовах
интерес.

· Мы можем включить системные вызовы sys_enter и / или sys_exit, найденные в
трассировка / события / raw_syscalls. Они вызываются для всех системных вызовов; в id поле может быть
используется для различения индивидуальных номеров системных вызовов.

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

фут С
# perf record -a -e raw_syscalls: sys_enter

^ C [перфокарта: просыпался 1 раз для записи данных]
[запись perf: захвачено и записано 56.545 МБ perf.data (~ 2470503 образцов)]
фут

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

Когда у нас есть файл perf.data, содержащий наши данные, мы можем использовать -g перфорация скрипт вариант
сгенерируйте скрипт Python, который будет содержать обработчик обратного вызова для каждого типа события, найденного в
поток трассировки perf.data (подробнее см. раздел СТАРТОВЫЕ СКРИПТЫ).

фут С
# perf скрипт -g python
сгенерированный скрипт Python: perf-script.py

Выходной файл, созданный также в текущем каталоге, называется
perf-script.py. Вот файл целиком:

# обработчики событий сценария perf, созданные с помощью сценария perf -g python
# Под лицензией GNU GPL License версии 2

# Поля обработчика событий common_ * являются наиболее полезными полями, общими для
# все события. Они не обязательно соответствуют полям common_ *.
# в формате files. Эти поля, недоступные в качестве параметров обработчика, могут
# извлекаться с использованием функций Python в форме common _ * (context).
# См. Документацию по perf-script-python для получения списка доступных функций.

импорт ОС
импорт системы

sys.path.append (os.environ ['PERF_EXEC_PATH'] + \
'/ scripts / python / Perf-Trace-Util / lib / Perf / Trace')

из импорта perf_trace_context *
из Core import *

def trace_begin ():
печать "в trace_begin"

def trace_end ():
печать "в trace_end"

def raw_syscalls__sys_enter (имя_события, контекст, common_cpu,
common_secs, common_nsecs, common_pid, common_comm,
идентификатор, аргументы):
print_header (event_name, common_cpu, common_secs, common_nsecs,
common_pid, common_comm)

print "id =% d, args =% s \ n"% \
(идентификатор, аргументы),

def trace_unhandled (имя_события, контекст, common_cpu, common_secs, common_nsecs,
common_pid, common_comm):
print_header (event_name, common_cpu, common_secs, common_nsecs,
common_pid, common_comm)

def print_header (event_name, cpu, secs, nsecs, pid, comm):
print "% -20s% 5u% 05u.% 09u% 8u% -20s"% \
(имя_события, cpu, secs, nsecs, pid, comm),
фут

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

Далее следует пара сгенерированных функций, trace_begin () и trace_end (), которые
вызывается в начале и в конце скрипта соответственно (подробнее см.
Раздел SCRIPT_LAYOUT ниже).

За ними следуют мероприятие обработчик функции генерировали по одной для каждого события в перфорация
запись выход. Функции-обработчики имеют вид подсистемыназвание события, и содержать названный
параметры, one для каждый поле in домен событие; in этой случай, есть только one мероприятие,
raw_syscallssys_enter (). (подробнее о мероприятии см. в разделе «УПРАВЛЯЮЩИЕ СОБЫТИЯМИ» ниже).
обработчики).

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

Сценарий, созданный параметром -g, просто печатает строку для каждого события, обнаруженного в трассировке.
stream, т.е. он просто выгружает событие и его значения параметров в стандартный вывод. В
Функция print_header () - это просто служебная функция, используемая для этой цели. Давай переименуем
сценарий и запустите его, чтобы увидеть результат по умолчанию:

фут С
# mv perf-script.py syscall-counts.py
# perf скрипт -s syscall-counts.py

raw_syscalls__sys_enter 1 00840.847582083 7506 perf id = 1, args =
raw_syscalls__sys_enter 1 00840.847595764 7506 perf id = 1, args =
raw_syscalls__sys_enter 1 00840.847620860 7506 perf id = 1, args =
raw_syscalls__sys_enter 1 00840.847710478 6533 npviewer.bin id = 78, args =
raw_syscalls__sys_enter 1 00840.847719204 6533 npviewer.bin id = 142, args =
raw_syscalls__sys_enter 1 00840.847755445 6533 npviewer.bin id = 3, args =
raw_syscalls__sys_enter 1 00840.847775601 6533 npviewer.bin id = 3, args =
raw_syscalls__sys_enter 1 00840.847781820 6533 npviewer.bin id = 3, args =
.
.
.
фут

Конечно, для этого скрипта нас не интересует вывод каждого события трассировки, а скорее
собирая это полезным способом. Так что избавимся и от всего, что связано с печатью.
как функции trace_begin () и trace_unhandled (), которые мы не будем использовать. Что оставляет
с этим минималистичным скелетом:

фут С
импорт ОС
импорт системы

sys.path.append (os.environ ['PERF_EXEC_PATH'] + \
'/ scripts / python / Perf-Trace-Util / lib / Perf / Trace')

из импорта perf_trace_context *
из Core import *

def trace_end ():
печать "в trace_end"

def raw_syscalls__sys_enter (имя_события, контекст, common_cpu,
common_secs, common_nsecs, common_pid, common_comm,
идентификатор, аргументы):
фут

В trace_end () мы просто распечатываем результаты, но сначала нам нужно сгенерировать некоторые результаты
печатать. Для этого нам нужно, чтобы наш обработчик sys_enter () выполнял необходимые подсчеты.
пока не будут подсчитаны все события. Хеш-таблица, проиндексированная по идентификатору syscall, - хороший способ
хранить эту информацию; каждый раз, когда вызывается обработчик sys_enter (), мы просто увеличиваем
счетчик, связанный с этой хеш-записью, проиндексированной этим идентификатором системного вызова:

фут С
syscalls = autodict ()

попробовать:
системные вызовы [id] + = 1
кроме TypeError:
системные вызовы [id] = 1
фут

Системные вызовы автодикт объект - это особый вид словаря Python (реализованный в
Core.py), который реализует Perl's автоживотный хеши в Python, т.е. с автоживификацией
хешей, вы можете назначать вложенные хеш-значения без необходимости создавать
промежуточные уровни, если они не существуют, например, системные вызовы [comm] [pid] [id] = 1 создадут
промежуточные уровни хеширования и, наконец, присвоить значение 1 хеш-записи для id (потому что
присваиваемое значение не является самим хеш-объектом, начальное значение присваивается в
Исключение TypeError. Что ж, может быть лучший способ сделать это в Python, но это то, что
пока работает).

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

Функция print_syscall_totals () выполняет итерацию по записям в словаре и
отображает строку для каждой записи, содержащей имя системного вызова (ключи словаря содержат
идентификаторы системных вызовов, которые передаются в функцию Util syscall_name (), которая переводит
необработанные номера системных вызовов в соответствующие строки имен системных вызовов). На выходе
отображается после того, как все события в трассировке были обработаны, путем вызова
print_syscall_totals () из обработчика trace_end (), вызываемого в конце скрипта
обработка.

Последний сценарий, производящий показанный выше результат, полностью показан ниже.
(помощник syscall_name () пока недоступен, пока вы можете иметь дело только с идентификаторами):

фут С
импорт ОС
импорт системы

sys.path.append (os.environ ['PERF_EXEC_PATH'] + \
'/ scripts / python / Perf-Trace-Util / lib / Perf / Trace')

из импорта perf_trace_context *
из Core import *
из Util import *

syscalls = autodict ()

def trace_end ():
print_syscall_totals ()

def raw_syscalls__sys_enter (имя_события, контекст, common_cpu,
common_secs, common_nsecs, common_pid, common_comm,
идентификатор, аргументы):
попробовать:
системные вызовы [id] + = 1
кроме TypeError:
системные вызовы [id] = 1

def print_syscall_totals ():
если for_comm не равно None:
print "\ nсобытия системного вызова для% s: \ n \ n"% (for_comm),
еще:
print "\ nsyscall events: \ n \ n",

напечатайте "% -40s% 10s \ n"% ("событие", "количество"),
напечатайте "% -40s% 10s \ n"% ("------------------------------------- --- ", \
"-----------"),

для id, val в отсортированном (syscalls.iteritems (), key = lambda (k, v): (v, k), \
реверс = правда):
напечатайте "% -40s% 10d \ n"% (syscall_name (id), val),
фут

Скрипт можно запустить так же, как и раньше:

# perf скрипт -s syscall-counts.py

Итак, это основные этапы написания и запуска сценария. Процесс может быть
обобщены на любую точку трассировки или набор точек трассировки, которые вас интересуют - в основном найти
интересующие вас точки трассировки, просмотрев список доступных событий, показанный
перфорация список и / или посмотрите / sys / kernel / debug / tracing events для получения подробных сведений о событии и поле
info, запишите соответствующие данные трассировки, используя перфорация запись, передав ему список
интересные события, сгенерируйте скелетный скрипт, используя перфорация скрипт -g питон и изменить
код для агрегирования и отображения для ваших конкретных нужд.

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

фут С
root @ tropicana: ~ # сценарий перфоманса -l
Список доступных скриптов трассировки:
wakeup-latency мин. / макс. / средн. задержка пробуждения в масштабе всей системы
rw-by-file ж / б активность для программы, по файлам
rw-by-pid общесистемная активность чтения / записи
фут

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

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

Ассоциация запись script - это сценарий оболочки с тем же базовым именем, что и ваш сценарий, но с
-запись прилагается. Скрипт оболочки следует поместить в папку perf / scripts / python / bin.
каталог в дереве исходных кодов ядра. В этом сценарии вы пишете перфорация запись
командная строка, необходимая для вашего скрипта:

фут С
# кот ядро-источник / инструменты / перф / скрипты / python / bin / syscall-counts-record

#!/ bin / bash
perf record -a -e raw_syscalls: sys_enter
фут

Ассоциация отчету script также является сценарием оболочки с тем же базовым именем, что и ваш сценарий, но с
-отчет прилагается. Он также должен находиться в каталоге perf / scripts / python / bin. В
этот сценарий, вы пишете перфорация скрипт -s командная строка, необходимая для запуска вашего скрипта:

фут С
# кот ядро-источник / инструменты / перф / скрипты / python / bin / syscall-counts-report

#!/ bin / bash
# description: счетчик системных вызовов
сценарий perf -s ~ / libexec / perf-core / scripts / python / syscall-counts.py
фут

Обратите внимание, что расположение сценария Python, указанного в сценарии оболочки, находится в
Каталог libexec / perf-core / scripts / python - сюда скрипт будет скопирован
сделать устанавливать при установке perf. Для установки, чтобы установить туда ваш скрипт,
ваш скрипт должен находиться в каталоге perf / scripts / python в исходном коде ядра.
дерево:

фут С
# ls -al источник-ядра / инструменты / perf / scripts / python

корень @ тропикана: / home / trz / src / tip # ls -al tools / perf / scripts / python
Всего 32
drwxr-xr-x 4 trz trz 4096 2010 01:26.
drwxr-xr-x 4 trz trz 4096 2010 01:26 ..
drwxr-xr-x 2 trz trz 4096 2010 01:26 bin
-rw-r - r-- 1 trz trz 2548 2010 01:26 check-perf-script.py
drwxr-xr-x 3 trz trz 4096 2010 01:26 Perf-Trace-Util
-rw-r - r-- 1 trz trz 1462 2010 01:26 syscall-counts.py
фут

Как только вы это сделаете (не забудьте сделать новый сделать устанавливать, иначе ваш сценарий не будет
появляются во время выполнения), перфорация скрипт -l должен показать новую запись для вашего скрипта:

фут С
root @ tropicana: ~ # сценарий перфоманса -l
Список доступных скриптов трассировки:
wakeup-latency мин. / макс. / средн. задержка пробуждения в масштабе всей системы
rw-by-file ж / б активность для программы, по файлам
rw-by-pid общесистемная активность чтения / записи
syscall-counts общесистемный счетчик системных вызовов
фут

Теперь вы можете выполнить шаг записи через перфорация скрипт запись:

# perf script запись syscall-counts

и отобразить результат, используя перфорация скрипт отчету:

# perf скрипт сообщает количество системных вызовов

стартовый СЦЕНАРИИ

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

Вы также можете посмотреть существующие скрипты в ~ / libexec / perf-core / скрипты / питон для
типичные примеры, показывающие, как делать основные вещи, такие как агрегированные данные о событиях, результаты печати,
и т.д. Также скрипт check-perf-script.py, хотя и не интересный своими результатами,
пытается использовать все основные функции сценариев.

СОБЫТИЕ ОБРАБОТЧИКИ

Когда сценарий perf вызывается с помощью сценария трассировки, пользовательский обработчик функция is
вызывается для каждого события в трассировке. Если для данного
тип события, событие игнорируется (или передается в трассировка_обработано функции, см. ниже) и
следующее событие обрабатывается.

Большинство значений полей события передаются в функцию-обработчик в качестве аргументов; некоторые из
менее распространенные - нет - они доступны как обратные вызовы в исполняемый файл perf
(Смотри ниже).

В качестве примера можно использовать следующую команду perf record для записи всех sched_wakeup
события в системе:

# perf record -a -e sched: sched_wakeup

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

Файл формата для события sched_wakep определяет следующие поля (см.
/ sys / kernel / debug / tracing / events / sched / sched_wakeup / format):

фут С
Формат:
поле: беззнаковое короткое common_type;
поле: беззнаковый символ common_flags;
поле: беззнаковый символ common_preempt_count;
поле: int common_pid;

поле: char comm [TASK_COMM_LEN];
поле: pid_t pid;
поле: int prio;
поле: int success;
поле: int target_cpu;
фут

Функция обработчика для этого события будет определена как:

фут С
def sched__sched_wakeup (имя_события, контекст, common_cpu, common_secs,
common_nsecs, common_pid, common_comm,
связь, pid, приоритет, успех, target_cpu):
pass
фут

Функция обработчика имеет вид subsystem__event_name.

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

Вот краткое описание каждого из аргументов инвариантного события:

event_name название события в виде текста
context непрозрачный файл cookie, используемый при обратных вызовах в perf
common_cpu процессор, на котором произошло событие
common_secs - часть метки времени события в секундах
common_nsecs - часть метки времени события, равная nsecs.
common_pid pid текущей задачи
common_comm имя текущего процесса

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

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

SCRIPT Палубы Prestige XXNUMX

Каждый сценарий Python perf должен начинаться с настройки пути поиска модуля Python и
'импорт' нескольких модулей поддержки (см. описания модулей ниже):

фут С
импорт ОС
импорт системы

sys.path.append (os.environ ['PERF_EXEC_PATH'] + \
'/ scripts / python / Perf-Trace-Util / lib / Perf / Trace')

из импорта perf_trace_context *
из Core import *
фут

Остальная часть скрипта может содержать функции-обработчики и вспомогательные функции в любом порядке.

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

трассировка_бегин, если определено, вызывается перед обработкой любого события и дает скриптам
возможность выполнять задачи по настройке:

фут С
определение trace_begin:
pass
фут

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

фут С
определение след_конец:
pass
фут

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

фут С
def trace_unhandled (имя_события, контекст, common_cpu, common_secs,
common_nsecs, common_pid, common_comm):
pass
фут

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

В НАЛИЧИИ МОДУЛИ И ФУНКЦИИ

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

Core.py Модули
Эти функции предоставляют некоторые важные функции пользовательским скриптам.

Ассоциация flag_str и символ_стр функции предоставляют удобочитаемые строки для флагов и символических
поля. Они соответствуют строкам и значениям, полученным из Распечатать FMT поля
файлы формата событий:

flag_str (event_name, field_name, field_value) - возвращает строковое представление, соответствующее field_value для флага field_name события event_name
symbol_str (event_name, field_name, field_value) - возвращает строковое представление, соответствующее field_value для символьного поля field_name события event_name

Ассоциация автодикт функция возвращает специальный вид словаря Python, который реализует Perl's
автоживотный хеши в Python, т.е. с автоживущими хешами, вы можете назначить вложенный хеш
значения без необходимости создавать промежуточные уровни, если они не
существовать.

autodict () - возвращает экземпляр автозаполнения словаря

perf_trace_context Модули
Некоторые из общий поля в файле формата события не так уж и распространены, но должны быть
тем не менее, стал доступным для пользовательских скриптов.

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

common_pc (context) - возвращает количество common_preempt для текущего события
common_flags (context) - возвращает common_flags для текущего события
common_lock_depth (context) - возвращает common_lock_depth для текущего события

Утил.py Модули
Различные служебные функции для использования со скриптом perf:

nsecs (secs, nsecs) - возвращает общее количество nsecs для данной пары secs / nsecs
nsecs_secs (nsecs) - возвращает целую часть секунд с заданными nsecs
nsecs_nsecs (nsecs) - возвращает остаток в nsecs с заданными nsecs
nsecs_str (nsecs) - возвращает печатаемую строку в виде secs.nsecs
avg (total, n) - возвращает среднее значение с учетом суммы и общего количества значений

Используйте perf-script-python онлайн с помощью сервисов onworks.net