Edit report at https://bugs.php.net/bug.php?id=52569&edit=1
ID: 52569
Comment by: f...@php.net
Reported by: mplomer at gmx dot de
Summary: Implement "ondemand" process-manager (to allow zero
children)
Status: Analyzed
Type: Feature/Change Request
Package: FPM related
PHP Version: 5.3.3
Assigned To: fat
Block user comment: N
Private report: N
New Comment:
Here is the v10 of the patch. It corrects the bug trollofdarkness and dbetz
have
found.
In fact the array which is storing event has not been sized up and the event
was
not added. It was working when settings catch_workers_output to yes (but breaks
this feature).
This should now be OK.
test and report please.
++ jerome
Previous Comments:
------------------------------------------------------------------------
[2011-07-10 13:49:40] f...@php.net
The following patch has been added/updated:
Patch Name: fpm-ondemand.v10-5.3.patch
Revision: 1310320180
URL:
https://bugs.php.net/patch-display.php?bug=52569&patch=fpm-ondemand.v10-5.3.patch&revision=1310320180
------------------------------------------------------------------------
[2011-07-10 13:49:24] f...@php.net
The following patch has been added/updated:
Patch Name: fpm-ondemand.v10.patch
Revision: 1310320164
URL:
https://bugs.php.net/patch-display.php?bug=52569&patch=fpm-ondemand.v10.patch&revision=1310320164
------------------------------------------------------------------------
[2011-07-10 13:32:56] mplomer at gmx dot de
@Troll: Does FPM works for you, when using the "dynamic" or "static" pm? Seems
more like an error in the Apache setup, which is somewhat tricky.
------------------------------------------------------------------------
[2011-07-10 12:59:16] f...@php.net
To sum up the patch:
1- new configuration:
* in globals: events.delay (default 500µs). It's the delay between 2 triggers
on a FD event. You can disable the delay by setting it to 0. You should change
it when the ondemand PM
forks more child than it should do.
* in pools: pm = "ondemand" to active the ondemand PM. In this mode, no
processes are forked at startup but when requests are comming
* in pools: pm.process_idle_timeout the time a process should stay idle
without serving any requests before it's killed
2- Here is the debug log I have when setting log_level to debug, error_log to
/dev/stderr and daemonize to no:
[10-Jul-2011 18:58:14.207987] DEBUG: pid 11370, fpm_scoreboard_init_main(),
line 40: got clock tick '100'
[10-Jul-2011 18:58:14.208169] DEBUG: pid 11370, fpm_event_init_main(), line
239: 11 fds have been reserved
[10-Jul-2011 18:58:14.208177] NOTICE: pid 11370, fpm_init(), line 77: fpm is
running, pid 11370
[10-Jul-2011 18:58:14.208189] DEBUG: pid 11370, fpm_event_loop(), line 266:
5984 bytes have been reserved in SHM
[10-Jul-2011 18:58:14.208194] DEBUG: pid 11370, fpm_event_loop(), line 267:
events.delay = 500
[10-Jul-2011 18:58:14.208197] NOTICE: pid 11370, fpm_event_loop(), line 268:
ready to handle connections
[10-Jul-2011 18:58:15.208565] DEBUG: pid 11370,
fpm_pctl_perform_idle_server_maintenance(), line 362: [pool direct] currently 0
active children, 0 spare children
[10-Jul-2011 18:58:16.208945] DEBUG: pid 11370,
fpm_pctl_perform_idle_server_maintenance(), line 362: [pool direct] currently 0
active children, 0 spare children
[10-Jul-2011 18:58:16.778599] DEBUG: pid 11370, fpm_children_make(), line 411:
[pool direct] child 11371 started
[10-Jul-2011 18:58:16.778615] DEBUG: pid 11370, fpm_pctl_on_socket_accept(),
line 532: [pool direct] got accept without idle child available .... I forked
[10-Jul-2011 18:58:17.209294] DEBUG: pid 11370,
fpm_pctl_perform_idle_server_maintenance(), line 362: [pool direct] currently 0
active children, 1 spare children
[10-Jul-2011 18:58:18.209631] DEBUG: pid 11370,
fpm_pctl_perform_idle_server_maintenance(), line 362: [pool direct] currently 0
active children, 1 spare children
[10-Jul-2011 18:58:19.210035] DEBUG: pid 11370,
fpm_pctl_perform_idle_server_maintenance(), line 362: [pool direct] currently 0
active children, 1 spare children
[10-Jul-2011 18:58:20.210382] DEBUG: pid 11370,
fpm_pctl_perform_idle_server_maintenance(), line 362: [pool direct] currently 0
active children, 1 spare children
[10-Jul-2011 18:58:21.210751] DEBUG: pid 11370,
fpm_pctl_perform_idle_server_maintenance(), line 362: [pool direct] currently 0
active children, 1 spare children
[10-Jul-2011 18:58:22.211264] DEBUG: pid 11370,
fpm_pctl_perform_idle_server_maintenance(), line 362: [pool direct] currently 0
active children, 1 spare children
[10-Jul-2011 18:58:23.211732] DEBUG: pid 11370,
fpm_pctl_perform_idle_server_maintenance(), line 362: [pool direct] currently 0
active children, 1 spare children
[10-Jul-2011 18:58:24.212057] DEBUG: pid 11370,
fpm_pctl_perform_idle_server_maintenance(), line 362: [pool direct] currently 0
active children, 1 spare children
[10-Jul-2011 18:58:25.212462] DEBUG: pid 11370,
fpm_pctl_perform_idle_server_maintenance(), line 362: [pool direct] currently 0
active children, 1 spare children
[10-Jul-2011 18:58:26.212763] DEBUG: pid 11370,
fpm_pctl_perform_idle_server_maintenance(), line 362: [pool direct] currently 0
active children, 1 spare children
[10-Jul-2011 18:58:27.213155] DEBUG: pid 11370,
fpm_pctl_perform_idle_server_maintenance(), line 362: [pool direct] currently 0
active children, 1 spare children
[10-Jul-2011 18:58:27.221542] DEBUG: pid 11370, fpm_got_signal(), line 76:
received SIGCHLD
[10-Jul-2011 18:58:27.221575] DEBUG: pid 11370, fpm_children_bury(), line 254:
[pool direct] child 11371 has been killed by the process managment after
10.442991 seconds from start
[10-Jul-2011 18:58:28.214082] DEBUG: pid 11370,
fpm_pctl_perform_idle_server_maintenance(), line 362: [pool direct] currently 0
active children, 0 spare children
[10-Jul-2011 18:58:29.214542] DEBUG: pid 11370,
fpm_pctl_perform_idle_server_maintenance(), line 362: [pool direct] currently 0
active children, 0 spare children
[10-Jul-2011 18:58:30.214972] DEBUG: pid 11370,
fpm_pctl_perform_idle_server_maintenance(), line 362: [pool direct] currently 0
active children, 0 spare children
------------------------------------------------------------------------
[2011-07-10 12:32:11] trollofdarkness at gmail dot com
Hello,
Ok so it is normal.
I think it would be great to make a short sum up of what's been introduced in
the FPM configuration by this patch, and what behaviour of what already
existing config directive has been modified. I read the entire bug file, but
did not completely understand what's been modified / introduced about the
config directives.
To answer your question I am running Debian Lenny 64bits. PHP has been compiled
successfully from the last SVN sources (5.3 branch). And as I said, I used both
Apache2 and Nginx, I tried with both sockets and host:ip methods and is has
exactly the same behaviour with the two methods :
When FPM starts, no process is launched for the given pool (ok, that's right)
When a request comes... the web server handles it, passes it to FPM ... But
after, I don't know, I did not see anything shocking in the log file... And
absolutly no process is started by FPM. So the request waits until the
webserver finally decides that FPM is not responding correctly and displays an
error message instead (after at least 1 minute, so that's not about FPM being
slow or something like that).
Thanks in advance.
Troll
------------------------------------------------------------------------
The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
https://bugs.php.net/bug.php?id=52569
--
Edit this bug report at https://bugs.php.net/bug.php?id=52569&edit=1
