On Wed, 19 Apr 2000, Gerd Knops wrote:
> Stas Bekman wrote:
> > On Wed, 19 Apr 2000, Matt Carothers wrote:
> > > On Tue, 18 Apr 2000, Stas Bekman wrote:
> > >
> > > > Let's assume that you have two different sets of scripts/code
> > > > which have a little or nothing in common at all (different
> > > > modules, no base code sharing), the basic mod_perl process
> > > > before the code have been loaded of three Mbytes and each code
> > > > base adds ten Mbytes when loaded. Which makes each process 23Mb
> > > > in size when all the code gets loaded.
> > >
> > > Can't you share most of that 23mb between the processes by
> > > pre-loading the scripts/modules in your startup.pl? I'd say the
> > > main advantage of engineering dissimilar services as if they were
> > > on separate servers is scalability rather than memory use. When a
> > > site outgrows the hardware it's on, spreading it out to multiple
> > > machines requires a lot less ankle grabbing if it was designed
> > > that way to begin with. :)
> >
> > Geez, I always forget something :(
> >
> > You are right. I forgot to mention that this was a scenario for the
> > 23 Mb of unshared memory. I just wanted to give an example. Still
> > somehow I'm almost sure that there are servers where even with
> > sharing in place, the hypothetical scenario I've presented is quite
> > possible.
> >
> > Anyway, it's just another patent for squeezing some more juice from
> > your hardware without upgrading it.
> >
> > But, sure I'll add the correction about the sharing memory which
> > drastically changes the story :)
> >
> Actually in my experience the sharing of memory doesn't work as well
> as one would hope. While compiling perl allocates memory for code
> and data (variables) from the same memory pools, so code and
> variables are interlaced. Over the lifetime of a apache/mod_perl
> child a lot of memory pages are promoted from shared to unshared that
> contain mostly code and one or two variables... If someone with more
> knowledge of the perl internals were to change that, this would make
> a huge difference for mod_perl users and everybody else writing
> daemons in perl that spawn many children.
The Perl is a language that uses weak data types, i.e. you don't specify
variable size (type) like you do in the strong typed languages like C.
Therefore Perl uses heap memory by allocating memory on demand, rather
(unmodifiable) text and (modifiable) data memory pages, used by C. The
latter get allocated when the program is loaded into memory before it
starts to run, the former is allocated at the run-time.
On heap there is no separation for data and text pages, when you call
malloc it just allocates you a chunk you have asked for, this leads to the
case where the code (static in most cases) and the variables (dynamic)
land on the same memory pages.
I'm not sure this a very good explanation. Perl gurus are very welcome to
correct/improve my attempt to explain this.
But the main point is that that's how Perl is written, and I don't know
whether it can be changed.
______________________________________________________________________
Stas Bekman | JAm_pH -- Just Another mod_perl Hacker
http://stason.org/ | mod_perl Guide http://perl.apache.org/guide
mailto:[EMAIL PROTECTED] | http://perl.org http://stason.org/TULARC/
http://singlesheaven.com| http://perlmonth.com http://sourcegarden.org
----------------------------------------------------------------------
