I've just built PHP 5.2.10 with the fpm patch on FreeBSD 6.2 and
started FPM using the init.d script with the default configuration
(only changed the process owner to www). I've not even configured
nginx to use the fastcgi processes yet and I have a single php-cgi
using 55% of the CPU and causing a 5 minute load average of over 2.
It's also using an excessive 170M of memory!!

Anyone seen this before or know what might cause it?

-Stuart

--
http://stut.net/

When you start up the daemon is it okay? Or is it when it starts
getting requests?

Sent from my iPhone

On Jul 6, 2009, at 6:35 AM, Stuart Dallas <stuttle@gmail.com> wrote:

>
> I've just built PHP 5.2.10 with the fpm patch on FreeBSD 6.2 and
> started FPM using the init.d script with the default configuration
> (only changed the process owner to www). I've not even configured
> nginx to use the fastcgi processes yet and I have a single php-cgi
> using 55% of the CPU and causing a 5 minute load average of over 2.
> It's also using an excessive 170M of memory!!
>
> Anyone seen this before or know what might cause it?
>
> -Stuart
>
> --
> http://stut.net/

2009/7/6 Michael Shadle <mike503@gmail.com>:
>
> When you start up the daemon is it okay? Or is it when it starts getting
> requests?

Like I said, I've not set anything up to use them yet so it's not
related to requests or any other external influence.

-Stuart

> On Jul 6, 2009, at 6:35 AM, Stuart Dallas <stuttle@gmail.com> wrote:
>
>>
>> I've just built PHP 5.2.10 with the fpm patch on FreeBSD 6.2 and
>> started FPM using the init.d script with the default configuration
>> (only changed the process owner to www). I've not even configured
>> nginx to use the fastcgi processes yet and I have a single php-cgi
>> using 55% of the CPU and causing a 5 minute load average of over 2.
>> It's also using an excessive 170M of memory!!
>>
>> Anyone seen this before or know what might cause it?
>>
>> -Stuart
>>
>> --
>> http://stut.net/
>

Okay. hmm. I don't have any machines right now setup for this.

Is it 64 bit or 32 bit?

And that is 170 megs of *physical* ram? How many children do you have
setup? How many pools? Maybe pastebin your config?


On Mon, Jul 6, 2009 at 12:28 PM, Stuart<stuttle@gmail.com> wrote:
>
> 2009/7/6 Michael Shadle <mike503@gmail.com>:
>>
>> When you start up the daemon is it okay? Or is it when it starts getting
>> requests?
>
> Like I said, I've not set anything up to use them yet so it's not
> related to requests or any other external influence.
>
> -Stuart
>
>> On Jul 6, 2009, at 6:35 AM, Stuart Dallas <stuttle@gmail.com> wrote:
>>
>>>
>>> I've just built PHP 5.2.10 with the fpm patch on FreeBSD 6.2 and
>>> started FPM using the init.d script with the default configuration
>>> (only changed the process owner to www). I've not even configured
>>> nginx to use the fastcgi processes yet and I have a single php-cgi
>>> using 55% of the CPU and causing a 5 minute load average of over 2.
>>> It's also using an excessive 170M of memory!!
>>>
>>> Anyone seen this before or know what might cause it?
>>>
>>> -Stuart
>>>
>>> --
>>> http://stut.net/
>>
>

On 06.07.2009 23:28, Stuart wrote:
> 2009/7/6 Michael Shadle <mike503@gmail.com>:
>>
>> When you start up the daemon is it okay? Or is it when it starts getting
>> requests?
>
> Like I said, I've not set anything up to use them yet so it's not
> related to requests or any other external influence.

Figure out PID of that process and do the following:
# gdb attach <pid>
gdb> bt

And paste the output you get here.

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

2009/7/6 Michael Shadle <mike503@gmail.com>:
>
> Okay. hmm. I don't have any machines right now setup for this.
>
> Is it 64 bit or 32 bit?

64-bit.

> And that is 170 megs of *physical* ram? How many children do you have
> setup? How many pools? Maybe pastebin your config?

The 170 meg is the RES column in top. SIZE is 210 meg.

Config file is unchanged from the build from source apart from setting
the process owner and group to www.

-Stuart

> On Mon, Jul 6, 2009 at 12:28 PM, Stuart<stuttle@gmail.com> wrote:
>>
>> 2009/7/6 Michael Shadle <mike503@gmail.com>:
>>>
>>> When you start up the daemon is it okay? Or is it when it starts getting
>>> requests?
>>
>> Like I said, I've not set anything up to use them yet so it's not
>> related to requests or any other external influence.
>>
>> -Stuart
>>
>>> On Jul 6, 2009, at 6:35 AM, Stuart Dallas <stuttle@gmail.com> wrote:
>>>
>>>>
>>>> I've just built PHP 5.2.10 with the fpm patch on FreeBSD 6.2 and
>>>> started FPM using the init.d script with the default configuration
>>>> (only changed the process owner to www). I've not even configured
>>>> nginx to use the fastcgi processes yet and I have a single php-cgi
>>>> using 55% of the CPU and causing a 5 minute load average of over 2.
>>>> It's also using an excessive 170M of memory!!
>>>>
>>>> Anyone seen this before or know what might cause it?
>>>>
>>>> -Stuart
>>>>
>>>> --
>>>> http://stut.net/
>>>
>>
>

2009/7/6 Antony Dovgal <tony@daylessday.org>:
>
> On 06.07.2009 23:28, Stuart wrote:
>> 2009/7/6 Michael Shadle <mike503@gmail.com>:
>>>
>>> When you start up the daemon is it okay? Or is it when it starts getting
>>> requests?
>>
>> Like I said, I've not set anything up to use them yet so it's not
>> related to requests or any other external influence.
>
> Figure out PID of that process and do the following:
> # gdb attach <pid>
> gdb> bt
>
> And paste the output you get here.

(gdb) bt
#0 0x000000080284e3ec in fork () from /lib/libc.so.6
#1 0x00000000006fbd16 in fpm_children_make (wp=0xd00500, in_event_loop=1)
at /root/build/php-5.2.10/sapi/cgi/fpm/fpm_children.c:326
#2 0x00000000006fc123 in fpm_children_bury ()
at /root/build/php-5.2.10/sapi/cgi/fpm/fpm_children.c:249
#3 0x00000000006fe2fc in fpm_got_signal (fd=4, ev=0, arg=0x0)
at /root/build/php-5.2.10/sapi/cgi/fpm/fpm_events.c:49
#4 0x0000000000701cd9 in _fpm_event_base_loop (base=0xd04800, flags=0)
at event.c:351
#5 0x00000000006fe450 in fpm_event_loop ()
at /root/build/php-5.2.10/sapi/cgi/fpm/fpm_events.c:109
#6 0x00000000006faf2d in fpm_run (max_requests=0x7fffffffc89c)
at /root/build/php-5.2.10/sapi/cgi/fpm/fpm.c:75
#7 0x00000000006f9253 in main (argc=4, argv=0x7fffffffec68)
at /root/build/php-5.2.10/sapi/cgi/cgi_main.c:1623

-Stuart

--
http://stut.net/

2009/7/6 Stuart <stuttle@gmail.com>:
> 2009/7/6 Antony Dovgal <tony@daylessday.org>:
>>
>> On 06.07.2009 23:28, Stuart wrote:
>>> 2009/7/6 Michael Shadle <mike503@gmail.com>:
>>>>
>>>> When you start up the daemon is it okay? Or is it when it starts getting
>>>> requests?
>>>
>>> Like I said, I've not set anything up to use them yet so it's not
>>> related to requests or any other external influence.
>>
>> Figure out PID of that process and do the following:
>> # gdb attach <pid>
>> gdb> bt
>>
>> And paste the output you get here.
>
> (gdb) bt
> #0  0x000000080284e3ec in fork () from /lib/libc.so.6
> #1  0x00000000006fbd16 in fpm_children_make (wp=0xd00500, in_event_loop=1)
>    at /root/build/php-5.2.10/sapi/cgi/fpm/fpm_children.c:326
> #2  0x00000000006fc123 in fpm_children_bury ()
>    at /root/build/php-5.2.10/sapi/cgi/fpm/fpm_children.c:249
> #3  0x00000000006fe2fc in fpm_got_signal (fd=4, ev=0, arg=0x0)
>    at /root/build/php-5.2.10/sapi/cgi/fpm/fpm_events.c:49
> #4  0x0000000000701cd9 in _fpm_event_base_loop (base=0xd04800, flags=0)
>    at event.c:351
> #5  0x00000000006fe450 in fpm_event_loop ()
>    at /root/build/php-5.2.10/sapi/cgi/fpm/fpm_events.c:109
> #6  0x00000000006faf2d in fpm_run (max_requests=0x7fffffffc89c)
>    at /root/build/php-5.2.10/sapi/cgi/fpm/fpm.c:75
> #7  0x00000000006f9253 in main (argc=4, argv=0x7fffffffec68)
>    at /root/build/php-5.2.10/sapi/cgi/cgi_main.c:1623

FWIW I've just built it on a CentOS5 box and it's exhibiting similar
behavior but with less CPU (~7.6%). Backtrace is also essentially the
same...

(gdb) bt
#0 0x0000003103099845 in fork () from /lib64/libc.so.6
#1 0x0000000000614210 in fpm_children_make (wp=0x920cdd0,
in_event_loop=1) at
/root/build/php-5.2.10/sapi/cgi/fpm/fpm_children.c:326
#2 0x0000000000614667 in fpm_children_bury () at
/root/build/php-5.2.10/sapi/cgi/fpm/fpm_children.c:249
#3 0x0000000000616cc7 in fpm_got_signal (fd=4, ev=<value optimized
out>, arg=<value optimized out>)
at /root/build/php-5.2.10/sapi/cgi/fpm/fpm_events.c:49
#4 0x000000000061aae8 in _fpm_event_base_loop (base=0x9203af0,
flags=0) at event.c:351
#5 0x0000000000616b7a in fpm_event_loop () at
/root/build/php-5.2.10/sapi/cgi/fpm/fpm_events.c:109
#6 0x0000000000613251 in fpm_run (max_requests=0x7fff1da5157c) at
/root/build/php-5.2.10/sapi/cgi/fpm/fpm.c:75
#7 0x000000000061216c in main (argc=4, argv=0x7fff1da51698) at
/root/build/php-5.2.10/sapi/cgi/cgi_main.c:1623

If I can't get this sorted in the next 24 hours I'm gonna have to use
spawn-fcgi instead which would be a major disappointment so any help
would be appreciated.

-Stuart

gdb bt output from my build:

#0 0x00002b01d37f5323 in __epoll_wait_nocancel () from /lib64/libc.so.6
#1 0x00000000007b870d in epoll_dispatch ()
#2 0x00000000007b713b in _fpm_event_base_loop ()
#3 0x00000000007b376d in fpm_event_loop ()
#4 0x00000000007b0126 in fpm_run ()
#5 0x00000000007af49d in main ()

CentOS 5.3 x64
PHP 5.2.10 + FPM 0.5.13
Started with stock php-fpm.conf, duplicated the pool section, changed
the first to 1 child, and changed the second to a new port and my
user/group. Possibly epoll related? I don't see epoll in your output.

gdb bt output from my build:

#0  0x00002b01d37f5323 in __epoll_wait_nocancel () from /lib64/libc.so.6
#1  0x00000000007b870d in epoll_dispatch ()
#2  0x00000000007b713b in _fpm_event_base_loop ()
#3  0x00000000007b376d in fpm_event_loop ()
#4  0x00000000007b0126 in fpm_run ()
#5  0x00000000007af49d in main ()

CentOS 5.3 x64
PHP 5.2.10 + FPM 0.5.13

0% CPU usage when idle.

Started with stock php-fpm.conf, duplicated the pool section, changed
the first to 1 child, and changed the second to a new port and my
user/group. Possibly epoll related? I don't see epoll in your output.

2009/7/8 Gordon Pettey <petteyg359@gmail.com>:
>
> gdb bt output from my build:
>
> #0  0x00002b01d37f5323 in __epoll_wait_nocancel () from /lib64/libc.so.6
> #1  0x00000000007b870d in epoll_dispatch ()
> #2  0x00000000007b713b in _fpm_event_base_loop ()
> #3  0x00000000007b376d in fpm_event_loop ()
> #4  0x00000000007b0126 in fpm_run ()
> #5  0x00000000007af49d in main ()
>
> CentOS 5.3 x64
> PHP 5.2.10 + FPM 0.5.13
>
> 0% CPU usage when idle.
>
> Started with stock php-fpm.conf, duplicated the pool section, changed
> the first to 1 child, and changed the second to a new port and my
> user/group. Possibly epoll related? I don't see epoll in your output.

That's what I would expect. It looks like it's continuously creating
children but they die almost instantly. Is it possible it's one of the
extensions I've built into PHP? Here's my configure line...

'./configure' '--enable-fastcgi' '--enable-fpm' '--disable-debug'
'--with-pic' '--disable-rpath' '--without-pear' '--with-curl'
'--with-exec-dir=/usr/bin' '--with-freetype-dir=/usr'
'--enable-gd-native-ttf' '--without-gdbm' '--with-gettext'
'--with-iconv' '--with-jpeg-dir=/usr' '--with-openssl' '--with-pspell'
'--with-pcre-regex=/usr' '--with-zlib' '--with-layout=GNU'
'--enable-exif' '--disable-magic-quotes' '--enable-sockets'
'--enable-shmop' '--with-mime-magic=/usr/share/file/magic.mime'
'--without-sqlite' '--with-libxml-dir=/usr' '--enable-pcntl'
'--enable-mbstring=shared' '--with-gd=shared' '--with-xmlrpc=shared'
'--with-mysql=shared,/usr' '--enable-dom=shared'
'--enable-soap=shared' '--with-xsl=shared,/usr'
'--enable-xmlreader=shared' '--enable-xmlwriter=shared'
'--with-mcrypt=shared' '--disable-pdo' '--with-readline'
'--includedir=/usr/include' '--libdir=/usr/lib64'
'--libexecdir=/usr/libexec' '--with-libdir=lib64'

Thanks.

-Stuart

I've had this issue before. I can't seem to remember.

It may have to do with what perms your PHP-FPM children are running
as.

Best thing to do is start turning off/on these ./configure statements
and start/stop php-fpm.

Double check all your paths as well.

Also, when you phpize/make make sure to read your logs.

On Jul 8, 12:17

--enable-force-cgi-redirect --enable-fpm
--with-fpm-conf=/etc/php-fpm.conf --with-fpm-log=/var/log/php-fpm.log
--with-fpm-pid=/var/run/php-fpm.pid --enable-sigchild --with-openssl
--with-zlib --enable-bcmath --with-bz2 --enable-calendar
--with-curlwrappers --enable-exif --enable-ftp --with-gd
--with-png-dir --with-zlib-dir --with-xpm-dir --with-ttf
--with-freetype-dir --with-t1lib --enable-gd-native-ttf --with-gettext
--enable-mbstring --with-mcrypt --with-mhash --with-mysql
--with-mysqli --with-ncurses --enable-pcntl --with-pspell
--with-libedit --enable-soap --enable-sockets --enable-sysvmsg
--enable-sysvsem --enable-sysvshm --with-tidy --enable-wddx
--with-xmlrpc --with-iconv-dir --with-xsl --enable-zip --with-pic
--with-pcre-dir --with-layout=GNU --prefix=/usr

Not sure how much it'll help, but you might as well clean up your
./configure options to start with.

Redundant options you should remove:

--disable-debug (already disabled by default)

--libdir=/usr/lib64
--libexecdir=/usr/libexec
--includedir=/usr/include
--with-exec-dir

Just add --prefix=/usr instead of those three. Once you've done that,
you can change:

--with-jpeg-dir=/usr to --with-jpeg-dir
--with-libxml-dir=/usr to --with-libxml-dir


>> That's what I would expect. It looks like it's continuously creating
>> children but they die almost instantly. Is it possible it's one of the
>> extensions I've built into PHP? Here's my configure line...
>>
>> './configure' '--enable-fpm' '--disable-debug'
>> '--with-pic' '--disable-rpath'
>> '--with-exec-dir=/usr/bin' '--with-freetype-dir=/usr'
>> '--enable-gd-native-ttf' '--without-gdbm' '--with-gettext'
>> '--with-iconv' '--with-jpeg-dir=/usr' '--with-openssl' '--with-pspell'
>> '--with-pcre-regex=/usr' '--with-zlib' '--with-layout=GNU'
>> '--enable-exif' '--disable-magic-quotes' '--enable-sockets'
>> '--enable-shmop' '--with-mime-magic=/usr/share/file/magic.mime'
>> '--without-sqlite' '--with-libxml-dir=/usr' '--enable-pcntl'
>> '--enable-mbstring=shared' '--with-gd=shared' '--with-xmlrpc=shared'
>> '--with-mysql=shared,/usr' '--enable-dom=shared'
>> '--enable-soap=shared' '--with-xsl=shared,/usr'
>> '--enable-xmlreader=shared' '--enable-xmlwriter=shared'
>> '--with-mcrypt=shared' '--disable-pdo' '--with-readline'
>> '--includedir=/usr/include' '--libdir=/usr/lib64'
>> '--libexecdir=/usr/libexec'

Didn't mean to send that yet. Javasript shortcut keys in Gmail suck.
If I wanted shortcut keys, I wouldn't use a web client...

--enable-force-cgi-redirect --enable-fpm
--with-fpm-conf=/etc/php-fpm.conf --with-fpm-log=/var/log/php-fpm.log
--with-fpm-pid=/var/run/php-fpm.pid --enable-sigchild --with-openssl
--with-zlib --enable-bcmath --with-bz2 --enable-calendar
--with-curlwrappers --enable-exif --enable-ftp --with-gd
--with-png-dir --with-zlib-dir --with-xpm-dir --with-ttf
--with-freetype-dir --with-t1lib --enable-gd-native-ttf --with-gettext
--enable-mbstring --with-mcrypt --with-mhash --with-mysql
--with-mysqli --with-ncurses --enable-pcntl --with-pspell
--with-libedit --enable-soap --enable-sockets --enable-sysvmsg
--enable-sysvsem --enable-sysvshm --with-tidy --enable-wddx
--with-xmlrpc --with-iconv-dir --with-xsl --enable-zip --with-pic
--with-pcre-dir --with-layout=GNU --prefix=/usr

Not sure how much it'll help, but you might as well clean up your
./configure options to start with.

Redundant options you should remove:

--disable-debug (already disabled by default)

--libdir=/usr/lib64
--libexecdir=/usr/libexec
--includedir=/usr/include
--with-exec-dir=/usr/bin

Just add --prefix=/usr instead of those three. Once you've done that,
you can get rid of =/usr on the following:

--with-jpeg-dir=/usr to --with-jpeg-dir
--with-libxml-dir=/usr to --with-libxml-dir
--with-freetype-dir=/usr to --with-freetype-dir

--with-pcre-regex = blah is not a valid option. Use --with-pcre-dir
instead (again, no need for =/usr, with --prefix=/usr).