httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Greg Ames <grega...@remulak.net>
Subject Re: Suggested direction for fixing threaded mpm thread startup.
Date Fri, 20 Apr 2001 19:15:36 GMT
Ian Holsman wrote:
> 
> > -----Original Message-----
> > From: Greg Ames [mailto:gregames@remulak.net]

> >  One theme
> > I heard over and over was that heavyweight web workloads (database,
> > mod_perl) should be isolated from lightweight workloads in order to
> > minimize the memory footprint.  Makes a lot of sense to me.
> 
> aah.. but one of the great things about 2.0 is that memory footprint
> is not as much of an issue anymore, as the number of processes required
> are an order or 2 magnitudes lower.
> suddenly something which takes 20M of memory isn't much of an issue.
> 
> ..ian
> >

yeah, you're right.  My apologies to everyone for a lame argument. 
Yesterday was rough... 2.0 still won't build on OS/390...seg faults on
Linux at startup late yesterday afternoon (I still have 'em)...should
have slept on that one before hitting "send".  

After thinking about it more, the size of the file better not have any
significant impact on the memory footprint, or we're broken.  (btw, that
can actually happen with a naive filter design last time I checked.)  

We have a lot to learn on the care and feeding of threaded mpm's.  As
Ryan pointed out at ApacheCon, if you have buggy code which seg faults,
the impact will be much greated.  Memory leaks...hmmm...you probably
should start with MaxRequestsPerChild where you had it for 1.3 or
prefork.  How big will it scale?  dunno, maybe Bill's idea for shrinking
the scoreboard shared memory requirements will help remove a limit
here.  And we will need to minimize the mutex
contention...apr_atomic_add...apr_atomic_push/pop...

(back to the seg fault for now)

Greg

Mime
View raw message