From owner-freebsd-hackers Tue Jan 26 18:09:06 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id SAA07208 for freebsd-hackers-outgoing; Tue, 26 Jan 1999 18:09:06 -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 SAA07191 for ; Tue, 26 Jan 1999 18:09:04 -0800 (PST) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.2/8.9.1) id SAA27656; Tue, 26 Jan 1999 18:08:58 -0800 (PST) (envelope-from dillon) Date: Tue, 26 Jan 1999 18:08:58 -0800 (PST) From: Matthew Dillon Message-Id: <199901270208.SAA27656@apollo.backplane.com> To: Kevin Day Cc: hackers@FreeBSD.ORG Subject: Re: High Load cron patches - comments? References: <199901270144.TAA27675@home.dragondata.com> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG :> :> vi /var/cron/tabs/* :> :> (manually mix up the minutes boundry for jobs that people ran at :> common points, like the top of the hour) :> :> kill the cron process :> restart it :> : :Tried that, but it doesn't stay fixed long enough, and we've had the :occasional disgruntled user put 5000 'find /'s in his crontab and watch the :machine explode. Woa! It's trivial to handle that situation, just give your users reasonable resource limits. All of BEST's users are placed in the 'standard' class. I then have a 'standard' entry in /etc/login.conf that gives them reasonable resource limits. It's possible that due to the way cron works, the resource limits is not being held to, but since cron runs a shell script and that runs the find, the resource limits should be held to. If not, we can fix cron. We occassionally had some idiot IRC hacker login and try to take down the machine from a shell prompt, usually with a fork attack, but since we've put in the resource limits they've never been able to do it. It's quite amusing. I gave rather generous resource limits -- normal users usually don't even know they are there. :> The other big problem is that some users just love running cron jobs :> once a minute, and sometimes when a machine gets loaded their jobs :> do not finish quickly enough and start building up. Weee! : :Yep. This patch seems to fix that. It queues jobs up. After it reaches a :huge number of queued jobs, it starts doubling the execution rate. Every :time you double the maximum number of allowable jobs in the queue, you :double the run speed. Very coarse, but it does self tune to catch up. : :Kevin -Matt Matthew Dillon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message