From: gordon@madmax.waterloo.edu (Gordon R. Strachan)
Subject: Re: Very slow start-up for VUE
Organization: University of Waterloo
Date: Fri, 10 Apr 1992 13:32:36 GMT

In article <1992Apr9.213130@IASTATE.EDU> cupples@IASTATE.EDU (Robert L Cupples) writes:
>
>We've been experiencing similiar problems with our 730.  This happens
>only when someone leaves a large program running in the background under
>nohup.  This might not be the problem of the original poster, but I would
>like to ask some advice about it.
>
>Again, the copyright information stays up for several minutes and then
>is very slow at "drawing" my windows, control panel, and xhpcalc.  The
>disk drive seems to spend a great deal of time running (swapping to disk?).
>The "load average?" is several bars, decays rather rapidly, and then either
>everything is back to normal, or any change in the X-windows (size, location,
>kill window, open new window) is redrawn very slowly.  Sometimes the mouse
>cursor quits moving or disappears briefly.
>
>Starting the background job at a different priority does help somewhat, but
>not always enough.  What would also help would be someway to change the priority
>of the background process while it is running.  I have not yet
>found a way to "renice" the job.

You can renice with the system call
syscall(SYS_SETPRIORITY, which, who, niceval) but, as you said it really
doesn't help in this situation.  You can run that process at the lowest
priority and the system will still thrash.  If you stop the job with a
SIGSTOP then you will be okay but it really doesn't solve the problem either.
I really don't know why the 700's get hit so hard with thrashing (at least
more so than the 300's) but I suspect it is due to the great difference in
processor speed versus disk speed.  With a really fast processor it is hard
to keep it 100% busy with high priority jobs so it goes an runs the lower
priority which forces them to be swapped back in.  Of course, I still insist
that the swapping in 8.0 is completely broken, especially compared to 7.0.
The O/S on the 730 in particular is very agressive in swapping out pages
that really don't need to be paged out.  With our system we had 16 Meg of
memory.  After the O/S kicked in and allocated its I/O buffers etc you
had a little over 10 Meg for user space.  If we then launched a process with
a working set size of 8 Meg and made sure that was the only thing running
(save the daemons) the system would thrash.  As near as I could tell vhand
kept throwing pages out to disk that were still needed by this process.  This
was a surprise to me because this particular processes walked through its
entire memory rather quickly and so I would have though every page would have
be marked often enough for vhand to leave alone but it didn't.  Even worse,
according to the man-pages there is no way to configure the vhand parameters.
I even considered killing vhand and just letting the swap daemon handle
everything but decided that probably wasn't too wise.

>
>The obvious answer that comes to my mind, is that the machine doesn't have
>enough ram and spends too much time swapping.  I do believe it came with
>16 meg.  Since money is always a problem at this university, telling my
>major professor what I think, rather than knowing the answer, might not be
>enough to convince him to loosen the purse strings (<= optimistic statement). 
>Does anybody have any experience with this?  Would another 16 meg make a
>large difference?  With it's speed, I find it hard to believe that it couldn't

Yes adding another 16 Meg makes a HUGE difference (well it did for me at least)
Basically with 16 Meg of memory you have enough to get the system up and
running and to use VUE and that's about it.  If you want to run any jobs
in the background which require any reasonable memory then you have to get
more memory.  Ever since we upgraded to 32 Meg we fine the system works
much better and haven't had any problems to date (well, not too true I think
HP shipped me bad ram because I've crashed twice since I installed it).
Bare in mind though that more ram doesn't really fix the problem it just
means you can run more and bigger programs until you hit the thrashing wall
again.

Gordon