httpd-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marc Perkel <m...@perkel.com>
Subject Re: [users@httpd] Serious Memory Leak Problem
Date Sat, 22 Oct 2005 14:25:56 GMT


David Tonhofer, m-plify S.A. wrote:

>
>
> --On Friday, October 21, 2005 11:16 AM -0700 Marc Perkel 
> <marc@perkel.com> wrote:
>
>>
>>
>> David Tonhofer, m-plify S.A. wrote:
>>
>>> I really don't know what the problem could be but let's
>>> start a discussion:
>>>
>>> 1) How many children are there?
>>> 2) What is the sum of the processes RSS size?
>>> 3) What is the sum of the processes VSIZE size?
>>>
>> Thanks for your perl script. Here's the results:
>>
>> 1029308 minor faults so far
>> 227 major faults so far
>> 1532 user time jiffies burnt so far
>> 25812 kernel time jiffies burnt so far
>> 55062589440 bytes of allocated virtual memory
>> 9328185344 bytes of resident memory allocated
>> 294 children active right now
>>
>> Excuse my ignorance but what does the mean?
>>
>> Thanks in advance
>
>
>
> Well,
>
> "minor faults"/"major faults" are about paging (if I remember
> correctly, a minor fault means  "page has to be read from disk,
> scratching a page in memory" and major fault means "page has to
> be read from disk, but before that an existing page has to be written")
>
> The jiffies express how many CPU has been used on the program,
> they used to be 1/100 of second units, not sure whether that still
> holds.
>
> What is interesting here is:
>
>> 55'062'589'440 bytes of allocated virtual memory
>>  9'328'185'344 bytes of resident memory allocated
>
>
> The first number is just the sum of the processes' virtual memory
> size - they indicate that they want 55 GByte in toto, but this being
> just 'virtual', it's not a problem.
>
> The second number is the sum of the processes' effective memory size -
> 9 GByte of RAM... more than you actually have? (scratches head) That
> shouldn't be possible, except if some RAM is counted twice. Damn.

Well - I have 4 gigs and usually running 1/2 full so the 9g can't be 
right. But maybe if we trace how it is wrong it might lead to the problem

>
> Here are my number (light charge on an dual XEON on RH ES4, only
> static serves, some PHP though but mostly Tomcat running the show):
>
> 87862 minor faults so far
> 9291 major faults so far
> 869 user time jiffies burnt so far
> 379 kernel time jiffies burnt so far
> 1271640064 bytes of allocated virtual memory
> 50085888 bytes of resident memory allocated
> 10 children active right now
>
> Acid test:  ~ 5 MByte resident memory per child for me
>            ~31 MByte resident memory per child for you
>
> This does not sound too unreasonable if there is a lot of Perl going on.
>
> We need more numbers...
>
ok - how do we get more numbers. And - the real problem is the memory 
growth. I have to limit my MaxRequestsPerChild to 10 because if I change 
it to 30 total system memory usage grows withing minutes swelling by a 
full gig. I really need to solve this. Thanks for your help.


---------------------------------------------------------------------
The official User-To-User support forum of the Apache HTTP Server Project.
See <URL:http://httpd.apache.org/userslist.html> for more info.
To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
   "   from the digest: users-digest-unsubscribe@httpd.apache.org
For additional commands, e-mail: users-help@httpd.apache.org


Mime
View raw message