httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dean Gaudet <dgau...@arctic.org>
Subject Re: worth fixing "read headers forever" issue?
Date Fri, 02 Jan 1998 21:17:36 GMT


On Fri, 2 Jan 1998, Brian Behlendorf wrote:

> >It's not at all unreasonable for us to do something with RLIMIT_CPU --
> >however we'd have to call setrlimit() and getrusage() once per hit to do
> >it right.  
> 
> Unless you were only concerned about overall CPU use by a particular child.

But that's not good... you could end up in the middle of an otherwise
normal request and run out of cpu time and send back a bogus message to
the client.

> Hmm - what about being able to control child spawning by specifying the
> amount of CPU time a particular child can take up, rather than
> MaxRequestsPerChild?  When you go over the limit, finish the current
> request then die.

Child suicide should be avoided, in fact our default MaxRequestsPerChild
of 30 is a joke.  All my benchmarking shows huge performance increases
when I raise this to more reasonable things like 100000, in fact I'd
prefer it to be infinite by default. 

I think the only folks that need such low maximums are the mod_perl folks
and folks with broken C libraries.  I bet with the "HostnameLookups off" 
tweak we'll stop triggering whatever lame bug it is in the Solaris libc
that resulted in the comment in conf/httpd.conf-dist.  There's still the
accept() memory leak, but for us this is a minor issue because it's caused
by signals and the only signals we take at accept() cause the child to
exit anyhow.  I could be wrong. 

Child suicide invalidates a bunch of data in the CPUs L1 and L2 caches, it
costs you CPU time to kill the old child, spawn a new child and let the
CPU reload its caches.  Long living children are the ones that we should
"coddle" and keep around.  Actually we'd rather keep around the busy
children, because they're in the caches... but I haven't seen/figured out
a good heuristic for that which works portably. 

Dean



Mime
View raw message