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

Question

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

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

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

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

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

Answer 1

Исходя из этого коммита , недавно выпущенный strace 4.9 поддерживает это с:

strace -w -c

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

Answer 2

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

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

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

или

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

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

probe $1.return { elapsed = gettimeofday_us()-@entry(gettimeofday_us()) }

Answer 3

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

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