Advice for finding a leaky Apache (probably PHP) process

[Matthew Seaman]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

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

- -- 
Dr Matthew J Seaman MA, D.Phil.                   7 Priory Courtyard
                                                  Flat 3
PGP: http://www.infracaninophile.co.uk/pgpkey     Ramsgate
                                                  Kent, CT11 9PW
-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.14 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkvUAgMACgkQ8Mjk52CukIyCJwCfW+UWZkYxNtTCtEg1NhCkRmTR
Mg8AoIYO4qRSswo/3gMWhVqrQAkzv7PX
=vFG3
-----END PGP SIGNATURE-----