From owner-freebsd-hackers Tue Jan 26 14:56:20 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id OAA14028 for freebsd-hackers-outgoing; Tue, 26 Jan 1999 14:56:20 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from apollo.backplane.com (apollo.backplane.com [209.157.86.2]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id OAA14017 for ; Tue, 26 Jan 1999 14:56:17 -0800 (PST) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.2/8.9.1) id OAA22114; Tue, 26 Jan 1999 14:56:10 -0800 (PST) (envelope-from dillon) Date: Tue, 26 Jan 1999 14:56:10 -0800 (PST) From: Matthew Dillon Message-Id: <199901262256.OAA22114@apollo.backplane.com> To: Wes Peters Cc: Kevin Day , hackers@FreeBSD.ORG Subject: Re: High Load cron patches - comments? References: <199901261853.MAA15095@home.dragondata.com> <36AE3981.C3F59FF1@softweyr.com> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG :> hwoever for me this wasn't effective, as the user's jobs tend to hang around :> for a long time. :> :> Can I get comments/suggestions about this? : :Commenting on the approach, rather than your implemenation: : :Wouldn't it be cleaner to limit it by load average rather than number of :jobs? This would tend to allow small, one-shot cron entries that really :don't eat a lot of resources to continue running on time, while saving :the machine from the monster processes. : :-- : Where am I, and what am I doing in this handbasket? : :Wes Peters +1.801.915.2061 :Softweyr LLC wes@softweyr.com No, this won't work at all. I have direct experience trying to regulate things by load average. The problem is that the load average takes too long to ramp up and ramp down. By the time it's ramped up, cron may have already forked a thousand jobs. Plus if the system gets loaded on its own, you risk an effective disablement of cron alltogether. We had lots of problems like this with sendmail 4 years ago at BEST. There is literally no way to win if you try to regulate the system based on the load average. This is, in fact, what prompted me to submit a patch to Eric Allman a couple of years ago to make sendmail's MaxDaemonChildren option apply to queue runs as well as server forks. Sendmail's load average-baesd regulation doesn't work worth beans, but putting a max limit on the number of forked children and queue-running children solved nearly all of sendmail's load-related problems. -Matt Matthew Dillon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message