On Nov 7, 2007, at 5:04 PM, Perrin Harkins wrote:
On Nov 7, 2007 5:50 PM, Boysenberry Payne
<[EMAIL PROTECTED]> wrote:
If I created some of my static hashes and objects during the
PerlPostConfigHandler phase
and added them to either the configuration or log pools
You're missing the big picture. Adding perl objects to a shared
memory pool doesn't prevent them also needing to be in perl's own
allocated memory pool. All shared memory schemes with perl result in
MORE memory being used, because every process that accesses these
structures needs its own copy in its own process in addition to the
shared one. The shared memory one is a serialized perl structure,
created with something like Storable and perl has to turn it back into
a normal perl variable, in non-shared memory, in order to use it.
I get it now, thanks. I read up a little on COW and get its advantages
with virtual memory now. I guess it just requires a careful approach
to how I use the data, making changes more intentional or at least
know how much it will cost me.
You can't use less memory by sharing your perl data with user-level
shared memory techniques. Only copy-on-write can help with that.
I have classes that create singleton objects with lots of static
parts. Should I build these "constructs"
on server post config so they're already built in the child processes
as shared memory rather than
building them in each child, increasing the non-shared memory use?
Build them before the server forks if you use prefork.
That's what I was thinking after reading up on the server stages more.
I think it will give COW a better chance at doing what it was intended
to do that way, rather than automatically creating a lot of unshared
memory.
Would it allow me to reduce what I have set for
$Apache2::SizeLimit::MAX_UNSHARED_SIZE?
You shouldn't be using that at all unless you have Linux::Smaps
installed, but if you do, loading things before forking should improve
the amount of copy-on-write sharing.
I guess up until now I hadn't really considered "pre-loading" my
expensive
singletons on startup. It was suggested I use the
PerlPostConfigHandler phase
instead of my startup.pl file; so I guess I'll start there and see
how my processes
are effected.
$Apache2::SizeLimit::MAX_UNSHARED_SIZE doesn't do me much good
in my developing environment (OS X) but on our production server it
has worked
wonderful. No more server crashes due to no memory being available.
I've tweaked the MinSpareServers, MaxSpareServers, StartServers,
MaxClients,
MaxRequestsPerChild and that helped a bunch too.
Really there is so much going on I'm guessing eventually I'll need to
take a
different approach to how its all put together.
Thanks again,
-bop
