From owner-freebsd-hackers Tue Jan 26 11:35:10 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id LAA19342 for freebsd-hackers-outgoing; Tue, 26 Jan 1999 11:35:10 -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 LAA19335 for ; Tue, 26 Jan 1999 11:35:07 -0800 (PST) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.2/8.9.1) id LAA20783; Tue, 26 Jan 1999 11:17:31 -0800 (PST) (envelope-from dillon) Date: Tue, 26 Jan 1999 11:17:31 -0800 (PST) From: Matthew Dillon Message-Id: <199901261917.LAA20783@apollo.backplane.com> To: Kevin Day Cc: hackers@FreeBSD.ORG Subject: Re: High Load cron patches - comments? References: <199901261853.MAA15095@home.dragondata.com> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG :I have a somewhat unusual setup, where I have a server that several hundred :customers use, that has all of /home over an nfs mount, and each customer :has quite a few cron jobs that they like to execute every ten minutes or so. : :The problem is that they all want to execute their cron jobs on a */10 :minute frequency, so on every minute ending in '0', I suddenly have cron :spawning off a few hundred processes, bringing the machine's load average :above 15.0, and saturating my NFS link for quite a while. : :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 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! 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. -Matt Matthew Dillon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message