[Unbound-users] unbound should probably manage other RLIMITs as well...

[Greg A. Woods]

At Thu, 29 Oct 2009 18:14:28 +0100, Florian Weimer <fw at deneb.enyo.de> wrote:
Subject: Re: [Unbound-users] unbound should probably manage other RLIMITs as	well...
> 
> On the other hand, most server software does NOT cope gracefully with
> resource allocation failures (there's a popular enterprise software
> stack which requires a server restart if a memory allocation failure
> occurs, for instance).

One should not aspire to meet just the lowest common denominator, and
certainly never to meet just the minimum of all alternatives.

BIND-8 and newer (i.e. since at least 1997) has had code to allow it set
various the RLIMIT values at startup, thus at least crudely imposing its
own controls upon itself.

That's sort of where I got the idea from, though here my initial idea
was to automatically make sure _all_ of the RLIMIT settings were not in
conflict with the other application-specific settings (i.e. in the same
way RLIMIT_NOFILE is currently adjusted to meet requirements,
RLIMIT_DATA and RLIMIT_STACK could also be automatically adjusted to
meet expected requirements).  Much better though would be the automatic
sizing of each tunable based on the current RLIMIT values set by the
system manager.  Though Unbound starts as root and can raise soft
limits, it's best to honour soft limits instead.

Indeed BIND-8 and newer have punted on the auto-sizing feature I
describe and they do behave badly if malloc() fails for whatever reason.
The BIND-9 documentation recommends against using RLIMIT datasize to
restrict the process size.


> (And for historic reasons, most DNS resolvers do not run with
> configured cache size limits.)

Well, BIND-9 has had cache size controls for well over 8 years now
(since 9.2.0, in official releases) -- I'm not sure what you mean by
"configured cache size limits" though.  I'd say only a very naive
sysadmin would let his caching resolvers run unbounded if at all
possible.


> I think those limits are only meaningful if you implement your own
> memory allocator.  You can't really know why you're approaching the
> process limit if all you do is call malloc to get heap blocks of
> varying lengths.  Operating systems and OS versions vary wildly.

Well, that's sort of what I was suggesting, though not in the sense of
replacing malloc(), but rather in being smart about how any memory
allocations which "grow" during runtime are managed such that a failure
is not fatal to the current operation, but instead simply causes reuse
of the LRU entry in the cache.

In fact what Wouter said in reply to me was that the next release will
actually try to behave much better when it runs out of memory
"unexpectedly".  Perhaps this behaviour can be perfected.

From an operations point of view one doesn't really care how big the
internal cache table is in bytes or in numbers of records, etc.  One
only cares that the cache stay within the bounds that make sense in the
context it is running in -- eg. so that it doesn't cause undue paging by
exceeding the total real-memory requirements of the whole system's
working page set.

In fact trying to meet operational requirements by having to calculate
how many bytes or records can safely be used by a cache or by each of a
set of caches is simply punting all the mundane calculations onto the
poor human operator.

The best way to meet this kind of operational requirement is to allow
the operator to tune the various resource limits applied to each process
and then to have the processes deal with those limits in the most
appropriate way.  For a process that leaks memory, the best action is to
die, and to hopefully be restarted.  For a process that intentionally
tries to use as much memory as is available for caching the best
approach to automatic tuning is to keep using memory until it runs out
and then reuse old entries, perhaps first freeing some additional old
entries to give headroom for other infrequent uses, and perhaps retrying
allocations periodically in case more resources are somehow made
available for the process.

-- 
						Greg A. Woods
						Planix, Inc.

<woods at planix.com>       +1 416 218 0099        http://www.planix.com/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 186 bytes
Desc: not available
URL: <http://lists.nlnetlabs.nl/pipermail/unbound-users/attachments/20091029/82736d6a/attachment.bin>