+- ispCP - Board - Support (http://www.isp-control.net/forum)
+-- Forum: ispCP Omega Support Area (/forum-30.html)
+--- Forum: Usage (/forum-34.html)
+--- Thread: PHP_FCGI_CHILDREN bug? (/thread-5613.html)
Pages: 1 2
PHP_FCGI_CHILDREN bug? - pgentoo - 02-03-2009 07:36 AM
It looks like there is a bug in PHP where it doesn't always cleanup the php-cgi processes when you use PHP_FCGI_CHILDREN in the php5-fcgi-starter.
I've noticed this where i'd have many more processes running for a site than the PHP_FCGI_CHILDREN specified. Restarting apache wouldn't even clean them up, I'd have to kill -9 them.
I commented out these lines and did some tweaks to the global configuration in the fcgid_ispcp.conf and its working much better.
Should we keep these settings in the starter script for any real reason, so should they not be default, since there are known issues with PHP?
Just thought I'd throw that out there...
Here is my current fcgid_ispcp.conf for reference
Code:
<IfModule mod_fcgid.c>
AddHandler fcgid-script .php .php5
IPCConnectTimeout 90
IdleTimeout 300
IdleScanInterval 120
ProcessLifeTime 900
MaxProcessCount 200
DefaultMinClassProcessCount 1
DefaultMaxClassProcessCount 5
IPCCommTimeout 300
BusyTimeout 300
BusyScanInterval 120
ErrorScanInterval 3
MaxRequestsPerProcess 500
ZombieScanInterval 3
</IfModule>One of my sites is getting about 1-2million page "hits" per day (reported by awstats), and this seems to be holding up fine.
Thoughts?
-
pGentoo
RE: PHP_FCGI_CHILDREN bug? - Lucan - 02-03-2009 07:55 AM
I had that probleme also some time ago.
But after looking for the failure, i noticed that fcgid_ispcp AND fastcgi_ispcp is enabled.
After disabling fastcgi_ispcp everything worked fine for me again.
I wondered how that could have happened, because i never activated fastcgi_ispcp....
But maybe something similar happened on your system?
RE: PHP_FCGI_CHILDREN bug? - pgentoo - 02-03-2009 08:08 AM
No, I'm on gentoo, so the enabling/disabling of stuff is a little different. My setup is clean, but I still notice that the php bug was being exposed. I googled it and found a bug in php's tracker on it too. Looks like it has been around for quite a while.
I know that putting that setting in the starter script, enables tuning of it per site, but why not just let mod_fcgid do this dynamically based on the load of the sites.
It seems like tuning the values:
Code:
DefaultMinClassProcessCount 1
DefaultMaxClassProcessCount 5to best fit your system, should do just fine...
If there are any huge benifits to doing it the default ispcp way, and i'm missing it, please someone chime in.
Thanks,
pGentoo
RE: PHP_FCGI_CHILDREN bug? - pgentoo - 02-10-2009 11:52 PM
Just a followup on this thread...
Relying on the system wide process management via fcgid_ispcp.conf as stated above has been working really well for me. Low load sites spawn up one processes, and after a while of not being hit, this process shuts itself down. For sites that have low but more constant traffic, they keep one process running pretty much all times. On one of my sites that gets pretty constant traffic, at about 2000 unique visits per day, the number of processes fluctuates between 1 and 3 from what i've seen, usually sitting at 1 or 2.
I haven't had any issues running this way, letting mod_fcgid handle all my process management directly, instead of having php do it via the environment variables.
If anyone is having problems with tons of php processes forking off, or processes not terminating when apache restarts, then this setting change is likely for you.
Feed back appreciated...
-
pGentoo
RE: PHP_FCGI_CHILDREN bug? - Keirnan - 02-11-2009 01:36 AM
(02-10-2009 11:52 PM)pgentoo Wrote: Just a followup on this thread...
Relying on the system wide process management via fcgid_ispcp.conf as stated above has been working really well for me. Low load sites spawn up one processes, and after a while of not being hit, this process shuts itself down. For sites that have low but more constant traffic, they keep one process running pretty much all times. On one of my sites that gets pretty constant traffic, at about 2000 unique visits per day, the number of processes fluctuates between 1 and 3 from what i've seen, usually sitting at 1 or 2.
I haven't had any issues running this way, letting mod_fcgid handle all my process management directly, instead of having php do it via the environment variables.
If anyone is having problems with tons of php processes forking off, or processes not terminating when apache restarts, then this setting change is likely for you.
Feed back appreciated...
-
pGentoo
This sounds like my problem exactly. I have made my fcgid-ispcp.conf look just like yours. Lets see if that is any better.
After a reboot with your settings, I still have 9 php5-cgi processes running. Shouldn't I only have 5? Or is it a max of 200?
Is there anything else I need to do to let it handle the process management?
RE: PHP_FCGI_CHILDREN bug? - pgentoo - 02-11-2009 02:00 AM
As I understand it (new to fcgi too..)
MaxProcessCount 200 = MAX of 200 TOTAL fcgi processes system wide (I believe)
DefaultMinClassProcessCount 1 = Min 1 process per "class", which I believe is per site and/or user? But i see that if the site doesn't have any php, or it hasn't been loaded in some time, that there are 0 processes for it, which is quite nice. I think this setting means that when the site is first hit, it will spawn of this number of processes, but they won't necessarily keep this many alive if the site is idle.
DefaultMaxClassProcessCount 5 = Max of 5 per site and/or user?
Another thing, did you comment out PHP_FCGI_CHILDREN from your starter scripts for all your domains? This needs to be done, or else php will do its own process management, which is where the issues are coming from.
-
pGentoo
RE: PHP_FCGI_CHILDREN bug? - Keirnan - 02-11-2009 05:11 AM
(02-11-2009 02:00 AM)pgentoo Wrote: Another thing, did you comment out PHP_FCGI_CHILDREN from your starter scripts for all your domains? This needs to be done, or else php will do its own process management, which is where the issues are coming from.
-
pGentoo
Ahh, there we go.
I went in and commented that stuff out, and now things seem to be running better. I have fewer processes so far, and seem to be using less resources overall.
The test will be after a few hours, if the processes are stacking up or not. I will report back once I've been running with this config for a while.
RE: PHP_FCGI_CHILDREN bug? - Keirnan - 02-11-2009 09:53 AM
(02-11-2009 05:11 AM)Keirnan Wrote: Ahh, there we go.
I went in and commented that stuff out, and now things seem to be running better. I have fewer processes so far, and seem to be using less resources overall.
The test will be after a few hours, if the processes are stacking up or not. I will report back once I've been running with this config for a while.
It certainly seems better now, at least, my overall resource utilization seems lower. I don't see any php processes just hanging around, and I haven't seen more than 3 active at a time.
That said, however, now I see a number of apache2 processes, like 6 of them. They are using about 32m of memory each. Is that normal?
RE: PHP_FCGI_CHILDREN bug? - pgentoo - 02-11-2009 02:02 PM
Good to hear its working better for you.
Depending on how you have apache2 configured (which MPM) this will differ. I recommend not using prefork, and using something like the "event" MPM, now that you are running fully only fcgi.
Event MPM processes/threads/etc, can be configured via the apache config files. This location differs based on the distro of linux you are running, but you should know how to do this.
Just FYI, with my setup, i see 6 apache2 processes as well, so you're probably fine.
Let me know how it goes...
-
pGentoo
RE: PHP_FCGI_CHILDREN bug? - simple - 02-12-2009 10:02 AM
I tried your config, but had to change it a little with debian etch:
MaxRequestsPerProcess << Invalid command 'MaxRequestsPerProcess', perhaps misspelled or defined by a module not included in the server configuration
Had to pull that one out.