Advice for finding a leaky Apache (probably PHP) process

[Joe Auty]

Not to blow off any of the fine suggestions that have been made, but I
may have solved my problem, sort of... I need help with one other
question though, see below (please and thanks!):

I'm not sure what the connection is here between the PHP upgrade,
perhaps nothing, but I did notice my individual httpd processes taking
up a crapload of RAM - they'd balloon to 600M and beyond, according to
top. According to this Apache directive:

http://httpd.apache.org/docs/2.0/mod/core.html#rlimitmem

> RLimitMEM Directive
>
> Description:    Limits the memory consumption of processes launched by
> Apache children
> Syntax:    RLimitMEM bytes|max [bytes|max]
> Default:    Unset; uses operating system defaults

The OS defaults are applying here. I believe that the kernel option that
is tunable in /boot/loader.conf is "kern.maxdsiz" which is 34359738368
bytes, or 32 gigabytes. This machine is actually a VM guest that has
only been assigned 1 gig, so basically it seemed like there was nothing
to control how far these processes will balloon.

Obviously the better solution is to stop them from ballooning somehow,
but when I restart Apache each process takes under 200 MB, so I set the
RLimitMEM to 250 MB and made sure that I have enough child processes
running. I'll play around with a kern.maxdsiz limit once I can reboot
the machine.

Here's my question...

>From the Apache performance tuning guide:
http://httpd.apache.org/docs/2.2/misc/perf-tuning.html
> The single biggest hardware issue affecting webserver performance is
> RAM. A webserver should never ever have to swap, as swapping increases
> the latency of each request beyond a point that users consider "fast
> enough". This causes users to hit stop and reload, further increasing
> the load. You can, and should, control the MaxClients setting so that
> your server does not spawn so many children it starts swapping. This
> procedure for doing this is simple: determine the size of your average
> Apache process, by looking at your process list via a tool such as
> top, and divide this into your total available memory, leaving some
> room for other processes.

I'm not exactly sure how to best calculate this? Right now top is
showing 260M of active RAM. The total of the "size" or "res" columns for
all of my httpd processes definitely exceeds this. How can I determine
how much RAM a httpd process is *actively* using, as opposed to how much
size it is claiming so that I can best come up with a maxclients setting?



Matthew Seaman wrote:
> On 25/04/2010 02:02:52, Joe Auty wrote:
>
> > I'm wondering if you guys have any general tips on how to find the
> > Apache process/app that is gobbling up my RAM randomly until my machine
> > crashes and I'm forced to reboot? I'm tired of staring at top and
> > working with flimsy hacks such as 10 minute Apache restart cronjobs.
>
> > This seems to start (or worsen) after updating to PHP 5.3, but this is
> > not happening on my test machine where PHP 5.3 is also installed and the
> > same apps are used (although not publicly).
>
> > General tips and suggestions are welcome here!
>
> You need to divide and conquer.  Basically, you've got all of your PHP
> applications running in one PHP interpreter instance per apache child
> and you won't be able to tell which is the problem app until you can
> separate them out.
>
> One way of doing that is the simple and obvious method of commenting out
> each application in turn from the apache config, leaving it running for
> a while and seeing what happens to memory usage.  This is OK only if
> you're happy to turn off chunks of site functionality while testing.
>
> Alternatively, you can set up several different instances of apache,
> each configured to run one of the php applications and each binding to a
> different port on the loopback interface.  Then use another apache with
> a bit of mod_proxy or mod_rewrite glue to redirect the queries
> internally.  Or you could replace the front facing apache instance with
> something like varnish.
>
> Finally, it has been suggested else-thread that you contemplate
> switching to an alternative HTTP daemon like nginx -- in that case,
> you'ld want to be running your PHP apps under fCGI rather than embedded
> in the HTTP daemon.  Running each different PHP app in a separate fCGI
> process shouldn't be too hard to set up.  While this is a valid
> alternative configuration for your site, the Scientist in me complains
> that as an attempt to find out why your PHP apps are misbehaving, there
> are too many uncontrolled changes for it to be a good diagnostic.
>
>     Cheers,
>
>     Matthew
>
_______________________________________________
freebsd-questions at freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to "freebsd-questions-unsubscribe at freebsd.org"

-- 
Joe Auty, NetMusician
NetMusician helps musicians, bands and artists create beautiful,
professional, custom designed, career-essential websites that are easy
to maintain and to integrate with popular social networks.
www.netmusician.org <http://www.netmusician.org>
joe at netmusician.org <mailto:joe at netmusician.org>