From owner-freebsd-questions@FreeBSD.ORG Tue Oct 28 14:45:02 2008 Return-Path: Delivered-To: freebsd-questions@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 35BEB1065679 for ; Tue, 28 Oct 2008 14:45:02 +0000 (UTC) (envelope-from freebsd@optiksecurite.com) Received: from relais.videotron.ca (relais.videotron.ca [24.201.245.36]) by mx1.freebsd.org (Postfix) with ESMTP id 096678FC17 for ; Tue, 28 Oct 2008 14:45:01 +0000 (UTC) (envelope-from freebsd@optiksecurite.com) MIME-version: 1.0 Content-transfer-encoding: 8BIT Content-type: text/plain; charset=ISO-8859-1; format=flowed Received: from [31.33.7.200] ([69.70.93.206]) by VL-MO-MR002.ip.videotron.ca (Sun Java(tm) System Messaging Server 6.3-4.01 (built Aug 3 2007; 32bit)) with ESMTP id <0K9G009YBEB1AC90@VL-MO-MR002.ip.videotron.ca>; Tue, 28 Oct 2008 10:45:01 -0400 (EDT) Message-id: <49072561.90904@optiksecurite.com> Date: Tue, 28 Oct 2008 10:44:49 -0400 From: =?ISO-8859-1?Q?Francis_Dub=E9?= User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) To: Jeremy Chadwick References: <49060AE0.3000301@optiksecurite.com> <49061898.60903@optiksecurite.com> <6DE465B2-C9D2-4A97-994F-D08CD7FE6211@mac.com> <20081027200253.GA29814@icarus.home.lan> In-reply-to: <20081027200253.GA29814@icarus.home.lan> Cc: freebsd-questions@freebsd.org Subject: Re: collecting pv entries -- suggest increasing PMAP_SHPGPERPROC X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Oct 2008 14:45:02 -0000 Jeremy Chadwick a écrit : > 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 mostly >> 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 pull 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. 156M x 450 process = way more RAM than what we have (same for RES). Concretely, how must I interpret these results ? >> >>> After checking multiple things (MySQL, networks, CPU, RAM) when a drop >>> occurs, we determined that everytimes there is drop, the number is >>> Apache's process is MaxClients (ps aux | grep httpd | wc -l) and the >>> new http request doesn't get answer from Apache (the TCP hanshakes >>> completes but Apache never push the data). >>> >> Yes, that aspect is going to be the same pretty much no matter what the >> bottleneck is or how large you set MaxClients to. You will end up with >> significantly better results (fewer drops, higher aggregate throughput) >> if you tune appropriately than if you try to ramp MaxClients up further >> than the available hardware can support. >> At the moment, the MaxClients isn't higher than the hardware can support, but it will if i raise it again. I've gone through the Apache's doc concerning high load tuning and did all that can be done on the fly (without downtime). We were already planning to add another webserver soon, but maybe not that soon :) >> You might find that checking out the URLs being most commonly listed in >> http://yourdomain.com/server-status when you run into high load problems >> will point towards a particular script or dynamic content which is >> causing a bottleneck. >> Thanks for the tips, i'll take a look at this. > > One of the problems here is that the individual reporting the problem is > basing all of his conclusions on the first couple lines of top(1) > output, and is not bothering to look at per-process RSS or SZ. "I have > lots of Inactive RAM, so what's the problem!??!" > > We should probably take the time to explain to the user the fact that > shared pages per process != amount of RAM that's been touched/used at > one point but is currently unused. Without someone explaining how the > VM works in this regard, he's going to continue to be confused and > correlate things which aren't necessarily related. > Right ! I would really appreciate few explanation on this. Do the shared pages counts as active or inactive RAM ? How can i calculate how much physical RAM an apache process is taking ? How the VM works in this regard ? ;) Thanks everyone ! Francis Dube R&D Optik Securite www.optiksecurite.com