Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 28 Jan 1999 18:51:36 -0000 (GMT)
From:      Duncan Barclay <dmlb@ragnet.demon.co.uk>
To:        Matthew Dillon <dillon@apollo.backplane.com>
Cc:        hackers@FreeBSD.ORG, wes@softweyr.com, dyson@iquest.net, Kevin Day <toasty@home.dragondata.com>
Subject:   Re: High Load cron patches - comments?
Message-ID:  <XFMail.990128185136.dmlb@computer.my.domain>
In-Reply-To: <199901281817.KAA09891@apollo.backplane.com>

next in thread | previous in thread | raw e-mail | index | archive | help

On 28-Jan-99 Matthew Dillon wrote:
> 
>     I think a rate limited cron is a good solution, but I would also ( if you
>     haven't already ) supply a max-parallel-jobs option.  Increasing the
>     fork rate works to a degree, but you also have to make sure that cron
>     (A) cannot kill the machine, and (B) cannot fall into a fork cascade 
>     failure by overloading the machine so much that the jobs can't be
>     retired faster then new jobs are queued.
> 
>     So, for example, you might have a feedback parameter X but you should
>     also have an absolute limit Y, which you set relatively high. 

[snipped example]

>     In effect, your feedback parameter solves your NFS burstiness problem
>     under 'normal' load conditions and the absolute limit handles the more 
>     severe noon & midnight cases.
> 
>                                       -Matt


Speaking as an electronic engineer who uses feedback in circuits all the
time:

One thing to watch out for when you have rate-feedback and a limiter is
essentially designing a unstable or chaotic system. The limit acts as a
non-linearity in the system feedback function which is usually a bad thing.
Non-linearities will at best open the feedback loop and at worst cause it to
thrash around like a mad thing. Similarly, if you have too many feedback loops
(i.e. rate and number) the feedback can start to oscillate...

These effects may not be visible because the time constants of the feedback
systems are likely to be longer than the process creation rate.

All of these are testable but it is easy to generate an unstable system by
changing time constants.

Duncan

---
________________________________________________________________________
Duncan Barclay          | God smiles upon the little children,
dmlb@ragnet.demon.co.uk | the alcoholics, and the permanently stoned.
________________________________________________________________________

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?XFMail.990128185136.dmlb>