Re: The cron problem and a solution

[George Bonser <grep@oriole.sbay.org>]

> 
> Nicing a job is not enough.  Suppose the job is IO intensive (like
> makewhatis) and the user is doing something IO intensive.  The user
> task gets priority and issues an IO request.  The CPU is now free so
> makewhatis is allowed to run and will issue an IO request.  Both jobs
> will be very slow because the disk heads will be constantly moving
> from where the foreground job is reading to where the makewhatis is
> rezading.  So the best solution is trying to avoiding starting the
> cron job until there is no other activity.

That is going to happen regardless.  Imagine that the system looks at the load
and sees that it is low and kicks off a process to rebuild the man database.
Just then, the user attempts to do something but the system is performace is
poor because of the process that started just BEFORE the user tried to do
something.  

What I am getting at is that looking at the current load might not mean
anything because we can not predict what demands will be placed on the system
in the immediate future. Also, system load is not a reliable indicator of I/O
activity. A rather I/O intensive procedure may not result in a high load level.
The load level as displayed in the uptime command is only number of processes
waiting for CPU service averaged over time. A very I/O intensive process may
not result in a high load level with a bus-mastering SCSI controller and a
system with a small number of total processes running. On the other hand, a
process can use significant CPU time with relatively little I/O activity.

Trying to guess when the user will not be using the system is difficult. My
suggestion is to perform these processes in such a way as to interfere as
little as possible (some interference is going to be required and must be
tolerated) with the completion of interactive user processes.

> 
> Another case where nicing falls short is in case we are short of
> memory.

But what alternative do we have?  Simply wait for the system load to be low and
HOPE it stays that way? Not likely given the nature of the use of the system.
If it is likely to remain unused for any period of time, the user will likely
switch it off. Some combination of both methods is probably in order.

1) Roll logs on start up or shut down.  This does not take very long.
2) Rebuild man database in the background (niced) after package installation or
   deletion.
3) Other housekeeping activities submitted as batches to at or cron (at being
   better because you can specify the execution time as a delta from now).

> I don't like it.  People will not want to wait 10 minutes until the
> computer shuts down properly.

Some activities only need to be done if certain conditions are met. Examples
.. has a day or week gone by since the function was last done?  Have any
packages been added or removed? &c.  We can be smart about deciding when
something needs doing. 


George Bonser 
If NT is the answer, you didn't understand the question. (NOTE: Stolen sig)
http://www.debian.org
Debian/GNU Linux ... the maintainable operating system.