LINUX.ORG.RU

Как искать узкие места (bottleneck)

 ,


4

6

Какое то неприличное название у темы получилось, ну да ладно.

Хотел бы спросить совета, как вы профилируете свои программы? Как ищите bottleneck'и? В первую очередь интерестно как это делается для сетевых event driven приложений.

valgring + callgrind, очевидно в этом плане не подходит. Так как он замеряет процессорное время. Т.е. он не позволит определить что у вас два потока постоянно тыкаются в один мютекс и ждут его. Helgrind вообще не понятно как применять если в проекте есть что то кроме стандартного мютекса (даже бустовый с его atomic уже наверно вызовет проблеммы).

Google CPU Profiler, уже лучше, хотя я таки тоже не уверен, что он сможет показать, что кто то уткнулся в мютекс. Я спциально попробывал все свои обработчики в приложении стравить на один mutex под которым еще и sleep происходит. Но в результате профилирования, этого участка вообще нету, а большую часть захвал именно IO хотя стреляю все локально.

Я в профилировании еще профан, хотелось бы услышать от кого то более опытного в этом деле на что стоит обратить внимание при профилировании, может быть какие то техники использовать.

Большинство статей которые у нашел/прочитал это самые азы использования профайлера. Так же встречаются статью на счет особенностей ошибочного отображения/подсчета данных профайлером.

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


У нас как раз сетевое приложение. Google CPU Profiler Делаем обертку над мутексом, засекаем время ожидания Делаем обертку над DAO, засекаем количество и время выполнения вызовов.

Все это можно запустить и в продакшене.

vromanov ★★ ()

может быть какие то техники использовать.

Сбор различного рода статистик в реальном времени. От времён выполнения различных транзакций до времени ожидания конкретного ресурса (блокировки). В выводе гистограмки + slow logs.

Подробные трейсы выполнения некоторых транзакций с задержками. Как, например, сделано в трейсах oracle db. Можно писать не для всех запросов, а для определённого процента с целью контроля качества.

mashina ★★★★★ ()
Ответ на: комментарий от queen3

Похоже всетаки не отвертеться мне от Intel VTune. А что в нем такого волшебного, что он вот умеет это делать, а все остальные нет?

Cupper ()

Ещё некоторую информацию может дать strace -T -c. Хотя тут детализация будет только по тому, какие есть системные вызовы и сколько они тратят времени. Это больше применимо, если проблема в работе с fs.

YesSSS ★★★ ()
Ответ на: комментарий от queen3

perf lock record ls
tracepoint lock:lock_acquire is not enabled. Are CONFIG_LOCKDEP and CONFIG_LOCK_STAT enabled?

как им пользоваться? Весь инет перерыл и кроме офф вики страницы в которой ничего не понятно, не нашел ни одного примера как пользоваться этим профайлером.

Cupper ()
Ответ на: комментарий от Cupper

Не знаю что такое perf lock и зачем он. Пользоваться просто:

perf record PROGRAM
perf report

Можно
perf -g -c 150000 PROGRAM
чтобы получить стеки (-g) и как часто сэмплы делать (-c).

И какой у тебя perf? Например в убунте надо ставить linux-tools-common и или как там этот пакет.

queen3 ★★★★★ ()

Мне недавно рассказали о профилировании «по бомжу»: запускаешь программу под отладчиком, а потом раз 10 через равные промежутки времени прерываешь. В какой функции больше раз оказался — та и проблемная. Даже выкладки были согласно теории вероятности, где показывалось, что этот метод работает с приемлемой точностью.

uuwaan ★★ ()
Ответ на: комментарий от Cupper

Ну там ещё и утечки ищутся. И представляются удобно графически. Я не пользовался, но у коллеги наблюдал - вроде удобно.

queen3 ★★★★★ ()
Ответ на: комментарий от uuwaan

Он работает, если сильно тупой метод лагает (типа файл в цикле читается зря).

queen3 ★★★★★ ()
Ответ на: комментарий от uuwaan

уху, читал этот пост на stackoverflow. Попробовал, отлично работает. Но это так сказать первый этап :)

Cupper ()
Ответ на: комментарий от Cupper

Причем тут sudo, тут в ядре загвоздка.

А, ну да. Спутал с perf sched, который не от рута не работает.

i-rinat ★★★★★ ()

Сбор статистики самим приложением (если принять меры для исключения пересечения по кэш линиям с другими процессорами, то это практечески бесплатно и можно оставить в продакшен) плюс сэмплирование.

Relan ★★★★★ ()
Ответ на: комментарий от Relan

Мы сделали програмку коотрая выводит информацию о самых нагруженных SQL запросах. Засекается сколько времени программа проводит выполняя каждый запрос и выводится. Очень удобно - видно сразу какой запрос надо оптимизировать :)

vromanov ★★ ()
Ответ на: комментарий от vromanov

Засекается сколько времени программа проводит выполняя каждый запрос и выводится.

Сама СУБД этим разве не занимается?

i-rinat ★★★★★ ()

Если callgrind не катит, oprofile спасет отца русской демократии

annulen ★★★★★ ()

OProfile, покажет где программа проводит много времени

gprof когда-то был, мне очень нравился, он точнее, чем OProfile, но не уверен, что до сих пор жив.

elijah_sd ()

Можешь попробовать http://www.rotateright.com/ zoom, только он платный. Собираешь программу в debug версии. Запускаешь в zoom мониторинг и запускаешь свою программу. После завершения программы - в zoom - stop и выбираешь процесс.

bhfq ★★★★★ ()
Ответ на: комментарий от bhfq

Собираешь программу в debug версии.

Спасибо, а что-то более разумное? Обычно только идиоты меряют скорость в debug.

Pavval ★★★★★ ()
Ответ на: Йидрить какой ты тугой! от bhfq

Чтоб ты знал, Debug билдами называются -O0 билды, а Release With Debug info называется (ты не поверишь!!!) - «Release With Debug info». А Release в целом называются все билды, собранные с включенной оптимизацией.

Pavval ★★★★★ ()
Ответ на: комментарий от i-rinat

Вот пример вывода нашей утилитки. Т.к. приложение может работать с разными базам (PG и TT), то эта утилита будет показывать информацию в обоих случаях и в одном виде. Видно, что самый жрущий запрос stmt_increment_accum. Он выполняется 8 тысяч раз в секунду и занимает 22% времени относительно остальных запросов. Также можно понять, что приблизительно 37% времени CPU тратится на работу с базой данных. http://freepcrf.com/images/tt_perf_info.png

vromanov ★★ ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.