Профилирование для стенного времени в Linux

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

Я пробовал oprofile, но кажется, что он дает время с точки зрения циклов Unhalted CPU (это время процессора, а не реальное время)

Я пробовал strace -T, который дает время стены, но генерируемые данные огромны, и получить сводный отчет сложно (и для этого существуют сценарии awk/py?)

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

Мне нужно, чтобы кто-то указал мне правильное направление. Большое спасибо!


profiling strace systemtap
person sandt1g3r    schedule 05.07.2011    source источник
comment
Что касается системных вызовов: syscalltime — комбинированный скрипт shell/systemtap для измерения количества и времени системных вызовов. Можно фильтровать по идентификаторам процессов, именам процессов и пользователям.sourceware.org/systemtap/examples/process/ системное время   -  person    schedule 13.12.2013

Ответы (3)


arrow_upward
5
arrow_downward

Судя по этой фиксации, недавно выпущенная версия strace 4.9 поддерживает это с помощью:

strace -w -c

Они называют это "задержкой системного вызова" (и трудно понять только из справочной страницы, что делает -w).

person Nickolay    schedule 04.10.2014
comment
Это рабочее решение. Не могу поверить, что это было добавлено только в 2014 году. - person nh2; 15.03.2015
comment
И я не могу поверить, что его до сих пор нет в CentOS 7! - person ndemou; 05.05.2017
comment
Хорошо, что strace.io указывает на build.opensuse.org/package/show /home:ldv_alt/strace, где есть пакеты для многих дистрибутивов. - person ndemou; 05.05.2017

arrow_upward
1
arrow_downward

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

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

person Mike Dunlavey    schedule 05.07.2011
comment
конечной целью может быть ускорение, а случайная пауза может быть быстрым путем к решению, но я бы предпочел иметь надлежащий анализ, который может быть представлен при необходимости, спасибо, кстати. - person sandt1g3r; 05.07.2011

arrow_upward
1
arrow_downward

См. пример сценария fntimes.stp systemtap. https://sourceware.org/systemtap/examples/index.html#profiling/fntimes.stp

Сценарий fntimes.stp отслеживает историю времени выполнения данного семейства функций (предполагается, что оно не рекурсивное). Каждый раз (после интервала прогрева) затем сравнивается с историческим максимумом. Если он превышает определенный порог (250%), печатается сообщение.

# stap fntimes.stp 'kernel.function("sys_*")'

or

# stap fntimes.stp 'process("/path/to/your/binary").function("*")'

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

probe $1.return { elapsed = gettimeofday_us()-@entry(gettimeofday_us()) }
person fche    schedule 04.10.2014