Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 26 Jan 1999 19:44:09 -0600 (CST)
From:      Kevin Day <toasty@home.dragondata.com>
To:        dillon@apollo.backplane.com (Matthew Dillon)
Cc:        hackers@FreeBSD.ORG
Subject:   Re: High Load cron patches - comments?
Message-ID:  <199901270144.TAA27675@home.dragondata.com>
In-Reply-To: <199901261917.LAA20783@apollo.backplane.com> from Matthew Dillon at "Jan 26, 1999 11:17:31 am"

next in thread | previous in thread | raw e-mail | index | archive | help
> :
> :No amount of pleading with my users did much good, since they were just
> :following a template given to them by the software they were using.
> 
>     We had similar problems at BEST, especially on older machines.  In fact,
>     and this is quite amusing ... we ran into a /proc simultanious-access
>     crashing bug precisely because 30 users were running botcheck scripts
>     every 10 minutes.  ( This was before we banned irc bots at BEST ).
> 
>     I finally gave up trying to get users to put crons in random minutes.
> 
>     My solution was:
> 
> 	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.

>     That solved the problem pretty much permanently.  Users tended to not
>     bother to change the crons back once I had edited them.
> 
>     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.

> 
>     Adding such uses to cron.deny and disabling their crontabs solves 
>     the problem.
> 
> :Can I get comments/suggestions about this?
> :
> :Kevin
> 
>     I like your idea.  I think it is a good idea.  I don't have time to
>     review the actual coding, though.
> 	

Ok... I'll keep playing with it and see if I can find any holes in my logic.

Kevin

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?199901270144.TAA27675>