Re: measuring shared memory on linux (was [Fwd: Re: /proc/*/statm, exactly what does "shared" mean?)]

[prev] [thread] [next] [Date index for 2005/02/14]

On Sat, 2005-02-12 at 11:43 -0500, Stas Bekman wrote:
> Richard F. Rebel wrote:
> > Hello Perrin and other modperl users,
> > 
> > I have forwarded an email from Hugh Dickens as a follow up on recent
> > discussion of mod_perl+apache forked children and copy-on-write pages.
> 
> Thanks for pursuing that issue at the linux kernel list, Richard. As you 
> have suggested it doesn't look very good.

I want to add my thanks too.

> At the same time the actual sharing is the same as before, so you still 
> win from preloading things. It's just that you can't quantify it anymore.

This is especially unfortunate because preloading appears to make the
SIZE measurement increase, as does the use of mmap in things like
Cache::FastMmap.  Before, we were assuming you could see how much memory
was truly being used by subtracting SHARE from SIZE, but it seems that
won't work.

> Once we get some "official" resolution we should update the tools like 
> Apache-VMonitor to reflect that discovery, in order to not mislead users.
> More importantly it affects Apache::SizeLimit and Apache::GTopSizeLimit, 
> which as the things are now, aren't working properly when someone limits 
> on shared memory.

Or on anything at all, since the size measurements they use include
things that really shouldn't be counted as part of the process size.

It seems that to tune properly you would need to send in requests with a
benchmarking tool and keep adjusting MaxClients upward while watching
the free memory on the box.  That's really ugly.  Maybe there's a way to
count memory used by each process slowly but accurately which we could
use during tuning at least.

- Perrin