Как представить мое приложение C++ на Linux
Я хотел бы представить свое приложение C++ на Linux. Я хотел бы узнать, сколько времени мое приложение провело на обработке ЦП по сравнению со временем, проведенным на блоке неактивным IO/being.
Я знаю, что существует вызов инструмента профиля valgrind на Linux. Но это повреждает время простоя, проведенное на каждый метод, и это не дает мне общую картину того, сколько время потратило на обработку ЦП по сравнению с неактивным? Или есть ли способ сделать это с valgrind.
8 ответов
Я могу порекомендовать valgrind инструмент callgrind в сочетании с KCacheGrind для визуализации . KCacheGrind позволяет довольно легко увидеть, где находятся горячие точки.
Примечание: прошло слишком много времени с тех пор, как я его использовал, поэтому я не уверен, что вы сможете получить из этого время ожидания ввода-вывода. Возможно, в сочетании с iostat или pidstat вы сможете увидеть, на что было потрачено все время.
Проверьте профиль . Также для получения дополнительной диагностики на уровне системы попробуйте systemtap .
Вы можете попробовать Zoom , который намного более отполирован и полнофункциональный, чем oprofile и др. . Это стоит денег (199 долларов), но вы можете получить бесплатную 30-дневную пробную лицензию.
LTTng - хороший инструмент для полного профилирования системы.
Если ваше приложение просто работает "вхолостую" (т.е. оно либо использует CPU, либо ожидает ввода/вывода) до выхода, и нет других конкурирующих процессов, просто сделайте time myapp (или, возможно, /usr/bin/time myapp, который выдает немного другой результат, чем встроенный shell).
Это даст вам что-то вроде:
real 0m1.412s
user 0m1.288s
sys 0m0.056s
В этом случае время пользователя+sys (ядра) составляет почти все реальное время, и только 0,068 с неучтенного времени... (вероятно, время, затраченное на первоначальную загрузку приложения и его вспомогательных библиотек).
Однако, если бы вы увидели:
real 0m5.732s
user 0m1.144s
sys 0m0.078s
то ваше приложение потратило 4,51 с, не потребляя CPU и, предположительно, блокируя IO. Это та информация, которую, как я думаю, вы ищете.
Однако, где эта простая техника анализа ломается:
- Приложения, которые ждут таймера/часов или другого внешнего стимула (напр. приложения GUI, управляемые событиями). Он не может отличить время ожидания на часах и время ожидания на диске/в сети.
- Многопоточные приложения, которым нужно немного больше думать, чтобы интерпретировать цифры.
Инструменты лакея и / или helgrind в valgrind должны позволить вам это сделать.
По сути, между запуском программы и ее завершением у нее есть стек вызовов. Во время ввода-вывода стек завершается системным вызовом. Во время вычисления он завершается типичной инструкцией.
В любом случае, , если вы можете опробовать стек в случайное время настенных часов, вы можете точно понять, почему он тратит это время.
Остается только один момент: тысячи образцов могут дать чувство уверенности, но они не скажут вам намного больше, чем 10 или 20 образцов.
callgrind - очень хороший инструмент, но OProfile мне показался более «полным». Кроме того, это единственный способ указать исходный код модуля и / или ядра, чтобы глубже понять ваши узкие места. Предполагается, что вывод может взаимодействовать с KCacheGrind, но у меня с этим возникли проблемы, поэтому я использовал вместо него Gprof2Dot . Вы можете экспортировать ваш callgraph в .png.
Редактировать:
OProfile смотрит на систему в целом, поэтому процесс будет выглядеть следующим образом:
[профиль настройки]
opcontrol --init
opcontorl --vmlinux=/path/to/vmlinux (or --no-vmlinux)
opcontrol --start
[запустите свое приложение здесь]
opcontrol --stop (or opcontrol --shutdown [man for difference]
затем, чтобы начать просмотр результатов, просмотрите страницу руководства по opreport