From owner-freebsd-hackers Thu Jan 28 13:03:55 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id NAA15201 for freebsd-hackers-outgoing; Thu, 28 Jan 1999 13:03:55 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from post.mail.demon.net (finch-post-10.mail.demon.net [194.217.242.38]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id NAA15188 for ; Thu, 28 Jan 1999 13:03:50 -0800 (PST) (envelope-from dmlb@ragnet.demon.co.uk) Received: from [158.152.46.40] (helo=ragnet.demon.co.uk) by post.mail.demon.net with smtp (Exim 2.10 #1) id 105ybL-0004Nc-00; Thu, 28 Jan 1999 21:03:48 +0000 Received: from dmlb by ragnet.demon.co.uk with local (Exim 1.82 #1) id 105wXQ-0001ry-00; Thu, 28 Jan 1999 18:51:36 +0000 Message-ID: X-Mailer: XFMail 1.3 [p0] on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <199901281817.KAA09891@apollo.backplane.com> Date: Thu, 28 Jan 1999 18:51:36 -0000 (GMT) From: Duncan Barclay To: Matthew Dillon Subject: Re: High Load cron patches - comments? Cc: hackers@FreeBSD.ORG, wes@softweyr.com, dyson@iquest.net, Kevin Day Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG 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