Добавлено: 13/09/04 в 12:30

Назрел очередной вопрос...

есть скрипт который вместо расчетных 0.5 переодически грузит процессор на 5% и более.
Хотелось бы выяснить какая команда или строчка вызывает большую нагрузку.
Скрипт довольно большой и использует пару вложенных скриптов и баз данных поэтому эксперементировать непосредственно с кодом довольно сложно.
Может есть какой нибудь дебагер или утилиты которые позволят определить что именно грузит процессор ?

Добавлено: 13/09/04 в 13:13

что за скрипт? какая платформа?

если исполняемый файл могу посоветовать truss (unix), strace (linux)
выводит системные вызовы и можно определить место где реурсы особенно сильно используются.

Если скрипт на php/perl можно попытаться в коде навставлять
что-нибудь типа print "Line ..." между сомнительными участками.
и паралельно с выводом этих строк смотреть на загрузку проца.

Посмотри, используется ли активно ОЗУ при пике процессора, это поможет определить узкое место или плохой алгоритм.

Проц может юзаться при активном вводе-выводе, при обработке больших массивов, при сложно сравнение строк...

Что еще посоветовать... ну можно внутри таймеров навставлять, чтобы высчитать время отработки каждого блока программы.

Добавлено: 13/09/04 в 14:28

скрипт на РНР.
работает буквально 2 секунды, так что делать принт и смотреть загруз проца - нереально.
как определять загрузку процессора конкретным скриптом из него самого я не знаю ...
т.е. теоритически конечно можно запустить скрипт к примеру от нободи с уникальным именем, а потом из скрипта делать переодически системный топ и смотреть на нужную строку... но имхо это ни даст никаких реальных значений так как данные к моменту выполнения этих команд будут уже не актуальны.

озу пользуется равномерно. единственные сомнения которые у меня были - это пара циклов... поставил в циклы команду (usleep 800) на нагрузку проца это не повлияло - значит имхо не в них дело.
больше идей не было... а код действительно большой, почти 2000 строк

Добавлено: 13/09/04 в 15:22

со скриптами конечно сложнее
проц там отследить сложно... если есть малейшие подозренияна циклы, ищи в них.. можешь сюда выложить куски, подскажу может что..

bog писал:

скрипт на РНР. работает буквально 2 секунды, так что делать принт и смотреть загруз проца - нереально. как определять загрузку процессора конкретным скриптом из него самого я не знаю ... т.е. теоритически конечно можно запустить скрипт к примеру от нободи с уникальным именем, а потом из скрипта делать переодически системный топ и смотреть на нужную строку... но имхо это ни даст никаких реальных значений так как данные к моменту выполнения этих команд будут уже не актуальны. озу пользуется равномерно. единственные сомнения которые у меня были - это пара циклов... поставил в циклы команду (usleep 800) на нагрузку проца это не повлияло - значит имхо не в них дело. больше идей не было... а код действительно большой, почти 2000 строк

Добавлено: 13/09/04 в 17:55

www.xdebug.org спасет отца русской демократии.
Еще zend studio неплохо помогает.

Добавлено: 13/09/04 в 21:34

спасибо.
пошел ставить

Добавлено: 13/09/04 в 23:22

Вообще я в своей практике просто разбивал на части и замерял _время выполнения_ каждой части. Та которая дольше всего выполняется и грузит проц болей всего. Почти всегда срабатывало.

Добавлено: 14/09/04 в 22:34

проц тормозят: глупые циклы, неоптимальные аглоритмы работы с большими списками
диск тормозят: операции open (php:include без оптимайзера), и собственно все операции работы с диском

Добавлено: 14/09/04 в 22:39

bog:

Попробуй вот это.

http://sourceforge.net/projects/php-profiler/