collecting pv entries -- suggest increasing PMAP_SHPGPERPROC

[Francis Dubé]

Jeremy Chadwick a écrit :
> On Tue, Oct 28, 2008 at 10:44:49AM -0400, Francis Dubé wrote:
>   
>> 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.
>>     
>
> I'm not sure you fully understand the concept of swapping (the term can
> be used for a multitude of things).  :-)  Some processes which sit
> idle/unused will have portions of their memory "swapped out" (to
> swap/disk) to allow for actively running processes to utilise physical
> memory.  This is something to keep in mind.
>
>   
>>>> 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 ?
>>     
>
> It's as I expected -- you don't understand the difference between
> SIZE (SZ) and RES (RSS).  The simple version:
>
> SIZE == amount of memory that's shared across all processes on the
> machine, e.g. shared libraries.  It doesn't mean "156MB is being taken
> up per process".
>
> RES == amount of memory that's specifically allocated to that individual
> process.  The three httpd processes above are taking up a total of
> ~38MBytes of memory (13108K + 12684K + 12280K).
>   

As I said, even with RES the numbers dont seems to have any sense.

Let's say 12500K x 450 = ~5500MBytes. Considering there's a lot of 
process other than Apache running on the server...there's something 
wrong. Is there something shared in RES too ?

>   
>> 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 ? ;)
>>     
>
> Others will have to explain the shared memory/pages aspect, as it's
> beyond my understanding.  But recent versions of 7.0 and 7.1-PRERELEASE
> contain a tool called procstat(1) which can help you break down the
> memory usage within a process.
>
>   
Our next server will be in 7.0 for sure.