A problem with UTS 2.0.1

[Bob Brankley]

I have been running UTS 2.0.1 since March and have been very happy
with it.  I have had a couple of small problems with UTS 2.0.1, but the
problems were not major and the UTS Support Center has been very
helpful in resolving them.  One of the current problems I am pursuing
concerns excessive paging under high CPU use.  The UTS Support Center
is currently working on the problem, but I was wondering if anybody
had seen this problem before.  Here is my system configuration:

System configuration:
Dual processor IBM 4381 with 16 MB of main memory, running VM/XA 2.1.
UTS runs as a guest under VM and is isolated to run only on the second
processor.  UTS is configured to be a 16 MB 370-type virtual machine.
Our disks are IBM 3380 DASD.  The system is rarely in use by more than
three users.


Problem:
According to the output of "sar," the number of real page faults
increases dramatically as UTS's CPU utilization approaches 70% or above.
These are real page faults generated by the UTS paging algorithms and NOT
VM/XA.  The number of virtual page faults (those caused by VM paging out
portions of UTS's pseudo-real storage) is extremely low during the same
period.  Another caveat is that UTS is paging despite the fact that he
has yet to fill what he perceives to be real storage.  In fact he has
typically only consumed 9 MB of the 16 MB of VM virtual storage he is
allocated.

I have isolated one application which seems to reliably cause the above
anomaly.  It is a makefile which uses vmpunch to assemble a set
of source files on an MVS guest machine running on the other processor.
Nightly accounting also causes heavy paging activity.  With a processor
load between 70-100%, the number of real page faults easily reaches
40-60 rpflt/s, rendering the virtual machine unusable.  The processor
time used by the wss_daemon goes through the roof as well.


Has anybody else observed this activity in UTS 2.0.1?  Could this be
a local mis-configuration issue which might easily be solved by applying
a few sticky bits?  Any other ideas?  I look forward to any discussion
on this topic.


Bob Brankley
System Analyst
AT&T Paradyne
brankley at pdn.paradyne.com