Прошу прощения за повторение поста из nginx-ru, но в том листе я не
получил ответа.

Есть проблема:

На сервере раз в неделю запускается тяжелый скрипт. В это время
увеличивается число php-fpm процессов и при достижении max_children
лимита php-fpm помирает.

Linux 3.2.1-gentoo-r2 x86_64
php-5.3.9

/etc/php/fpm-php5.3/php-fpm.conf:
[site]
listen = 127.0.0.1:9002

user = site
group = site

pm = dynamic
pm.max_children = 256
pm.start_servers = 16
pm.min_spare_servers = 16
pm.max_spare_servers = 24

pm.status_path = /phpfpm_status
ping.path = /phpfpm_ping
request_slowlog_timeout = 10
slowlog = /var/log/php/php-fpm-$pool_slow.log

php_admin_flag[log_errors] = on
php_admin_value[date.timezone] = Europe/London
php_admin_value[error_log] = /var/log/php/php-fpm-$pool_error.log
php_admin_value[memory_limit] = 256M
php_flag[short_open_tag] = on


В логах это выглядит так:
[25-Mar-2012 02:14:29] WARNING: [pool site] seems busy (you may need to
increase pm.start_servers, or pm.min/max_spare_servers), spawning 16
children, there are 6 idle, and 241 total children
[25-Mar-2012 02:14:34] NOTICE: child 6399 stopped for tracing
[25-Mar-2012 02:14:34] NOTICE: about to trace 6399
[25-Mar-2012 02:14:34] ERROR: failed to ptrace(PEEKDATA) pid 6399:
Input/output error (5)
[25-Mar-2012 02:14:34] NOTICE: finished trace of 6399
[25-Mar-2012 02:14:34] NOTICE: child 6444 stopped for tracing
[25-Mar-2012 02:14:34] NOTICE: about to trace 6444
[25-Mar-2012 02:14:34] ERROR: failed to ptrace(PEEKDATA) pid 6444:
Input/output error (5)
[25-Mar-2012 02:14:34] NOTICE: finished trace of 6444
[25-Mar-2012 02:14:34] NOTICE: child 6445 stopped for tracing
[25-Mar-2012 02:14:34] NOTICE: about to trace 6445
[25-Mar-2012 02:14:34] NOTICE: finished trace of 6445
[25-Mar-2012 02:14:34] NOTICE: child 6451 stopped for tracing
[25-Mar-2012 02:14:34] NOTICE: about to trace 6451
[25-Mar-2012 02:14:34] ERROR: failed to ptrace(PEEKDATA) pid 6451:
Input/output error (5)
....
[25-Mar-2012 02:16:34] NOTICE: child 6358 stopped for tracing
[25-Mar-2012 02:16:34] NOTICE: about to trace 6358
[25-Mar-2012 02:16:35] NOTICE: finished trace of 6358
[25-Mar-2012 02:16:35] NOTICE: child 6383 stopped for tracing
[25-Mar-2012 02:16:35] NOTICE: about to trace 6383
[25-Mar-2012 02:16:35] NOTICE: finished trace of 6383
[25-Mar-2012 02:16:35] NOTICE: child 6456 stopped for tracing
[25-Mar-2012 02:16:35] NOTICE: about to trace 6456
[25-Mar-2012 02:16:35] NOTICE: finished trace of 6456
[25-Mar-2012 02:16:35] NOTICE: Finishing ...
[25-Mar-2012 02:16:37] NOTICE: exiting, bye-bye!

Ситуация стабильно воспроизводится на нескольких серверах - php-fpm
помирает при достижении лимита.

Как решение, можно увеличить max_children, но IMO это не совсем правильно.

Я ожидал след. поведения:
если число процессов равно max_children, то перестают создаваться новые
чаилды, но php-fpm прдолжает обслуживать существующие соединения, но не
помирать совсем же!

Any ideas?

Спасибо.

On 03/27/2012 12:27 AM, Sergey Kobzar wrote:
> [25-Mar-2012 02:16:37] NOTICE: exiting, bye-bye!

Его убивает кто-то, очевидно.

> Ситуация стабильно воспроизводится на нескольких серверах - php-fpm
> помирает при достижении лимита.
>
> Как решение, можно увеличить max_children, но IMO это не совсем правильно.

Попробуйте с pm = static и выставить фиксированное кол-во чайлдов.
Хотя, я не понимаю как это вам поможет, если процесс явно кто-то убивает извне.

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

On 03/26/12 23:44, Antony Dovgal wrote:
> On 03/27/2012 12:27 AM, Sergey Kobzar wrote:
>> [25-Mar-2012 02:16:37] NOTICE: exiting, bye-bye!
>
> Его убивает кто-то, очевидно.
>
>> Ситуация стабильно воспроизводится на нескольких серверах - php-fpm
>> помирает при достижении лимита.
>>
>> Как решение, можно увеличить max_children, но IMO это не совсем
>> правильно.
>
> Попробуйте с pm = static и выставить фиксированное кол-во чайлдов.
> Хотя, я не понимаю как это вам поможет, если процесс явно кто-то убивает
> извне.

Спасибо. Буду смотреть, кто это может быть.

Простите, может я не в тему, но почему вы тяжёлые скрипты запускаете под
php-fpm?
Производственная необходимость?

27 марта 2012 г. 0:27 пользователь Sergey Kobzar <sergey.kobzar@mail.ru>написал:

> Прошу прощения за повторение поста из nginx-ru, но в том листе я не
> получил ответа.
>
> Есть проблема:
>
> На сервере раз в неделю запускается тяжелый скрипт. В это время
> увеличивается число php-fpm процессов и при достижении max_children лимита
> php-fpm помирает.
>
>

--
С уважением, Максим Камашев
<max.kamashev@gmail.com>

On 03/27/12 00:06, Max Kamashev wrote:
> Простите, может я не в тему, но почему вы тяжёлые скрипты запускаете под
> php-fpm?
> Производственная необходимость?
>
> 27 марта 2012 г. 0:27 пользователь Sergey Kobzar <sergey.kobzar@mail.ru
> <mailto:sergey.kobzar@mail.ru>> написал:
>
> Прошу прощения за повторение поста из nginx-ru, но в том листе я не
> получил ответа.
>
> Есть проблема:
>
> На сервере раз в неделю запускается тяжелый скрипт. В это время
> увеличивается число php-fpm процессов и при достижении max_children
> лимита php-fpm помирает.
>
>
>
> --
> С уважением, Максим Камашев
> <max.kamashev@gmail.com <mailto:max.kamashev@gmail.com>>

Скрипт о котором вы говорите написан на шеле. Но из-за того, что он
генерит большую disk IO, вырастает очередь из php-fpm процессов. Как-то
так...

Может тогда попробовать проставить nice (ionice)?

27 марта 2012 г. 2:25 пользователь Sergey Kobzar <sergey.kobzar@mail.ru>написал:

>
> Скрипт о котором вы говорите написан на шеле. Но из-за того, что он
> генерит большую disk IO, вырастает очередь из php-fpm процессов. Как-то
> так...
>



--
С уважением, Максим Камашев
<max.kamashev@gmail.com>

27.03.2012 0:06, Max Kamashev написал:
> Простите, может я не в тему, но почему вы тяжёлые скрипты запускаете под
> php-fpm?
> Производственная необходимость?

Не хотелось бы поднимать холивар и троллинг.

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


--
Vladislav V. Prodan
System & Network Administrator
http://support.od.ua
+380 67 4584408, +380 99 4060508
VVP88-RIPE

Я не считаю себя гуру что бы давать рекомендации, но некоторые непреложные
истины могу подытожить:

- Запускать скрипты с пониженным приоритетом nice
- Контролировать память, если совсем долго работают (например демоны), то
лучше бы запускать сборщик мусора, unset переменных
- Не позволять запускать несколько скриптов сразу (например по крону) (по
pid-файлам)
- Ставить в циклах sleep, time_nanosleep, ticks, т.е. не давать возможности
скриптам сожрать процессор
- Ну и мониторить потребляемые ресурсы (обычный top), что именно может
съедать скрипт, пытаться оптимизировать код, если это возможно

27 марта 2012 г. 2:05 пользователь Vladislav V. Prodan
<universite@ukr.net>написал:

> 27.03.2012 0:06, Max Kamashev написал:
> > Простите, может я не в тему, но почему вы тяжёлые скрипты запускаете под
> > php-fpm?
> > Производственная необходимость?
>
> Не хотелось бы поднимать холивар и троллинг.
>
> Но уточните, какие бы вы дали рекомендации по запуску тяжелых php скриптов?
> Меня не раз просили контролировать запуск подобных скриптов и я не
> придумал ничего лучшего, как выставлять лимиты для определенного
> пользователя в php-fpm и запускать скрипты из-под него.
>
>
> --
> Vladislav V. Prodan
> System & Network Administrator
> http://support.od.ua
> +380 67 4584408, +380 99 4060508
> VVP88-RIPE
>



--
С уважением, Максим Камашев
<max.kamashev@gmail.com>

nice работает только на CPU, чтобы скрипт не мочкарил сервер по IO
нужно использовать ionice, самое эффективное: ionice -c3 (если конечно
не преследуется цель максимально быстро отработать).

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

2012/3/27 Max Kamashev <max.kamashev@gmail.com>:
> Я не считаю себя гуру что бы давать рекомендации, но некоторые непреложные
> истины могу подытожить:
>
> - Запускать скрипты с пониженным приоритетом nice
> - Контролировать память, если совсем долго работают (например демоны), то
> лучше бы запускать сборщик мусора, unset переменных
> - Не позволять запускать несколько скриптов сразу (например по крону) (по
> pid-файлам)
> - Ставить в циклах sleep, time_nanosleep, ticks, т.е. не давать возможности
> скриптам сожрать процессор
> - Ну и мониторить потребляемые ресурсы (обычный top), что именно может
> съедать скрипт, пытаться оптимизировать код, если это возможно
>
> 27 марта 2012 г. 2:05 пользователь Vladislav V. Prodan <universite@ukr.net>
> написал:
>
>> 27.03.2012 0:06, Max Kamashev написал:
>> > Простите, может я не в тему, но почему вы тяжёлые скрипты запускаете под
>> > php-fpm?
>> > Производственная необходимость?
>>
>> Не хотелось бы поднимать холивар и троллинг.
>>
>> Но уточните, какие бы вы дали рекомендации по запуску тяжелых php
>> скриптов?
>> Меня не раз просили контролировать запуск подобных скриптов и я не
>> придумал ничего лучшего, как выставлять лимиты для определенного
>> пользователя в php-fpm и запускать скрипты из-под него.
>>
>>
>> --
>> Vladislav V. Prodan
>> System & Network Administrator
>> http://support.od.ua
>> +380 67 4584408, +380 99 4060508
>> VVP88-RIPE
>
>
>
>
> --
> С уважением, Максим Камашев
> <max.kamashev@gmail.com>

On 03/27/12 07:12, Max Kamashev wrote:
> Может тогда попробовать проставить nice (ionice)?

Возможно, но сперва надо понять кто отстреливает php...

>
> 27 марта 2012 г. 2:25 пользователь Sergey Kobzar <sergey.kobzar@mail.ru
> <mailto:sergey.kobzar@mail.ru>> написал:
>
>
> Скрипт о котором вы говорите написан на шеле. Но из-за того, что он
> генерит большую disk IO, вырастает очередь из php-fpm процессов.
> Как-то так...
>
>
>
>
> --
> С уважением, Максим Камашев
> <max.kamashev@gmail.com <mailto:max.kamashev@gmail.com>>

On 03/27/12 12:29, Sergey Kobzar wrote:
> On 03/27/12 07:12, Max Kamashev wrote:
>> Может тогда попробовать проставить nice (ionice)?
>
> Возможно, но сперва надо понять кто отстреливает php...

Нашел причину. Дествительно php-fpm прибивался внешним процессом. 1.5
недели - полет нормальный, за исключением backup time - mysqldump
генерит большую дисковую активность и периодически вылазить 504 ошибка у
Nginx.

mysqldump запускю так:
ionice -c 3 mysqldump ...

Можно конечно снэпшоты прикрутить, делать снэпшот партиции с mysql и
потом rsync'ом копировать данные на другой сервер ограничив bandwidth,
но ждя этого надо переразбить винт + добавить поддержку снэпшотов.

Есть еще идеи, как поумерить его пыл? Делать бэкап посредством
myster-slave replication не предлагать.

P.S. Linux 3.2.1-gentoo-r2 x86_64

On 04/05/12 12:20, Sergey Kobzar wrote:
> On 03/27/12 12:29, Sergey Kobzar wrote:
>> On 03/27/12 07:12, Max Kamashev wrote:
>>> Может тогда попробовать проставить nice (ionice)?
>>
>> Возможно, но сперва надо понять кто отстреливает php...
>
> Нашел причину. Дествительно php-fpm прибивался внешним процессом. 1.5
> недели - полет нормальный, за исключением backup time - mysqldump
> генерит большую дисковую активность и периодически вылазить 504 ошибка у
> Nginx.
>
> mysqldump запускю так:
> ionice -c 3 mysqldump ...
>
> Можно конечно снэпшоты прикрутить, делать снэпшот партиции с mysql и
> потом rsync'ом копировать данные на другой сервер ограничив bandwidth,
> но ждя этого надо переразбить винт + добавить поддержку снэпшотов.
>
> Есть еще идеи, как поумерить его пыл? Делать бэкап посредством
> myster-slave replication не предлагать.
>
> P.S. Linux 3.2.1-gentoo-r2 x86_64

On 04/05/12 12:21, Sergey Kobzar wrote:
> On 04/05/12 12:20, Sergey Kobzar wrote:
>> On 03/27/12 12:29, Sergey Kobzar wrote:
>>> On 03/27/12 07:12, Max Kamashev wrote:
>>>> Может тогда попробовать проставить nice (ionice)?
>>>
>>> Возможно, но сперва надо понять кто отстреливает php...
>>
>> Нашел причину. Дествительно php-fpm прибивался внешним процессом. 1.5
>> недели - полет нормальный, за исключением backup time - mysqldump
>> генерит большую дисковую активность и периодически вылазить 504 ошибка у
>> Nginx.
>>
>> mysqldump запускю так:
>> ionice -c 3 mysqldump ...
>>
>> Можно конечно снэпшоты прикрутить, делать снэпшот партиции с mysql и
>> потом rsync'ом копировать данные на другой сервер ограничив bandwidth,
>> но ждя этого надо переразбить винт + добавить поддержку снэпшотов.
>>
>> Есть еще идеи, как поумерить его пыл? Делать бэкап посредством
>> myster-slave replication не предлагать.
>>
>> P.S. Linux 3.2.1-gentoo-r2 x86_64

Забыл добавить - объем базы ~40G и на постоянно растет где-то на 2G/месяц.

http://www.percona.com/doc/percona-xtrabackup/ +
http://www.percona.com/doc/percona-xtrabackup/innobackupex/innobackupex_script.html
намного шустрее mysqldump

5 апреля 2012 г. 13:22 пользователь Sergey Kobzar
<sergey.kobzar@mail.ru>написал:

> On 04/05/12 12:21, Sergey Kobzar wrote:
>
>> On 04/05/12 12:20, Sergey Kobzar wrote:
>>
>>> On 03/27/12 12:29, Sergey Kobzar wrote:
>>>
>>>> On 03/27/12 07:12, Max Kamashev wrote:
>>>>
>>>>> Может тогда попробовать проставить nice (ionice)?
>>>>>
>>>>
>>>> Возможно, но сперва надо понять кто отстреливает php...
>>>>
>>>
>>> Нашел причину. Дествительно php-fpm прибивался внешним процессом. 1.5
>>> недели - полет нормальный, за исключением backup time - mysqldump
>>> генерит большую дисковую активность и периодически вылазить 504 ошибка у
>>> Nginx.
>>>
>>> mysqldump запускю так:
>>> ionice -c 3 mysqldump ...
>>>
>>> Можно конечно снэпшоты прикрутить, делать снэпшот партиции с mysql и
>>> потом rsync'ом копировать данные на другой сервер ограничив bandwidth,
>>> но ждя этого надо переразбить винт + добавить поддержку снэпшотов.
>>>
>>> Есть еще идеи, как поумерить его пыл? Делать бэкап посредством
>>> myster-slave replication не предлагать.
>>>
>>> P.S. Linux 3.2.1-gentoo-r2 x86_64
>>>
>>
> Забыл добавить - объем базы ~40G и на постоянно растет где-то на 2G/месяц.
>



--
С уважением,
Антипов Илья

On 04/05/12 12:23, Илья Антипов wrote:
> http://www.percona.com/doc/percona-xtrabackup/ +
> http://www.percona.com/doc/percona-xtrabackup/innobackupex/innobackupex_script.html
> намного шустрее mysqldump

Хм... Интересный вариант. Никогда не использовал. Можно сделать full
backup, а потом инкрементальные бэкапы раз в неделю. Уменьшиться обем
данных заливаемых на вит и передаваемых по сети.

ТОлько я так понимаю expire_logs_days в my.cnf должен быть не менне, чем
интервал запуска innobackupex?

Спасибо.

Поддержу Илью!
xtrabackup очень быстро работает на бэкап и восстановление!
Также порекомендую использовать архиватор pigz для хранения бэкапов, он
намного быстрее работает, чем стандартный tar или gzip

Удачи!

5 апреля 2012 г. 2:34 пользователь Sergey Kobzar <sergey.kobzar@mail.ru>написал:

> On 04/05/12 12:23, Илья Антипов wrote:
>
>> http://www.percona.com/doc/**percona-xtrabackup/http://www.percona.com/doc/percona-xtrabackup/ +
>> http://www.percona.com/doc/**percona-xtrabackup/**
>> innobackupex/innobackupex_**script.htmlhttp://www.percona.com/doc/percona-xtrabackup/innobackupex/innobackupex_script.html
>> намного шустрее mysqldump
>>
>
> Хм... Интересный вариант. Никогда не использовал. Можно сделать full
> backup, а потом инкрементальные бэкапы раз в неделю. Уменьшиться обем
> данных заливаемых на вит и передаваемых по сети.
>
> ТОлько я так понимаю expire_logs_days в my.cnf должен быть не менне, чем
> интервал запуска innobackupex?
>
> Спасибо.
>

Спасибо. Попробую.

On 04/05/12 22:30, Maxim Fedchishin wrote:
> Поддержу Илью!
> xtrabackup очень быстро работает на бэкап и восстановление!
> Также порекомендую использовать архиватор pigz для хранения бэкапов, он
> намного быстрее работает, чем стандартный tar или gzip
>
> Удачи!
>
> 5 апреля 2012 г. 2:34 пользователь Sergey Kobzar <sergey.kobzar@mail.ru
> <mailto:sergey.kobzar@mail.ru>> написал:
>
> On 04/05/12 12:23, Илья Антипов wrote:
>
> http://www.percona.com/doc/__percona-xtrabackup/
> http://www.percona.com/doc/percona-xtrabackup/ +
> http://www.percona.com/doc/__percona-xtrabackup/__innobackupex/innobackupex___script.html
> http://www.percona.com/doc/percona-xtrabackup/innobackupex/innobackupex_script.html
> намного шустрее mysqldump
>
>
> Хм... Интересный вариант. Никогда не использовал. Можно сделать full
> backup, а потом инкрементальные бэкапы раз в неделю. Уменьшиться
> обем данных заливаемых на вит и передаваемых по сети.
>
> ТОлько я так понимаю expire_logs_days в my.cnf должен быть не менне,
> чем интервал запуска innobackupex?
>
> Спасибо.

On 5 April 2012 13:34, Sergey Kobzar <sergey.kobzar@mail.ru> wrote:
> On 04/05/12 12:23, Илья Антипов wrote:
>>
>> http://www.percona.com/doc/percona-xtrabackup/  +
>>
>> http://www.percona.com/doc/percona-xtrabackup/innobackupex/innobackupex_script.html
>> намного шустрее mysqldump
>
>
> ТОлько я так понимаю expire_logs_days в my.cnf должен быть не менне, чем
> интервал запуска innobackupex?

Да нет, они никак не связаны. Бинлоги вообще могут быть выключены.

--
With best regards,
Dmitri Minaev

On 04/06/12 08:29, Dmitri Minaev wrote:
> On 5 April 2012 13:34, Sergey Kobzar<sergey.kobzar@mail.ru> wrote:
>> On 04/05/12 12:23, Илья Антипов wrote:
>>>
>>> http://www.percona.com/doc/percona-xtrabackup/ +
>>>
>>> http://www.percona.com/doc/percona-xtrabackup/innobackupex/innobackupex_script.html
>>> намного шустрее mysqldump
>>
>>
>> ТОлько я так понимаю expire_logs_days в my.cnf должен быть не менне, чем
>> интервал запуска innobackupex?
>
> Да нет, они никак не связаны. Бинлоги вообще могут быть выключены.

Спасибо.