Numerous /usr/bin/php4's idling, eating up RAM

10 posts / 0 new
Last post
#1 Tue, 01/15/2008 - 17:16
amalec

Numerous /usr/bin/php4's idling, eating up RAM

Running Virtualmin 3.50 Pro, Webmin 1.380 on Fedora 6 512 MB of RAM.

Apache php.conf is mostly uncommented, while php4.conf is mostly commented (the opposite of what's recommended what's recommended in the FAQs, maybe this is the problem?)

There is only one virtual server that uses php4 by default (and its sub server, which runs php5).

As the server receives visitors the number of 0% CPU /usr/bin/php4 processes increases in a time of about an hour, until there's around 50 of php4 processes.

PHP script execution mode is FCGId (run as virtual server owner) with 4 PHP FCGId sub-processes for every virtual server. Ruby scripts disabled, Run CGI scripts as domain owner? set to Yes.

For the other virtual servers which all run PHP5 there is a maximum of 4 php-cgi's ever running.

I suspect this has caused my server to become unresponsive recently, when it ran out of virtual memory.

php4.ini is configured for a maximum execution time of 30 seconds (the default setting, like all others).

UPDATE: I've checked for any scripts that modify the execution time and I've disabled all of them. The problem still remains.

I'd really appreciate any help.

-A

Post edited by: amalec, at: 2008/01/15 17:23<br><br>Post edited by: amalec, at: 2008/01/15 17:34

Tue, 01/15/2008 - 17:46
Joe
Joe's picture

<div class='quote'>Apache php.conf is mostly uncommented, while php4.conf is mostly commented (the opposite of what's recommended what's recommended in the FAQs, maybe this is the problem?)</div>

Doesn't matter...you just cannot have both mod_php4 and mod_php5 loaded at the same time in one Apache instance. It'll segfault. If you're using all mod_fcgid execution for PHP scripts, you can even disable both mod_php versions, and save yourself several MB of RAM. I generally recommend this unless you need mod_php for some reason, though I've been hesitant to make it the default.

50 php processes under fcgid isn't all that much, and most of the memory is shared...but with 512MB, if you've got lots of other services, particularly mail with AV and spam scanning, it's certainly possible to hit the ceiling. You could follow the docs on reducing memory usage here:

http://www.virtualmin.com/documentation/id,virtualmin_on_low_memory_syst...

Limits in mod_fcgid don't seem to actually do much, according to a couple of threads we've had here in the forums...I've never run into any serious issues on our two production boxes, both of which run mod_fcgid, using the defaults...but others have reported problems. It could be related to one or more of the applications you have running--the complaints we have seen have been from folks running different apps than the ones we run here (we run Joomla, DokuWiki, WordPress, and FlySpray all with regular usage).

Oh, yeah, we did find one bug in PHP5 that effected mod_fcgid, but there were frequent errors in the error_log of the affected host. You haven't mentioned any errors from the logs, so I won't assume you're hitting that bug. We rolled an updated package to fix that bug on CentOS 4, but it may still affect the FC6 OS standard package.

--

Check out the forum guidelines!

Tue, 01/15/2008 - 18:03 (Reply to #2)
amalec

Thanks for the reply.

The error logs look fine, aside from hundreds

[code:1][Wed Jan 16 10:50:16 2008] [warn] mod_fcgid: stderr: PHP Warning: Call-time pass-by-reference has been deprecated - argument passed by value; If you would like to pass it by reference, modify the declaration of [runtime function name](). If you would like to enable call-time pass-by-reference, you can set allow_call_time_pass_reference to true in your INI file. However, future versions may not support this any longer. in /home/blah/commecialscript_Ididntwrite/blah.php on line 75
[/code:1]

Which is completely another issue I understand.

What is your opinion on setting non-default fcgi values for
IdleTimeout
IdleScanInterval
MaxProcessCount
etc...

I'm pretty sure the defaults would have taken care of the issues I was having though. Or am I way off the mark here?

-A

Tue, 01/15/2008 - 18:27 (Reply to #3)
amalec

Sorry about replying instead of editing, but apparently &quot;Oops! You've hit a bug in the forum software. It'll be fixed soon.&quot;

&quot;50 php processes under fcgid isn't all that much&quot;

Even if most of them are using 0% CPU?

&quot;.you just cannot have both mod_php4 and mod_php5 loaded at the same time in one Apache instance. It'll segfault.&quot;

I've done this before, but thanks to your docs and forum I quickly fixed it. Searching your website and forums using Google seems to be pretty ineffective for some reason though.

&quot;you can even disable both mod_php versions, and save yourself several MB of RAM. I generally recommend this unless you need mod_php for some reason, though I've been hesitant to make it the default.&quot;

I tried this, and the server returned an error (I'll confirm this and maybe make another post).

Again thanks!

-A

Mon, 01/21/2008 - 15:58 (Reply to #4)
Joe
Joe's picture

Yeah, I've seen this before - on some systems, the php-cgi processes continue to run even after the timeout set in the Apache config or php.ini. The only solution I found was a cron job to kill them after about an hour of inactivity ..

I'd be interested to know if your fcgid.conf changes helped with this problem though. Another option is to reduce the number of running PHP processes per domain, which can be done in Virtualmin.

--

Check out the forum guidelines!

Wed, 02/06/2008 - 13:30 (Reply to #5)
amalec

Just a final update.

The only changes I've made were to /etc/httpd/conf.d/mod_fcgid.conf

Added lines:

<div class='quote'>IdleTimeout 120
IdleScanInterval 60
ProcessLifeTime 600</div>

I am running Virtualmin 3.50 (Pro) and have not upgraded. In the two weeks the problem has not repeated itself, though I can't confirm this is thanks to the config changes. May be worth a try for those with the same problem though.

Sat, 02/09/2008 - 01:26 (Reply to #6)
webinger

If you want so save RAM using fcgi with php4 try this setting in your <b>php4.fcgi</b> config:

#PHP_FCGI_CHILDREN=4
#export PHP_FCGI_CHILDREN

If you use Apaches &quot;KeepAlive On&quot; in <b>apache2.conf</b>. Then set the KeepAliveTimeout to a lower value like 10.

this would use more CPU instead of RAM. I Also got rid of that FCGI_CHILDREN on my server. The speed is very god and the RAM usage is at a very constant level.
regards

Sat, 02/09/2008 - 07:47 (Reply to #7)
Joe
Joe's picture

You can also make this change via the Virtualmin web user interface - just select your domain on the left menu, click on Website Options under Server Configuration, and change the 'PHP FCGId sub-processes' to 1.

--

Check out the forum guidelines!

Sun, 02/10/2008 - 04:26 (Reply to #8)
webinger

i think thats a mistake i only have

Run CGI scripts as domain owner? Yes No
PHP script execution mode Apache mod_php (run as Apache's user)
CGI wrapper (run as virtual server owner)
FCGId (run as virtual server owner)
Ruby script execution mode Ruby scripts disabled
CGI wrapper (run as virtual server owner)
Write logs via program?
(Handles missing log directory) Yes No

in Website Options under Server Configuration

but you can change your default php4/5.fci file in virtualmin &gt; system settings &gt;server templates &gt; your default config &gt; php wrapper scripts
FastCGI wrapper for PHP 4
and
FastCGI wrapper for PHP 5

use Script below ...
and enter for example:

#!/bin/sh
PHPRC=$PWD/../etc/php5
export PHPRC
#PHP_FCGI_CHILDREN=4
#export PHP_FCGI_CHILDREN
SCRIPT_FILENAME=$PATH_TRANSLATED
export SCRIPT_FILENAME
exec /usr/bin/php5-cgi

Mon, 01/21/2008 - 15:21
amalec

Just a final update.

This issue is possibly a bug (not in the VirtualMin software).

The php4 processes that idled were <i>never</i> killed, and never used. My virtual memory usage for that period is a plot that basically increases every few hours until it reaches the limit

For whatever reason the issue has been mostly resolved, with memory usage bouncing up and down with load as expected.

For the record I've added the following lines to fcgid.conf

[code:1]IdleTimeout 120
IdleScanInterval 60
ProcessLifeTime 600[/code:1]

Topic locked