Re: Niced cron jobs
On Sun, Jun 27, 1999 at 02:37:18PM -0400, Adam Di Carlo wrote:
> Craig's point, which I agree with, is that niceing cron jobs by
> default is of questionable benefit for 80%,
Agreed. Because nobody else had, I ran a few numbers on an otherwise
unloaded system. I compiled a kernel while running the slocate cron job
(creates an index of the filesystem) at the default priority, and at
niceness 10. The compile finished about 8% sooner with the nice slocate.
Interactive performance was fine in both cases. If most cron jobs are
disk-intensive like slocate's, it's not at all clear that nice buys much for
joe user.
This is of course not a conclusive test. It was run on a fast machine and
the CPU was never maxed out. But does anyone have more convincing evidence
or arguments?
> and definately harmful for
> the, well, say, 5% of the servers out there that operate on high load.
To repeat what I wrote before: For every "heavily-loaded server" on which
nice causes overlapping cron jobs, I'll bet I can find one on which non-nice
cron jobs have an unacceptable performance impact, and another on which
non-niced cron jobs overlap. This is an educated guess, but nobody's
disputed it.
Moreover, isn't it obvious that on such a machine, the number, frequency,
and parameters of the cron jobs each matter at least as much as the nice
value, and that changing the niceness is among the easiest steps an
administrator will have to take to analyze and solve the problem (whatever
it is), if indeed he finds it contributes to the problem? (This is why I
find a "niceness configuration file" silly, if harmless.)
Loaded systems are a wash on this issue.
In the end, I don't have any strong position (I would just nice 'em if it
were up to me), but I hope the decision will be made on better data and
reasoning than has been presented so far.
Andrew
Reply to: