Path: utzoo!attcan!uunet!wuarchive!zaphod.mps.ohio-state.edu!sdd.hp.com!hplabs!hpda!hpcuhc!mck
From: mck@hpcuhc.HP.COM (Doug McKenzie)
Newsgroups: comp.sys.hp
Subject: Re: HP 9000/835 memory usage (System crawling ...)
Message-ID: <530019@hpcuhc.HP.COM>
Date: 20 Sep 90 19:19:08 GMT
References: <7679@ucdavis.ucdavis.edu>
Organization: Hewlett Packard, Cupertino
Lines: 80

> when snail mode is entered, I notice the following:
> 
> 1 - Free memory goes from its normal amount of 1 mb or so to 6 mb free
>      out of 16mb; corresponding to this, user memory utilization goes
>      from its normal level of 75% or so to 30%.
> 
> 2 - Idle CPU time goes to 80%
> 
> 3 - 1 minute load average shoots up to 14 or 15, instead of its
>     normal state of < 2.
> 
> 4 - Swap space utilization remains around 25%  
> 
> On the "V" screen of monitor (Virtual memory status):
> 
>    On each screen update, the "processes swapped in" and "processes
>    swapped out" BOTH show 10 or 15.  Normally they show 0.
> 
> Background information on our system:
>    HP-835 with 16 Mb, 129 Mb of swap, running HP-UX 7.0

All the above suggest swapping in/out is causing the performance slowdown.
"1" shows that some memory resident processes have been swapped out.  "2"
shows that the system is busy swapping stuff to disk, "3" means that
whatever you're doing is generating a need for more memory (15 processes
worth), and the V screen confirms swapping is going on.  Utilization of swap
space ("4") is not really relevant, since swap is allocated on exec, not
based on a working set, or other dynamic parameter.  (Of course if a process
allocates more memory, it'll show up in swap allocation.)

Swapping is basically a last resort effort to keep the system running, when
either free memory is very low, or I/O bandwidth (disk reads/writes) are
excessive.  For a properly sized and configured system, the "pageout" process
should take care of memory needs during typical usage.  With "monitor" you
can see this happening, and when pageout can't keep up with demands.  Pageout
will run when 1/4 or less of usable memory is free, and speed up as needed,
until it maxes out at 200 pages scanned per second (if *my* memory serves.)
If that's not enough, process(es) are swapped out based on complex, pretty
intelligent choices, until things are OK again.  All, or virtually all pages
of a process are swapped out when the process is swapped out.  A minimal
number of pages are swapped back in when the proc is brought in again.
Robert mentioned that an entire process's "environment" has to be swapped
in.  I'm not sure what was meant, but neither all the code, nor all the data
pages are typically swapped in.  The user area is swapped in/out with the
proc's pages, but is only about 2K bytes.

> I hope the answer is not simply "buy more memory".

It may be that disk I/O is causing the swapping, if many processes are
reading/writing simultaneously.  I'd guess more likely your memory is
causing the swaps, or both I/O and memory.

X is certainly a hog.  My (diskless) 330 was a slug with 4 megs, OK with 8,
running X.  So your other processes are limited to the remaining 8 MB.  I'd
guess inadequate memory is causing swapping.  A load average of 15?  Yikes,
this is a lot of runnable processes.  How big are they?  Why are they all
trying to run at once?  Does the X startup start the application processes
also?  Could some of these be delayed or "niced", so they weren't all trying
to go at once?  This should help a *transient* snail-mode, if it's the
simultaneity (sp?) of startup (rather than the "cruising" needs or the
needed processes) that's the problem.  If the process(es) make significant
startup efforts and then sleep, this would bog down other processes's
interactive response unnecessarily, during the startup.

So I'd suggest examining how your X startup scene behaves, using monitor,
and tweak it to be a little nicer to system resources.  Stick some "sleep
300"'s in X's startup, and trade-off getting windows up quick, for
prevention of swapping.

Hope my meandering helps.

> $10,000 + for HP 800 memory makes that a much more painful
> alternative.  Because of this, we tend to expand by other workstations
> instead!

Ouch.

Doug McKenzie
S800 HP-UX Support
mck@hpda.hp.com  OR  ...hplabs!hpda!mck