2011-02-03 4 views
0

Я использую PHP + Zend Framework для нескольких демонов CLI. Они занимают довольно много памяти. Я предполагаю, что часть Zend Framework может вызвать это, но я хочу, чтобы факты показывали мне, где память пропала даром.PHP CLI - определить, где моя память впустую

Как определить, где пропала память? Это просто процесс пробной + ошибки? Также как я могу улучшить сбор мусора (я прочитал некоторые статьи, что это также может быть проблемой, вызывающей большую память).

+1

Посмотрите на этот вопрос: http://stackoverflow.com/questions/4286193/track-memory-usage-of-a-method –

ответ

1

Я бы рекомендовал использовать профилировщик XDebug, который должен дать вам ответы, которые вам нужны.

Профайлер будет генерировать файл cachegrind, который вы можете просмотреть в инструменте, таком как KCacheGrind, чтобы узнать, где находятся узкие места и возможности использования вашей программы.

Узнайте больше на странице профайлера XDebug в: http://www.xdebug.org/docs/profiler

+0

Насколько я могу рассказать профайлеру только профили времени, а не потребление памяти ? –

+0

@Sebastian Hoitz, http://xdebug.org/docs/execution_trace - он (xdebug) тоже может трассировать потребление памяти – binaryLV

0

Какая версия PHP вы используете? Только PHP> = 5.3 имеет достойный сборщик мусора. PHP < = 5.2 может съесть всю вашу память, когда используется для запуска сценариев демона.

+0

Не обязательно - только если у вас возникла проблема с ссылками на изоляцию (объекты особенно плохие для этого - но вы получаете ту же проблему с массивами). – symcbean

+0

5.3 добавить только «круглый контрольный детектор». Остальная часть GC идентична – KingCrunch

+0

По моему опыту, не требуется многого, чтобы процесс демонстрации PHP 5.2 съел всю память. Мое дело было просто простым рабочим на основе Zend_Queue. Даже когда вы возвращаетесь к исключению объектов и запускаете пустой цикл while, он продолжал есть память до тех пор, пока не будет достигнут «memory_limit», и демон само себя убил. С PHP 5.3 эти проблемы исчезли. К сожалению, нет PHP 5.3 еще на производственных серверах :-). – Htbaa

1

IME, PHP использует огромное количество памяти для разбора кода - попробуйте создать простой скрипт, который ничего не делает, кроме явно всех используемых вами библиотек, и отслеживает использование памяти при запуске/завершении. Сравните это с тем, что вы видите в своем подлинном скрипте.

Htbaa частично корректен - более свежие версии PHP имеют гораздо более умный сборщик мусора, однако более ранние версии все еще делают сборку мусора - они просто не находят все случаи, которые делает новый gc. Но из-за его сбора мусора вы обычно видите что-то вроде пилообразной памяти при использовании постоянной входной нагрузки.

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

Смежные вопросы