Nginx+php-fpm 5.2 Течёт память. Доходит до cуммарного использования
700 Мб. Скажите как правильно отлавливать скрипты с утечками памяти?

ps axu | grep php-cgi | grep user

user 5528 1.8 1.0 33140 21300 ? S 23:49 0:04 /usr/
local/php5/bin/php-cgi --fpm --fpm-config /usr/local/php5/etc/php-
fpm.conf
user 12258 1.4 3.3 78660 66928 ? S 21:12 2:21 /usr/
local/php5/bin/php-cgi --fpm --fpm-config /usr/local/php5/etc/php-
fpm.conf
user 16108 1.4 5.8 48848 37040 ? S 15:10 0:53 /usr/
local/php5/bin/php-cgi --fpm --fpm-config /usr/local/php5/etc/php-
fpm.conf
user 23848 1.4 2.9 71624 59876 ? S 21:41 1:55 /usr/
local/php5/bin/php-cgi --fpm --fpm-config /usr/local/php5/etc/php-
fpm.conf
user 32542 1.3 1.2 37240 25432 ? S 23:34 0:15 /usr/
local/php5/bin/php-cgi --fpm --fpm-config /usr/local/php5/etc/php-
fpm.conf

можно использовать http://pecl.php.net/package/memtrack
но я так и не выловил утечки памяти в скриптах. После долгих имперических экспериментов оказалось, что течет xCache
выкрутились кривым, но вполне жизнеспособным образом: анализировали по крону каждые 15 мин размер php-cgi
и как только размер процесса достигал 700М делали мягкую перезагрузку fpm (получалось в среднем по 2 раза в сутки)
и еще этим же скриптом мониторили размер свопа.

10 сентября 2010 г. 2:21 пользователь Alexandre Kalendarev
<akalend@mail.ru>написал:

> можно использовать http://pecl.php.net/package/memtrack
> но я так и не выловил утечки памяти в скриптах. После долгих имперических
> экспериментов оказалось, что течет xCache
> выкрутились кривым, но вполне жизнеспособным образом: анализировали по
> крону каждые 15 мин размер php-cgi
> и как только размер процесса достигал 700М делали мягкую перезагрузку fpm
> (получалось в среднем по 2 раза в сутки)
> и еще этим же скриптом мониторили размер свопа.
>

Установил, настроил, буду мониторить. Спасибо за подсказку!

Делаю в принципе тоже самое, однако никакие акселераторы не установлены.
Память течёт как бы сама. Пришла идея уменьшить количество max_requests c
500 до 50? Однако сразу задался вопросом чем это черевато в пиковых
промежутках времени?

9 сентября 2010 г. 23:21 пользователь Alexandre Kalendarev
<akalend@mail.ru>написал:

> можно использовать http://pecl.php.net/package/memtrack
> но я так и не выловил утечки памяти в скриптах. После долгих имперических
> экспериментов оказалось, что течет xCache
> выкрутились кривым, но вполне жизнеспособным образом: анализировали по
> крону каждые 15 мин размер php-cgi
> и как только размер процесса достигал 700М делали мягкую перезагрузку fpm
> (получалось в среднем по 2 раза в сутки)
> и еще этим же скриптом мониторили размер свопа.
>

On 09/09/10 23:21, Alexandre Kalendarev wrote:
> можно использовать http://pecl.php.net/package/memtrack
> но я так и не выловил утечки памяти в скриптах. После долгих имперических экспериментов оказалось, что течет xCache
> выкрутились кривым, но вполне жизнеспособным образом: анализировали по крону каждые 15 мин размер php-cgi
> и как только размер процесса достигал 700М делали мягкую перезагрузку fpm (получалось в среднем по 2 раза в сутки)
> и еще этим же скриптом мониторили размер свопа.

У меня было подобное с XCache 1.3. Проблема решилась откатом на 1.2.
Основное нововведение в 1.3 - поддержка php 5.3.

> On 09/09/10 23:21, Alexandre Kalendarev wrote:
> > можно использовать http://pecl.php.net/package/memtrack
> > но я так и не выловил утечки памяти в скриптах. После долгих имперических экспериментов оказалось, что течет xCache
> > выкрутились кривым, но вполне жизнеспособным образом: анализировали по крону каждые 15 мин размер php-cgi
> > и как только размер процесса достигал 700М делали мягкую перезагрузку fpm (получалось в среднем по 2 раза в сутки)
> > и еще этим же скриптом мониторили размер свопа.
>
> У меня было подобное с XCache 1.3. Проблема решилась откатом на 1.2.
> Основное нововведение в 1.3 - поддержка php 5.3.

Ага, как раз только вышел 5.3 и только xCache его поддерживал. так что на то время выбора у нас не было.

> On 09/09/10 23:21, Alexandre Kalendarev wrote:
> > можно использовать http://pecl.php.net/package/memtrack
> > но я так и не выловил утечки памяти в скриптах. После долгих имперических экспериментов оказалось, что течет xCache
> > выкрутились кривым, но вполне жизнеспособным образом: анализировали по крону каждые 15 мин размер php-cgi
> > и как только размер процесса достигал 700М делали мягкую перезагрузку fpm (получалось в среднем по 2 раза в сутки)
> > и еще этим же скриптом мониторили размер свопа.

возможно что оффтоп, но вдруг поможет:

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

эксперименты с семейством memory_get_peak_usage (http://www.ibm.com/developerworks/opensource/library/os-php-v521/) ничего не дали, занимаемая память как в начале перегрузки, так и при большом разбухании процесса в среднем не изменялась.

Весь прикол в том, что под темижеми настройками, только от других
пользователей, работают ещё несколько сайтов. С ними всё отлчино.

10 сентября 2010 г. 14:00 пользователь Alexandre Kalendarev <akalend@mail.ru
> написал:

> > On 09/09/10 23:21, Alexandre Kalendarev wrote:
> > > можно использовать http://pecl.php.net/package/memtrack
> > > но я так и не выловил утечки памяти в скриптах. После долгих
> имперических экспериментов оказалось, что течет xCache
> > > выкрутились кривым, но вполне жизнеспособным образом: анализировали по
> крону каждые 15 мин размер php-cgi
> > > и как только размер процесса достигал 700М делали мягкую перезагрузку
> fpm (получалось в среднем по 2 раза в сутки)
> > > и еще этим же скриптом мониторили размер свопа.
>
> возможно что оффтоп, но вдруг поможет:
>
> еще может течь специфичный модуль, если таковы используются. Выловить это
> крайне сложно. пытался дебажить valgrind, но как товых утечек не находил.
>
> эксперименты с семейством memory_get_peak_usage (
> http://www.ibm.com/developerworks/opensource/library/os-php-v521/) ничего
> не дали, занимаемая память как в начале перегрузки, так и при большом
> разбухании процесса в среднем не изменялась.
>

может она У ТЕБЯ ТРАТИТСЯ, а не ТЕЧЁТ?!!!

10.09.10, Вячеслав Бирюков<sov1ed@gmail.com> написал(а):
> Весь прикол в том, что под темижеми настройками, только от других
> пользователей, работают ещё несколько сайтов. С ними всё отлчино.
>
> 10 сентября 2010 г. 14:00 пользователь Alexandre Kalendarev <akalend@mail.ru
>> написал:
>
>> > On 09/09/10 23:21, Alexandre Kalendarev wrote:
>> > > можно использовать http://pecl.php.net/package/memtrack
>> > > но я так и не выловил утечки памяти в скриптах. После долгих
>> имперических экспериментов оказалось, что течет xCache
>> > > выкрутились кривым, но вполне жизнеспособным образом: анализировали по
>> крону каждые 15 мин размер php-cgi
>> > > и как только размер процесса достигал 700М делали мягкую перезагрузку
>> fpm (получалось в среднем по 2 раза в сутки)
>> > > и еще этим же скриптом мониторили размер свопа.
>>
>> возможно что оффтоп, но вдруг поможет:
>>
>> еще может течь специфичный модуль, если таковы используются. Выловить это
>> крайне сложно. пытался дебажить valgrind, но как товых утечек не находил.
>>
>> эксперименты с семейством memory_get_peak_usage (
>> http://www.ibm.com/developerworks/opensource/library/os-php-v521/) ничего
>> не дали, занимаемая память как в начале перегрузки, так и при большом
>> разбухании процесса в среднем не изменялась.
>>
>

Sat, 13 Nov 2010 01:11:20 +0300 письмо от standart <mtu882@gmail.com>:

> может она У ТЕБЯ ТРАТИТСЯ, а не ТЕЧЁТ?!!!
если вопрос был ко мне, то у меня именно текла.

Тратится на что?
После перезапуска синхронно начинает выростать до безграничных пределов.

13 ноября 2010 г. 10:08 пользователь Alexandre Kalendarev
<akalend@mail.ru>написал:

>
>
> Sat, 13 Nov 2010 01:11:20 +0300 письмо от standart <mtu882@gmail.com>:
>
> > может она У ТЕБЯ ТРАТИТСЯ, а не ТЕЧЁТ?!!!
> если вопрос был ко мне, то у меня именно текла.
>



--
Viacheslav Sov1et Biriukov
http://openstar.com.ua

Sat, 13 Nov 2010 12:19:26 +0200 письмо от Viacheslav Biriukov <v.v.biriukov@gmail.com>:

> Тратится на что?
> После перезапуска синхронно начинает выростать до безграничных пределов.
>
именно, притом все РНР-шные средства по вычислению размеров занимаемой памяти показывали приблизительно одинаковую цифру
вне зависимости от того, когда был запущен скрипт - в начале цикла перезапуска или ближе к границы падения.