vm.pmap.shpgperproc and Apache

Mike Andrews mandrews at bit0.com
Mon Nov 26 13:07:00 PST 2007

(This is about 7.0-BETA3 amd64)

Can someone explain to someone who isn't a VM guru exactly what 
vm.pmap.shpgperproc does?

My understanding of how the VM system works isn't great but my 
understanding is, if you have a process that's malloc'ed, say, 100MB of 
memory, then it forks, and the child modifies 5MB of it, the total memory 
usage is really 105MB instead of 200MB because unmodified pages used by 
both copies are kept as just a single copy; modified pages are copied on 
write and eventually cause the processes to grow.

For example, having mod_perl2 preload and precompile all scripts, instead 
of doing it on their first hit, should save a ton of memory because the 
children will share the memory from the parent: 
http://www.perl.com/pub/a/2002/07/30/mod_perl.html is an old article 
explaining how I think it works.

On a quad-core box with about 200 mod_perl2 Apache processes, and about 
2000 other much smaller Apache processes with the mod_perl shut off, I get 
"Aproaching the limit on PV entries, consider increasing either the 
vm.pmap.shpgperproc or the vm.pmap.pv_entry_max sysctl" a few times on the 
console after a reboot.  Raising vm.pmap.shpgperproc from the default 200 
up to 500 reduces these but doesn't eliminate them.

My question is, does vm.pmap.shpgperproc affect how much of the parent's 
memory a forked child can share, or does it just affect things like SysV 
SHM where a proces has to explicitly request a shared pool of memory for 
IPC, or is it something else entirely?  Because if it's the former, the 
default of 200 would mean only 800K memory shared between mod_perl 
processes which for this situation is absurdly low -- so I hope I'm wrong 
on how that works. :)

Also, what's the danger of setting it too high, on an amd64 system with 4 
GB memory (soon to be 6 GB), given the process counts above?  I'm 
attempting to run with it set to 2048 right now and not noticing any ill 
effects.  On amd64 it appears to be tunable at runtime, vs i386 where you 
have to tweak PMAP_SHPGPERPROC in the kernel config -- very handy.

I have found some old discussions about PMAP_SHPGPERPROC on Google but 
none of the ones I read really get specific enough for me; they all just 
seem to say "keep raising it til the warnings on the console go away" :)

Side question: Anyone know of a way to profile Apache memory usage on a 
per-module basis?

More information about the freebsd-current mailing list