php-fpm 5.3.0 FreeBSD 7.2- amd64

Очень странное поведение,
слетает в свап и виснет. В логах ничего нет.

перед слетом обнаружили, что php-cgi процессы отжирают много памяти (более гига ).
появляется раз в день, отловить ситуацию не просто. Пока сделали мягкий рестарт php-fpm раз в пару часов.

проверил на утечки некоторые новые используемые расширения на 32 битном AMD (Ubuntu)- нет

valgrind под amd46 не устанавливается, проверить им утечки на FreeBsd не могу.

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

Вопросы:
- какими инструментами, как и что именно смотреть?

попробуйте мемтрак
http://pecl.php.net/package/memtrack

2009/12/17 Alexandre Kalendarev <akalend@mail.ru>:
> php-fpm 5.3.0 FreeBSD 7.2- amd64
>
> Очень странное поведение,
> слетает в свап и виснет. В логах ничего нет.
>
> перед слетом обнаружили, что php-cgi процессы отжирают много памяти (более гига ).
> появляется раз в день, отловить ситуацию не просто. Пока сделали мягкий рестарт php-fpm раз в пару часов.
>
> проверил на утечки некоторые новые используемые расширения на 32 битном AMD (Ubuntu)- нет
>
> valgrind под amd46 не устанавливается, проверить им утечки на FreeBsd не могу.
>
> есть предположение, что какой-то php процесс после рестарта не чистит память. с какого-то момента - память php процессов начинает быстро расти.
>
> Вопросы:
> - какими инструментами, как и что именно смотреть?
>



--

wbr,
fisher

Алексей,

спасибо за совет,
это скореевсего к Тонни:

memtrack не удалось запустить
пишет unable to initialize module
Module compiled with build ID=API20090626,NTS,debug

прописал в php.ini
[memtrack]
memtrack.enabled=1
memtrack.soft_limit=100M


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

какие еще могут быть идеи?


-----Original Message-----
From: "Alexey A. Rybak" <alexey.rybak@gmail.com>
To: highload-php-ru@googlegroups.com
Date: Thu, 17 Dec 2009 14:53:17 +0300
Subject: Re: php-fpm утечки?, куда рыть

> попробуйте мемтрак
> http://pecl.php.net/package/memtrack
>
> 2009/12/17 Alexandre Kalendarev <akalend@mail.ru>:
> > php-fpm 5.3.0 FreeBSD 7.2- amd64
> >
> > Очень странное поведение,
> > слетает в свап и виснет. В логах ничего нет.
> >
> > перед слетом обнаружили, что php-cgi процессы отжирают много памяти (более гига ).
> > появляется раз в день, отловить ситуацию не просто. Пока сделали мягкий рестарт php-fpm раз в пару часов.
> >
> > проверил на утечки некоторые новые используемые расширения на 32 битном AMD (Ubuntu)- нет
> >
> > valgrind под amd46 не устанавливается, проверить им утечки на FreeBsd не могу.
> >
> > есть предположение, что какой-то php процесс после рестарта не чистит память. с какого-то момента - память php процессов начинает быстро расти.
> >
> > Вопросы:
> > - какими инструментами, как и что именно смотреть?
> >
>
>
>
> --
>
> wbr,
> fisher
>

On 17.12.2009 18:02, Alexandre Kalendarev wrote:
> Алексей,
>
> спасибо за совет,
> это скореевсего к Тонни:
>
> memtrack не удалось запустить
> пишет unable to initialize module
> Module compiled with build ID=API20090626,NTS,debug

Собран не с теми хидерами.
Или вообще не для того PHP.

--
Wbr,
Antony Dovgal
---
http://pinba.org - realtime statistics for PHP

2009/12/17 Alexandre Kalendarev <akalend@mail.ru>:
> Алексей,
>
> спасибо за совет,
> это скореевсего к Тонни:
>
> memtrack не удалось запустить
> пишет unable to initialize module
> Module compiled with build ID=API20090626,NTS,debug

дык а сам пхп как собран?

>
> прописал в php.ini
> [memtrack]
> memtrack.enabled=1
> memtrack.soft_limit=100M
>
>
> не думаю, что мемтреком можно отловить утоечку, он ловит внутренние аллокейты,
> а здесь мне кажется причина какая-то системная.

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

> самое страшное, что я не могу ее локализовать (не понятно кто виноват), не остается ни каких следов после падения.
>
> какие еще могут быть идеи?
--

wbr,
fisher

> > memtrack не удалось запустить
> > пишет unable to initialize module
> > Module compiled with build ID=API20090626,NTS,debug
>
> Собран не с теми хидерами.
> Или вообще не для того PHP.
PHP 5.3.1 --with-fpm

PHP 5.3.1 --with-fpm --with-xcache
все модули, кроме xdebug собраны статически

memtrack подгружается динамически. Статически мне не удалось его подцепить,
buildconf его не видит, соответственно в configure нет опции --enable-memtrack
Autoconf 2.13

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

Леш, а по каким причинам эти аллокейты не осовобождались: ошибка в коде или косяки в самом экстеншене?

>
>> по-моему, это необоснованное, и сталобыть с некоторой вероятностью
>> ошибочное мнение. на моей практике именно "внутренние аллокейты" чаще
>> всего потом не высвобождались по каким-то причинам, но по крайней
>> мере, было ясно где копать, и было видно как пухнет процесс.
>>
>
> Леш, а по каким причинам эти аллокейты не осовобождались: ошибка в коде или косяки в самом экстеншене?

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

--

wbr,
fisher

использую много где eaccelerator - полёт нормальный.

собран динамически.


2009/12/24 Alexandre Kalendarev <akalend@mail.ru>

>
> В ходе экспериментов оказалось, что процессы бухнут из-за xcache
> скорость разбухания: где-то по 1-2 Мб за 3-5 мин вначале и 10-15 Мб через
> два-три часа,
> через четыре объем процесса занимает 600-700М и память уходит в своп... а
> еще через пару наступает пппц...
> правда решили эту проблему мониторингом занимаемой процессами памяти и
> мягким перезапуском php-fpm. С мягким перезапуском тоже оказались следующие
> проблемы: если скрипт быстрый, то он приостанавливается, если скрипт тяжелый
> (работает от 15-до 20 сек) и в это время приходит USR2, то на клиент
> приходит ERR 302.
>
> после отключения xcache все встало в норму и объем, занимаемый одним
> процессом остается на уровне 115-150 Мб.
> xcache - был прилинкован динамически. Может попробовать собрать статически?
>
> кто наблюдал похожие явления,
> какой акселератор лучше использовать с php-fpm?
>
>
> Alexandre
>



--
Ilyas R. Khasyanov
Unix/Linux System Administrator
GPG Key ID: 6EC5EB27 (Changed since 2009-05-12)

Alexandre Kalendarev wrote:
> после отключения xcache все встало в норму и объем, занимаемый одним процессом остается на уровне 115-150 Мб.
> xcache - был прилинкован динамически. Может попробовать собрать статически?
>
> кто наблюдал похожие явления,
> какой акселератор лучше использовать с php-fpm?
>
Я использую APC, без проблем. С xcache выгребал глюки и на mod_php.

Thursday, December 24, 2009, 12:18:19 AM, Alexandre wrote:


> В ходе экспериментов оказалось, что процессы бухнут из-за xcache
> скорость разбухания: где-то по 1-2 Мб за 3-5 мин вначале и 10-15 Мб через два-три часа,
> через четыре объем процесса занимает 600-700М и память уходит в
> своп... а еще через пару наступает пппц...
> правда решили эту проблему мониторингом занимаемой процессами
> памяти и мягким перезапуском php-fpm. С мягким перезапуском тоже
> оказались следующие проблемы: если скрипт быстрый, то он
> приостанавливается, если скрипт тяжелый (работает от 15-до 20 сек) и
> в это время приходит USR2, то на клиент приходит ERR 302.

> после отключения xcache все встало в норму и объем, занимаемый
> одним процессом остается на уровне 115-150 Мб.
> xcache - был прилинкован динамически. Может попробовать собрать статически?

> кто наблюдал похожие явления,
> какой акселератор лучше использовать с php-fpm?

Какая версия xcache?
Какая OS?

--
Sergey

Sergey Kobzar wrote:
>> какой акселератор лучше использовать с php-fpm?
Все акселераторы не без греха. Только экперимент позволяет выявить
лучший для данных конкретных условий.

Я много лет использовал eaccelerator, ещё с тех пор, как он назывался
turck-mmcache. И с апачем, и с php-fcgi, и с php-fpm. Привык к его
закидонам, научился их как-то обходить. В итоге, он меня устраивает, я
другого не хочу. Кто-то пользуется APC с момента его появления, кому-то
больше нравится xcache. Тут дело не в том, что лучше, а в том, что
больше подходит под твои задачи.

> Какая версия xcache?
> Какая OS?
Ты-б сразу и сказал, на какой версии оно у тебя так текло и на какую
откатился :-)

Thursday, December 24, 2009, 8:51:15 AM, Andrey wrote:

>> Какая версия xcache?
>> Какая OS?
> Ты-б сразу и сказал, на какой версии оно у тебя так текло и на какую
> откатился :-)

:)

Текло на 1.3.0, откатился на 1.2.2 - течь перестало.

Недавно накатился снова на 1.3.0 - вроде бы нормально, но пока на 100%
сказать не могу.

Разница между 1.2.2 и 1.3.0 - в основном поддержка php 5.3. Если не
критично, то лучше оставаться на 1.2.2 IMO.


Gentoo Linux amd64/10.0
Linux 2.6.21.7-2.fc8xen x86_64


--
Sergey

> Какая версия xcache?
> Какая OS?
FreeBSD 7.2 stable 64
PHP 5.3.1 - fpm
xcache -1.3.0

-----Original Message-----
From: Sergey Kobzar <sergey.kobzar@mail.ru>
To: highload-php-ru@googlegroups.com
Date: Thu, 24 Dec 2009 10:45:44 +0200
Subject: Re[2]: php-fpm утечки?, куда рыть

> Thursday, December 24, 2009, 8:51:15 AM, Andrey wrote:
>
> >> Какая версия xcache?
> >> Какая OS?
> > Ты-б сразу и сказал, на какой версии оно у тебя так текло и на какую
> > откатился :-)
>
> :)
>
> Текло на 1.3.0, откатился на 1.2.2 - течь перестало.
>
> Недавно накатился снова на 1.3.0 - вроде бы нормально, но пока на 100%
> сказать не могу.
>
> Разница между 1.2.2 и 1.3.0 - в основном поддержка php 5.3. Если не
> критично, то лучше оставаться на 1.2.2 IMO.

Спасибо, интересная информация,

eaccelerator не подходит, на нем не работает часть функционала PHP 5.3.1 (что связано со static)