Gosh, I am going to take a crack at this, but it's been a long while. I know somewhere this stuff is documented. On Linux these things are not terribly well documented anywhere that I have found.
Okay, the VIRT/VSZ/VSS is the virtual memory size of your process. This includes all shared pages with other processes. The way the VM system works, this is not really terribly accurate way to tell the memory usage of your process tho. The RES figure is the resident size of your process, how much of it is actually in ram at the current moment. This figure does not include Shared Pages of dynamically loaded libraries that are also loaded by other programs (eg, libc). SHR/SHARE (on linux at least) is the pages that COULD be shared with other processes (and usually are, such as libc). However, all this said, none of these columns clearly demonstrates the shared COPY ON WRITE (COW) pages. COW pages are shared between related processes and are a "optimization". Basically pages marked as copy on write, are shared between the processes until they are written to. So long as they are not, then they remain shared. This is the type of shared memory you are talking about when you mention Apache "sharing" pages between children. Eg, you load a big ole hash in the parent, then fork, the children should not actually copy the memory but share it until it starts getting written to. As far as I know, especially on linux, there is no way to tell exactly how 'shared' your apache processes are, except by using apache+mod_perl with GTop (and it's associated apache module). I certainly don't know of a way to get this figure from the command line. Maybe someone else on the list does. I have seen people post ways to 'approximate' how shared your applications are from ps/top. Just looking at the 'RES' column and observing that upon start most of your apache processes should be nearly the same size. Over time this will change, and some will end up being larger. This could be because of alloc()'s or could be because of COW pages being written to and becoming un-shared. So long as the bulk of them are roughly the same size, you can assume your shared-ness is okay. If it's of concern, then you might consider making sur MaxRequests is set so that children get restarted every so often, or using apache + gtop (which is what I have done when I have needed to). Maybe someone can add some detail to help Ben approximate his sharedness... OHHH, and BTW, when do you load this hash? If it's not done in the Parent/Master process in the early part of the apache initialization process, each process when forks then would of course load the hash separately and it would not be shared. This means in the module initialization phase. You can force this by putting the code you want to load the hash into your startup.pl file or calling it from there. Other methods would maybe be BEGIN blocks, or in a module in a place that would be executed soon as the module is loaded. Now that I think about this, I bet this may be your problem if you are sure the data is not being shared with COW pages. Best, On Thu, 2005-02-10 at 16:51 -0600, ben syverson wrote: > Hi Richard, > > Sorry -- I should have been more specific: > > On Feb 10, 2005, at 4:40 PM, Richard F. Rebel wrote: > > > How are you detecting that a process is growing by a couple megs? > > Via "top" on the command line. > > > Also, you mention that the processes grow by a couple megs. By this do > > you mean that each subsequent fork is a few megs larger than the > > parents? > > Each fork (and also the parent) winds up being a few megs larger when > the hash is loaded. Right now I'm testing with 5 children, and If I > comment out the line that loads the module which loads the hash, all 6 > processes wind up being larger. > > > One more question, what mpm are you using? > > Old-style pre-fork. > > Thanks! > > - ben > -- Richard F. Rebel cat /dev/null > `tty`
signature.asc
Description: This is a digitally signed message part
