Date: Sun, 25 Apr 2010 17:40:49 -0400 From: Joe Auty <joe@netmusician.org> To: freebsd-questions@freebsd.org Subject: Re: Advice for finding a leaky Apache (probably PHP) process Message-ID: <4BD4B6E1.9020800@netmusician.org> In-Reply-To: <4BD40203.90203@infracaninophile.co.uk> References: <4BD394BC.7030501@netmusician.org> <4BD40203.90203@infracaninophile.co.uk>
next in thread | previous in thread | raw e-mail | index | archive | help
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@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "freebsd-questions-unsubscribe@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@netmusician.org <mailto:joe@netmusician.org>
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4BD4B6E1.9020800>