Re: [users@httpd] Serious Memory Leak Problem

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 





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



--On Friday, October 21, 2005 11:16 AM -0700 Marc Perkel <marc@xxxxxxxxxx> 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.

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...

Thanks for your help. I was using mod_perl and I uninstalled it trying to isolate that in case it was somehow the problem. No difference. And, like you - I used to run a dual xeon system and at that time I was amazed by how little memory it was using. The difference that I know of is:

1) I'm running a dual core Athlon instead of 2 xeon processors.
2) I'm running the 64 bit version of fedora Core 4 instead of the 32 bt version.

I also had a second server that had a P4 processor - not hyperthreaded - and memory usage was also very low on that.

Here's some data I saved:


On the new server running top it shows *httpd* processes using:

virt 201m
res 53m
shr 11m

On the old server the *httpd* process show:

virt: 50k
res 14m
shr 10k

That's quite a difference.

What can I do to nail this down. Or - is the 64 bit version just broken? Or is the a Dual Core Athlon related problem?



---------------------------------------------------------------------
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@xxxxxxxxxxxxxxxx
  "   from the digest: users-digest-unsubscribe@xxxxxxxxxxxxxxxx
For additional commands, e-mail: users-help@xxxxxxxxxxxxxxxx



[Index of Archives]     [Open SSH Users]     [Linux ACPI]     [Linux Kernel]     [Linux Laptop]     [Kernel Newbies]     [Security]     [Netfilter]     [Bugtraq]     [Squid]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Samba]     [Video 4 Linux]     [Device Mapper]

  Powered by Linux