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 00:19:48 GMT
You can't implement cputime rlimit entirely in user code.  You need
support from the system -- either in terms of an actual setrlimit() call,
in terms of a virtual itimer, or in terms of getrusage()... and if you've
got one of the latter two you probably also have resource limits. 

If NT doesn't have that stuff then tough.  They probably put it in 5.0
though, since they had to put in pretty much all of the unix functionality
that 25+ years of experience has said is a Good Thing. 

rlimits pose problems because of how you're told that you've run over
them.

RLIMIT_DATA, RLIMIT_AS -- depending on the unix you'll either get a
SIGSEGV/SIGBUG or a malloc() failure.  If you get a malloc() failure you
at least have the opportunity to report it.  But decoding a SIGBUS failure
is a real pain.  Single Unix doesn't mention the sigsegv thing, but it
does happen in reality, Linux and IRIX for example can easily cause this
due to optimistic memory allocation.

RLIMIT_STACK -- According to single unix you'll get a SIGSEGV.  That's
quite humourous, how is it going to set up your stack frame when you've
gone over the limit? heh.

RLIMIT_CPU -- you're supposed to get a SIGXCPU.  But single unix doesn't
mention what happens if you continue processing on receipt of SIGXCPU. 
Under Linux it sends you SIGXCPU every second after you're above the
limit. 

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.  There's nothing for us to decode on a SIGXCPU, we just
terminate the request in progress like timeout() does.

I doubt we should bother with RLIMIT_DATA and RLIMIT_AS.  I think we
should implement my pool counting suggestion instead... it saves syscalls
and lets us control when we barf out a lot easier.  Otherwise we'd have to
be able to distinguish between regular SIGSEGVs and SIGSEGVs caused by
optimistic allocation on unixes supporting that.

Dean

On Thu, 1 Jan 1998, Brian Behlendorf wrote:

> At 11:04 PM 12/31/97 -0700, Marc Slemko wrote:
> >I am doubtful that rlimits can be used usefully.
> 
> Why not?  Because rlimits aren't inherited by the children from the parent?
>  Because of x-platform variance in implementation?  
> 
> If rlimit isn't standardized widely enough yet, maybe instead of putting
> counters on every possible source of network input, we should emulate
> rlimit functionality inside Apache?  So we're controlling the memory and
> CPU consumption as a whole instead of within isolated areas.  Side benefit:
> we'd get resource limiting on platforms without any type of rlimit
> functionality, like NT.  Downside: marginal server bloat & overhead.
> 
> 	Brian
> 
> "All applications eventually expand their feature set until they can read
> mail."
> 
> 
> --=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--
> specialization is for insects				  brian@organic.com
> 


Mime
View raw message