On Sat, Jun 26, 1999 at 09:18:48PM -0400, Adam Di Carlo wrote:
> Craig Sanders <cas@taz.net.au> writes:
>
> > it doesn't matter. if there is no CPU available for nice -10 tasks
>
> [Ahem -- you mean nice 10 because nice -10 is decided "mean"]
yep. i was thinking of the command line options ("nice -10" == "nice -n 10")
> > because the machine is too busy then there is no CPU available for nice
> > -9 or -8 or -1 either. because they hardly ever get any cpu cycles the
> > cron jobs stay around for ages, using memory, file handles, and other
> > resources.
>
> This doesn't jibe with what I know about the Linux (and SunOS 5)
> process schedulers. Even if a nice 0 (unnice) process is chewing up
> all the processor, nice'd processes *will* get CPU time (i.e., taking
> away CPU time from unnice processes). The only level of niceness
> which will *never* run without idle CPU is nice 20 (moby nice).
yes, this is true - the problem is that the niced cron jobs don't get
ENOUGH cpu to complete in a reasonable time. for some jobs - eg those
which use up a lot of memory, like processing apache or squid log files
or rebuilding the locate db - this can be disastrous.
> > at first glance, using nice seems like a good way of smoothing
> > out the load caused by cron but it is nowhere near that simple
> > in practice. on busy machines it creates a situation which gets
> > progressively worse until the machine runs out of resources and
> > dies....while on lightly loaded machines it makes hardly any
> > difference at all because the thrashing is disk activity, not CPU
> > load (certainly not enough difference to justify endangering server
> > boxes).
>
> I dunno -- my experience is different. I have definately seen
> heavily loaded machine stack up cron jobs this way, but generally the
> starvation is IO-starvation rather than CPU starvation.
ummm...that's what i said, isn't it?
CPU isn't really the problem. it's memory and IO - this is not only the
cause of the problem i'm describing, it is also the reason why nicing
the cron jobs doesn't actually gain you very much on workstations.
> For instance, in cases where the machine is swapping it's little
> brains out.
yep.
> I've tried it and it works fine for me. I agree, this should be a
> globally configurable option if possible, i.e.,:
>
> # cat /etc/cron.conf
> NICENESS=10
agreed. i have no objection at all to making it a configurable option.
in fact, i'm in favour of such things - the more we make it easy for
users to tweak and fine-tune their machines, the better.
my objection was only against forcing this behaviour on everyone.
i don't even care very much what the default is (although i prefer
NICENESS=0), as long as it's a conffile that persists across upgrades.
> Personally, I find the benefits are not all that great since cron jobs
> (i.e., from findutils) tend to be IO hogs and niceness doesn't
> particulary matter in terms of user responsiveness.
yes!!
you said a lot of what i've been trying to say, only better :)
craig
--
craig sanders