If I created some of my static hashes and objects during the
PerlPostConfigHandler phase
and added them to either the configuration or log pools would that
help me keep
some of my memory shared, assuming I could get at either pool during
the PerlResponseHandler?
Am I confusing lifetime scope with shared memory? Are the two entwined?
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?
Would it allow me to reduce what I have set for
$Apache2::SizeLimit::MAX_UNSHARED_SIZE?
Thanks for all of the help,
-bop
On Nov 7, 2007, at 2:16 PM, Boysenberry Payne wrote:
Other than for callbacks on destruction of memory pools what is
APR::Pool useful for?
-bop
On Nov 7, 2007, at 1:56 PM, Perrin Harkins wrote:
Don't use Apache::SharedMem. It uses IPC::ShareLite, which is slow.
Does memcached or Cache::FastMap work with apache's shared memory
pool?
No, I don't think anyone has ever gotten that to work.
In this situation if its possible (which it should be for my own
modules) I would like
the package symbol table and contents to be loaded into the shared
server wide memory.
It's not possible. Perl allocates its own memory. You can't tell it
where it to put things. As discussed many times on the list,
copy-on-write helps with this on prefork systems. On threaded
systems, Perl shares the parsed code, but the symbol table is
duplicated for each thread, so it ends up using more memory than
prefork.
You can read more about copy-on-write in the mod_perl docs or at
modperlbook.org and there is more discussion about threads and how
they affect memory in the list archives.
- Perrin
