OT: Unix stutter

[Bill Vermillion]

On Sat, Sep 11 17:38  Fairlight said 'Who you talkin' to? You talkin'
to Fairlight?  I didn't do nuttin'.  I said: 

> When asked his whereabouts on Sat, Sep 11, 2004 at 03:51:32PM -0400,
> Bill Vermillion took the fifth, drank it, and then slurred:
> > 
> > >From the command line just do this:

> > sar -o /tmp/sar 10 10

> > The first 10 is how many seconds to wait before you run it again.
> > The second 10 is how many times you wish it to run.  The output
> > goes into the file 'sar' in tmp.  

> > This is good to catch those thing that happen for a minute or so
> > and go away.

> Bill, if the system is non-responsive enough that it won't even
> accept TTY input, what makes you think it will spawn a new
> process, or that even a running process would be granted CPU
> slices during the "dead" time? This didn't make any more sense
> to me the second time it came up for precisely that reason. Am
> I missing something about sar?

But he did say it went in fit's and spurts.  So if the above was
made as a script then it could probably start even though you may
not know it for awhile.  As long as the system isn't totally dead
you can often get things from it if you are patient.

As in the first reply I've thought systems were disconnected and
hit CR many times with no response, and then a bit later I get
a line of #'s down the screen.

Just because it is not echoing doesn't mean it is not capturing and
accepting the keystrokes to act on them later.

And since the it's a time-sharing system if things get really slow
the processes will eventually get acted upon as whatever the big
things slowing things down is.

A long time ago when fpTransfer was basically quite slow the only
way to get more data was to run multiple parallel transfers.

I had about 4 transfers running, and started doing something else
and all of a sudden the system seemed dead.  [AT&T 3B2].  But I
could tell it was still running. It appeared dead at first glance
but it was not.  It was thrashing more than the snakes in the pit
in the Indiana Jones movie.

But I waited it out.  And about 20 minutes later it finished one
process that freed up enough resources to make it start responding
again.

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.

If it's running slow, and you don't have the sar command as a
script just carefully type it in blindly.  When the system gets
around to accepting what is in the keyboard queue it would start
running.  While it may not log the peak moment it surely should
show things right afterward as systems normally don't go from 
extreme overload to light load instantly but will more typically
ramp down.

Bill
-- 
Bill Vermillion - bv @ wjv . com