OT: Unix stutter

[Bill Vermillion]

On Sun, Sep 12 02:15 , while impersonating an expert on the internet, 
John Esak sent this to stdout: 

> > Sar was being run by cron.  Normally the cron report would finish
> > in less than a minute past the hour, normally just a few seconds.
> >
> > This time the sar finished at 20 minutes after the hour.  I used to
> > keep a printout of that report to show people.  Average disk
> > wait was 8300 ms.  That means that instead of the typical 20ms
> > during light times, or 40ms during load time, each access to the
> > disk took 8 1/3 seconds.  But it finally finished.

> Along these lines... I was wondering if my "very_fast" tape
> backup (the dedicated 29360 and AIT3) isn't "too" fast...
> sucking up too many resources, too quickly, too often... etc.

The tape will wait if you don't have enough data coming to it.
That should be obvious if the tape stops and starts during backup.

And SCSI devices dont suck up resources as much as other things do.

> I suggested "nicing" the process to Frank at Microlite and he
> suggested we try to diagnose what was wrong first and he'd
> tell me how to nice it later. Since then I never went back
> to determine the syntax for nicing it. (I would guess just
> nicing it on the cron line might do it??, but he sounded as if
> there was another prescribed way.) In any case, I _am_ going
> to try that next if sar shows nothing... or maybe if sar shows
> something... :-)

I really don't think changeing the nice value will do much. It may
even cause the data to stop streaming and you don't want that.
Shoeshining will be harder on the drive and tape and will make your
backup take longer.  It's the stop/reverse/reposition/start -
that makes the drive work more and wears tapes faster.  

My take on tape backup is to get it going as fast as possible so it
is over as soon as possible.  And if you are doing this at night
are there users on the system then?   There shouldn't be, but if
there are, can you trust your backups?

Bill

Bill

-- 
Bill Vermillion - bv @ wjv . com