Date: Wed, 29 Oct 2008 10:38:34 +0100 From: Mel <fbsd.questions@rachie.is-a-geek.net> To: freebsd-questions@freebsd.org Cc: Francis =?iso-8859-1?q?Dub=E9?= <freebsd@optiksecurite.com>, Jeremy Chadwick <koitsu@freebsd.org> Subject: Re: collecting pv entries -- suggest increasing PMAP_SHPGPERPROC Message-ID: <200810291038.35167.fbsd.questions@rachie.is-a-geek.net> In-Reply-To: <49072561.90904@optiksecurite.com> References: <49060AE0.3000301@optiksecurite.com> <20081027200253.GA29814@icarus.home.lan> <49072561.90904@optiksecurite.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tuesday 28 October 2008 15:44:49 Francis Dub=E9 wrote: > Jeremy Chadwick a =E9crit : > > On Mon, Oct 27, 2008 at 12:56:30PM -0700, Chuck Swiger wrote: > >> On Oct 27, 2008, at 12:38 PM, FreeBSD wrote: > >>>> You need to keep your MaxClients setting limited to what your system > >>>> can run under high load; generally the amount of system memory is the > >>>> governing factor. [1] If you set your MaxClients higher than that, > >>>> your system will start swapping under the load and once you start > >>>> hitting VM, it's game over: your throughput will plummet and clients > >>>> will start getting lots of broken connections, just as you describe. > >>> > >>> According to top, we have about 2G of Inactive RAM with 1,5G Active > >>> (4G total RAM with amd64). Swapping is not a problem in this case. > >> > >> With 4GB of RAM, you're less likely to run into issues, but the most > >> relevant numbers would be the Swap: line in top under high load, or the > >> output of "vmstat 1" / "vmstat -s". > > We're monitoring our swap with cacti, and we've never been swapping even > during high load because we dont let apache spawn enough process to do so. > > >> It would also be helpful to know what your httpd's are looking like in > >> terms of size, and what your content is like. For Apache serving most= ly > >> static content and not including mod_perl, mod_php, etc, you tend to > >> have 5-10MB processes and much of that is shared, so you might well be > >> able to run 400+ httpd children. On the other hand, as soon as you pu= ll > >> in the dynamic language modules like perl or PHP, you end up with much > >> larger process sizes (20 - 40 MB) and much more of their memory usage = is > >> per-process rather than shared, so even with 4GB you probably won't be > >> able to run more than 100-150 children before swapping. > > Here's an example of top's output regarding our httpd process : > 54326 apache 1 96 0 156M 13108K select 1 0:00 0.15% httpd > 54952 apache 1 96 0 156M 12684K select 1 0:00 0.10% httpd > 52343 apache 1 4 0 155M 12280K select 0 0:01 0.10% httpd > > Most of our page are in HTML with a LOT of images. Few PHP pages, very > light PHP processing. Then your best bet is to properly set up mod_expires for the images. More t= hen=20 anything else that will reduce the load on your server. http://httpd.apache.org/docs/2.2/mod/mod_expires.html#expiresbytype The better solution involves recoding your site to serve images from a=20 different webserver (can be the same machine, simply use a very light jail)= =2E=20 This installation only loads mod_expires and mod_headers and serves images= =20 only. I would do this regardless, for two reasons: 1) You will almost certainly get rid of PMAP_SHPGPERPROC on the document=20 server 2) You will more easily detect bottlenecks in scripts, because the problem = is=20 not aggrevated/masked by the image serving. =2D-=20 Mel Problem with today's modular software: they start with the modules and never get to the software part.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200810291038.35167.fbsd.questions>