perf-script-python - онлайн у хмарі

ПРОГРАМА:

ІМ'Я

perf-script-python - обробляти дані трасування за допомогою скрипту Python

СИНТАКСИС

пер сценарій [-s [Python]:script[.py] ]

ОПИС

Цей параметр сценарію perf використовується для обробки даних сценарію perf за допомогою вбудованого в perf Python
перекладач. Він зчитує та обробляє вхідний файл і відображає результати трасування
аналіз, реалізований у даному скрипті Python, якщо такий є.

A QUICK приклад

У цьому розділі показано процес від початку до кінця створення робочого сценарію Python
об’єднує та витягує корисну інформацію з потоку необроблених сценаріїв perf. Ви можете уникнути
прочитати решту цього документа, якщо вам достатньо прикладу; решта
Документ містить докладнішу інформацію про кожен крок і перераховує доступні бібліотечні функції
сценаристів.

У цьому прикладі детально описані кроки, які були використані для створення кількість системних викликів сценарій
ви бачите, коли ви перераховуєте доступні сценарії perf за допомогою пер сценарій -l. Як такий, це
script також показує, як інтегрувати ваш сценарій до списку загального призначення пер
сценарій скрипти, перелічені цією командою.

Сценарій системних викликів є простим сценарієм, але демонструє всі основні ідеї
необхідний для створення корисного сценарію. Ось приклад його виводу (назви системних викликів
ще не підтримується, вони відображатимуться у вигляді цифр):

.ft C
події системного виклику:

кількість подій
----------------------------------------- ---------- -
sys_write 455067
sys_getdents 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_sigprocmask 6
sys_wait4 3
sys_ioctl 3
sys_set_robust_list 1
sys_exit 1
56 1
sys_access 1
.ft

В основному наше завдання полягає в тому, щоб вести підрахунок системного виклику, який оновлюється щоразу, коли система
виклик відбувається в системі. Наш скрипт зробить це, але спочатку нам потрібно записати дані
які будуть оброблені цим сценарієм. Теоретично ми могли б скористатися кількома способами
зробити це:

· ми могли б увімкнути кожну подію в каталозі tracing/events/syscalls, але це так
понад 600 системних викликів, що значно перевищує кількість, дозволену perf. Ці окремі системні виклики
події, однак, будуть корисні, якщо ми захочемо пізніше використовувати вказівки, отримані від
скрипти загального призначення для деталізації та отримання більш детальної інформації про окремі системні виклики
інтерес.

· ми можемо ввімкнути системні виклики sys_enter та/або sys_exit, які можна знайти в розділі
tracing/events/raw_syscalls. Вони викликаються для всіх системних викликів; в id поле може бути
використовується для розрізнення окремих номерів системного виклику.

Для цього сценарію нам потрібно лише знати, що було введено системний виклик; нам байдуже, як це
вийшов, тому ми скористаємося пер запис щоб записати лише події sys_enter:

.ft C
# запис perf -a -e raw_syscalls:sys_enter

^C[ perf record: прокинувся 1 раз для запису даних ]
[ perf record: знято та записано 56.545 МБ perf.data (~2470503 зразків)]
.ft

Опції в основному говорять про збір даних для кожної події системного виклику в усій системі та
мультиплексувати вихід на процесор в один потік. Цей єдиний потік буде записано
файл у поточному каталозі під назвою perf.data.

Коли у нас є файл perf.data, що містить наші дані, ми можемо використовувати -g пер сценарій варіант до
створити сценарій Python, який міститиме обробник зворотного виклику для кожного типу події, знайденого в
потік трасування perf.data (додаткову інформацію див. у розділі STARTER SCRIPTS).

.ft C
# сценарій виконання -g python
згенерований сценарій Python: perf-script.py

Вихідний файл, створений також у поточному каталозі, має назву
perf-script.py. Ось файл повністю:

# обробники подій perf script, згенеровані perf script -g python
# Ліцензується згідно з умовами ліцензії GNU GPL версії 2

# Поля обробника подій common_* є найкориснішими полями, загальними для
# всі події. Вони не обов'язково відповідають полям "common_*".
# у форматі файлів. Ці поля недоступні як параметри обробника
# можна отримати за допомогою функцій Python у вигляді common_*(context).
# Перегляньте документацію perf-script-python для отримання списку доступних функцій.

імпортувати вас
імпортувати sys

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

з імпорту perf_trace_context *
з основного імпорту *

def trace_begin():
надрукувати "in trace_begin"

def trace_end():
надрукувати "in trace_end"

def raw_syscalls__sys_enter(назва_події, контекст, common_cpu,
common_secs, common_nsec, common_pid, common_comm,
id, аргументи):
print_header(назва_події, common_cpu, common_secs, common_nsec,
common_pid, common_comm)

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

def trace_unhandled(назва_події, контекст, common_cpu, common_secs, common_nsec,
common_pid, common_comm):
print_header(назва_події, common_cpu, common_secs, common_nsec,
common_pid, common_comm)

def print_header(назва_події, процесор, секунди, nsec, pid, comm):
надрукувати "%-20s %5u %05u.%09u %8u %-20s " % \
(назва_події, процесор, секунди, нссек, pid, кому),
.ft

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

Далі наведено кілька згенерованих функцій, trace_begin() і trace_end(), які є
викликається на початку та в кінці сценарію відповідно (докладніше див
розділ SCRIPT_LAYOUT нижче).

За ними йдуть подія обробник функції, створені по одній для кожної події в пер
запис вихід. Функції обробника мають форму підсистеминазва_події, та містити названий
параметри, один та цінності кожен поле in подія; in це випадок, є тільки один подія
raw_syscallssys_enter(). (Див. розділ ОБЕРІВНИКИ ПОДІЙ нижче для отримання додаткової інформації про подію
обробники).

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

Сценарій, створений опцією -g, просто друкує рядок для кожної події, знайденої в трасі
stream, тобто він, в основному, просто скидає подію та значення її параметрів у стандартний вихід. The
Функція print_header() — це просто допоміжна функція, яка використовується для цієї мети. Давайте перейменуємо
скрипт і запустіть його, щоб побачити вихідні дані за замовчуванням:

.ft C
# mv perf-script.py syscall-counts.py
# скрипт виконання -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=
.
.
.
.ft

Звичайно, для цього сценарію ми не зацікавлені в друку кожної події трасування, а радше
агрегуючи його корисним способом. Так ми позбудемося і всього, що пов’язано з друком
як функції trace_begin() і trace_unhandled(), які ми не будемо використовувати. Це залишає
ми з цим мінімалістичним скелетом:

.ft C
імпортувати вас
імпортувати sys

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

з імпорту perf_trace_context *
з основного імпорту *

def trace_end():
надрукувати "in trace_end"

def raw_syscalls__sys_enter(назва_події, контекст, common_cpu,
common_secs, common_nsec, common_pid, common_comm,
id, аргументи):
.ft

У trace_end() ми просто надрукуємо результати, але спочатку нам потрібно згенерувати деякі результати
друкувати. Для цього нам потрібно, щоб наш обробник sys_enter() виконував необхідний підрахунок
поки всі події не будуть підраховані. Хеш-таблиця, індексована ідентифікатором системного виклику, є хорошим способом
зберігати цю інформацію; щоразу, коли викликається обробник sys_enter(), ми просто збільшуємо
кількість, пов’язана з цим хеш-записом, індексованим цим ідентифікатором системного виклику:

.ft C
системні виклики = autodict()

спробуйте:
системні виклики [ідентифікатор] += 1
крім TypeError:
системні виклики [ідентифікатор] = 1
.ft

Системні виклики автодикт object — це особливий вид словника Python (реалізований у
Core.py), який реалізує Perl автооживлення хеші в Python, тобто з автооживленням
хешів, ви можете призначати вкладені хеш-значення без необхідності створювати
проміжні рівні, якщо вони не існують, наприклад syscalls[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() ще недоступний, наразі ви можете мати справу лише з ідентифікаторами):

.ft C
імпортувати вас
імпортувати sys

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

з імпорту perf_trace_context *
з основного імпорту *
з Util import *

системні виклики = autodict()

def trace_end():
print_syscall_totals()

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

def print_syscall_totals():
якщо for_comm не є None:
надрукувати "\nsyscall події для %s:\n\n" % (for_comm),
ще:
надрукувати "\nподії системного виклику:\n\n",

надрукувати "%-40s %10s\n" % ("подія", "рахунок"),
надрукувати "%-40s %10s\n" % ("------------------------------------- ---", \
"-----------"),

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

Сценарій можна запустити так само, як і раніше:

# скрипт виконання -s syscall-counts.py

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

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

.ft C
root@tropicana:~# сценарій виконання -l
Список доступних сценаріїв трасування:
wakeup-latency загальносистемна мінімальна/макс./сер. затримка пробудження
rw за файлом r/w діяльність для програми, за файлом
rw-by-pid загальносистемна r/w активність
.ft

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

Щоб сценарій відображався як a вбудований script, ви пишете два простих сценарію, один для
запис і один для звітність.

Команда запис script — це сценарій оболонки з такою ж базовою назвою, що й ваш сценарій, але з
-запис додається. Сценарій оболонки слід помістити в perf/scripts/python/bin
каталог у дереві джерел ядра. У цьому сценарії ви пишете пер запис
командний рядок, необхідний для вашого сценарію:

.ft C
# cat kernel-source/tools/perf/scripts/python/bin/syscall-counts-record

#!/ bin / bash
perf запис -a -e raw_syscalls:sys_enter
.ft

Команда звітом script також є сценарієм оболонки з такою ж базовою назвою, що й ваш сценарій, але з
- звіт додається. Він також повинен знаходитися в каталозі perf/scripts/python/bin. в
цей сценарій, ви пишете пер сценарій -s командний рядок, необхідний для запуску вашого сценарію:

.ft C
# cat kernel-source/tools/perf/scripts/python/bin/syscall-counts-report

#!/ bin / bash
# опис: кількість системних викликів у всій системі
сценарій виконання -s ~/libexec/perf-core/scripts/python/syscall-counts.py
.ft

Зауважте, що розташування сценарію Python, наведене в сценарії оболонки, знаходиться в
каталог libexec/perf-core/scripts/python – сюди буде скопійований скрипт
зробити встановлювати коли ви встановлюєте perf. Щоб установити там свій скрипт,
ваш сценарій має бути розташований у каталозі perf/scripts/python у вихідному коді ядра
дерево:

.ft C
# ls -al kernel-source/tools/perf/scripts/python

root@tropicana:/home/trz/src/tip# ls -al tools/perf/scripts/python
Всього 32
drwxr-xr-x 4 trz trz 4096 2010-01-26 22:30 .
drwxr-xr-x 4 trz trz 4096 2010-01-26 22:29 ..
drwxr-xr-x 2 trz trz 4096 2010-01-26 22:29 bin
-rw-r--r-- 1 trz trz 2548 2010-01-26 22:29 check-perf-script.py
drwxr-xr-x 3 trz trz 4096 2010-01-26 22:49 Perf-Trace-Util
-rw-r--r-- 1 trz trz 1462 2010-01-26 22:30 syscall-counts.py
.ft

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

.ft C
root@tropicana:~# сценарій виконання -l
Список доступних сценаріїв трасування:
wakeup-latency загальносистемна мінімальна/макс./сер. затримка пробудження
rw за файлом r/w діяльність для програми, за файлом
rw-by-pid загальносистемна r/w активність
syscall-counts Кількість системних викликів у всій системі
.ft

Тепер ви можете виконати крок запису через пер сценарій запис:

# запис сценарію perf кількість системних викликів

і відобразити результат за допомогою пер сценарій звітом:

# Perf script повідомляє про кількість системних викликів

СТАРТЕР СЦЕНАРІЇ

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

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

EVENT ОБРУЧНИКИ

Коли сценарій perf викликається за допомогою сценарію трасування, визначається користувачем обробник функція is
викликані для кожної події в трасі. Якщо для заданої функції не визначено функції обробника
типу події, подія ігнорується (або передається a trace_handled функція, див. нижче) і
обробляється наступна подія.

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

Як приклад, наступну команду perf record можна використовувати для запису всього sched_wakeup
події в системі:

# запис perf -a -e sched:sched_wakeup

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

Файл формату події sched_wakep визначає наступні поля (див
/sys/kernel/debug/tracing/events/sched/sched_wakeup/format):

.ft C
формат:
поле:unsigned short common_type;
поле: unsigned char common_flags;
поле: unsigned char common_preempt_count;
поле:int common_pid;

поле: char comm[TASK_COMM_LEN];
поле:pid_t pid;
field:int prior;
field:int успіх;
поле: int target_cpu;
.ft

Функція обробника для цієї події буде визначена як:

.ft C
def sched__sched_wakeup(назва_події, контекст, common_cpu, common_secs,
common_nsec, common_pid, common_comm,
comm, pid, prio, success, target_cpu):
проходити
.ft

Функція обробника має вигляд subsystem__event_name.

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

Ось короткий опис кожного з аргументів інваріантної події:

event_name назва події у вигляді тексту
контекст непрозорий «cookie», що використовується для зворотних викликів у perf
common_cpu процесор, на якому сталася подія
common_secs - частина секундної позначки часу події
common_nsecs частина nsecs часової позначки події
common_pid — ідентифікатор поточного завдання
common_comm ім'я поточного процесу

Усі решта полів у файлі формату події мають відповідники як обробники
однойменні аргументи функції, як можна побачити в прикладі вище.

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

SCRIPT ЗОВНІШНІЙ ВИД

Кожен сценарій Perf Python має починати з налаштування шляху пошуку модуля Python і
'імпортування кількох модулів підтримки (див. опис модулів нижче):

.ft C
імпортувати вас
імпортувати sys

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

з імпорту perf_trace_context *
з основного імпорту *
.ft

Решта сценарію може містити функції обробника та функції підтримки в будь-якому порядку.

Окрім функцій обробника подій, розглянутих вище, кожен сценарій може реалізувати набір
додаткові функції:

trace_begin, якщо визначено, викликається перед обробкою будь-якої події та дає сценарії a
можливість виконати завдання з налаштування:

.ft C
def trace_begin:
проходити
.ft

trace_end, якщо визначено, викликається після обробки всіх подій і надає сценарії a
можливість виконувати завдання в кінці сценарію, наприклад відображати результати:

.ft C
def trace_end:
проходити
.ft

trace_unhandled, якщо визначено, викликається після для будь-якої події, яка не має обробника
явно визначено для нього. У нього передається стандартний набір поширених аргументів:

.ft C
def trace_unhandled(назва_події, контекст, common_cpu, common_secs,
common_nsec, common_pid, common_comm):
проходити
.ft

Решта розділів містять описи кожного з доступних вбудованих сценаріїв perf
Модулі Python та пов’язані з ними функції.

В НАЯВНОСТІ МОДУЛІ І ФУНКЦІЇ

Наступні розділи описують функції та змінні, доступні через різні perf
скриптові модулі 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
автооживлення хеші в 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 для поточної події

Util.py Модулі
Різні допоміжні функції для використання зі скриптом perf:

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

Використовуйте perf-script-python онлайн за допомогою служб onworks.net