Date: Wed, 14 Jul 1999 21:37:08 -0700 (PDT) From: Matthew Dillon <dillon@apollo.backplane.com> To: lyndon@orthanc.ab.ca Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: Replacement for grep(1) (part 2) Message-ID: <199907150437.VAA06766@apollo.backplane.com> References: <199907141755.LAA05231@orthanc.ab.ca>
next in thread | previous in thread | raw e-mail | index | archive | help
:> I mean, jeeze, the reservation for the program stack alone would eat
:> up all your available swap space! What is a reasonable stack size? The
:> system defaults to 8MB. Do we rewrite every program to specify its own
:> stack size? How do we account for architectural differences?
:
:The alternative is to rewrite every program that assumes the semantics
:of malloc() are being followed. The problem I have as an applications
:writer is that I tend to believe malloc. To pick a specific example,
:our IMAP client takes steps to ensure it won't run out of memory in
:critical sections. We maintain a "rainy day" pool block of memory. If
:...
:--lyndon
We just put a cap on the number of imap clients we allow running
at any given moment... say, a few hundred. Not only does it
work just dandy, it also prevents the machine from overloading
and gives us a nice "you may want to look into this" alarm.
We do the same thing with sendmail, popper, the web server,
named, and every other service which can be forked.
This also prevents one subsystem from overly interfering with
another. For example, if popper saturates it does not overly
interfere with imapd operation.
The limit is set to around 3x the monday peak load, and
sufficient swap is configured to deal with it should the limit
be hit.
Problem solved. No fancy modifications required. If any of
these subsystems actually ever got close to using all available
swap, the other subsystems would be up the creek anyway so, really,
it doesn't make much sense hacking the source to allow the subsystem
to run into the wall anyway.
-Matt
Matthew Dillon
<dillon@backplane.com>
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199907150437.VAA06766>