Решено! Как определить узкое место системы (проц/память/винт/настройки системы)?

[Int_20h]

Очень странная ситуация происходит у меня на домашнем сервере (AMD Phenom II x2 555, Socket AM2+, 4Gb RAM).

Там стоит:
Apache/2.2.14 (Ubuntu)
MySQL 5.1.41-3ubuntu12.6
PHP 5.3.2

На данном сервере я отлаживаю свои PHP-скрипты, часть из которых объектно ориентированные с использованием MySQL. Некоторые из этих скриптов ОЧЕНЬ объектно ориентированные, т.е. работают с объектами, исходники которых занимают по 50Kb, при этом данные объекты содержат внутри себя еще несколько объектов и т.д.

Недавно потребовалось пересчитать свойства в 150-300 таких объектах, запустил я скрипт и он выполнялся примерно 40-50 секунд. В целом не очень большое время для такого объема информации, но, естественно, обработку хочется ускорить. Для того чтобы оценить загрузку процессора запускаю top во время выполнения скрипта и вижу только mysqld, который грузит процессор на 1%. iotop тоже ничего особенного не показывает.

Получается ОЧЕНЬ СТРАННАЯ ситуация: скрипт выполняется почти минуту, php проц не загружает вообще, mysql его загружает на 1%, apache'а в top'е нет и в помине.
Теперь меня мучает вопрос: что мешает при таких обстоятельствах загрузить процессор хотя бы на 50% и выполнить скрипт не за минуту, а за 10 секунд?
Как узнать в какое узкое место уперлась система?
Пользователь решил продолжить мысль 24 Октября 2010, 17:39:41:P.S. Никаких данных из сети в объектах не содержится, т.е. от скорости канала время обработки не зависит.

[Raptor26]

может жесткий диск или фаиловая система на нем?

[Sam Stone]

1) iotop (мож чего с винта усиленно читает)
2) дебажить не учили?

[Int_20h]

kostja@srv232:~$ iotop
Total DISK READ: 127.94 K/s | Total DISK WRITE: 410.95 K/s
  TID  PRIO  USER     DISK READ  DISK WRITE  SWAPIN     IO>    COMMAND
11046 be/4 mysql       3.88 K/s  108.55 K/s  ?unavailable?  mysqld

iotop нечего особенного не показывает. Диски в системе легко выдают 90Mb/s на чтение и 80Mb/s на запись, значения которые дает iotop даже "нагрузкой" язык не поворачивается назвать...

А зачем дебажить? Я могу поставить xDebug, покажет он мне что такая-то процедура выполняется 100 раз по 0,5 секунды, а дальше-то что?

Я логично предполагаю, что если бы PHP занял 99% процессорного времени, то процедура бы выполнялась не по 0,5 секунды, а по 0,005 секунды. Как дебагер мне поможет понять, почему этого не происходит?

Вопрос не в том, где в моем коде ошибка (я подразумеваю, как раз, что он очень хорошо оптимизирован), вопрос в том, почему вся эта братия (Apache, PHP, MySQL) загружают процессор на 1%, при  этом скрипт выполняется 50 секунд?

P.S. Еще удивляет то, что PHP и Apache'а, в отличие от mysql, в top'е вообще не значатся.

[Дмитрий Бо]

А в php.ini или как там его ограничение на мозги не стоит? Или ещё где.

[gregory5]

Диски в системе легко выдают 90Mb/s на чтение и 80Mb/s на запись

Стояли такие диски, после смены на одноблинкик со скоростью чтения 140 мб записи 1хх мб, я заметил ощутимый прирост отклика системы, также возросла скорость поиска, 80-90 мб это либо довольно старые hdd либо замедленные грин версии, предназначение у таких дисков как правило файло помойка, но ни как не система где требуется хороший отклик, следующий шаг это построение массивов различной сложности (другие варианты не предлагаю т.к. дороги)

[Int_20h]

в php.ini стоит

memory_limit = 1024M

не знаю. есть ли инструкция,которая ограничивает лимит процессорного времени в php, я ее точно не настраивал.

насчет дисков - да, это WD Green 5400rpm, но вряд ли это объясняет проблему. База MySQL занимает 50Mb, хранится в innoDB. На компе с 4 Gb памяти вся эта база должна быть закэширована 10 раз. Я просто не могу поверить в то, что даже самый медленный диск при таком размере базы будет вызывать такие тормоза.

Впрочем, сегодня вечером специально перенесу базу на tmpfs и проверю производительность.

[Sam Stone]

А зачем дебажить? Я могу поставить xDebug, покажет он мне что такая-то процедура выполняется 100 раз по 0,5 секунды, а дальше-то что?

Оптимизировать ее. Может ты ее и хорошо написал для единичного запуска, а когда сотни раз в цикле начинаешь крутить - вылезают все задержки. 100 простых селектов из базы не всегда быстрее одного сложного.
Как вариант - попробовать на другом хосте запустить (например на виртуалке).

dbg

[alecsartania]

А зачем дебажить?

надо выяснить куда деваются временные таймы при выполнении программы, а то мож все таки кто-то кого то ждет а потом быстро быстро выполняется ;-)
тогда надо семафор этот ловить. например какой общий ресурс лочится.
 дебаг.

[Int_20h]

Огромное спасибо всем, кто помогал. Особенно alecsartania и Sam Stone.

Вопрос решен. Пока я пребываю в неком шоке, поскольку не могу логически объяснить результатов...

Ребята подсказали про семафор и лоченые ресурсы, я подумал, что единственная зона, где может возникнуть подобный семафор - MySQL. Начал копать дальше, прочитал, что базы в MyISAM, в отличие от InnoDB, производят параллельные вставки. Поскольку при пересчете свойств объектов они сначала считывались, а потом сохранялись, подумал, что это может иметь значение. Сменил формат баз данных, в которых хранились свойства, на MyISAM.

В результате, тот же самый скрипт без изменений за 0,5 секунды просчитывает массив в 10 раз больше чем раньше. MySQL при этом, как и положено, загружает процессор на 50-60%.

Вот такой вот бред... За счет смены формата баз удалось добиться ускорения в сотни раз...