| UIS used a lot of PAGEDYN and NPAGEDYN resources, which is probably why
your customer started there. DECwindows operates in a vastly different
manner, keeping most of its resources in process virtual memory. It is
difficult to provide tuning suggestions without some evidence of where
bottlenecks exist on that specific system.
With DECwindows it is often true that more memory will help. If indeed
physical memory is severely limited, overall performance may be better
with BALSETCNT reduced to favor swapping rather than paging to release
memory from idle processes. I recently applied this technique on one
of our workstations with very favorable effect. Be sure to provide a
reasonably sized SWAPFILE...
|
| I've placed a few "loan of products" workstations at customer sites running
very predictable environments. e.g. A VS3100 running VAXset and a PASCAL
compiler and a VS3100 for documentation group running DECwrite (and maybe
DECdecision) and a VS3100 used simply for multiple terminal sessions on
remote VAXs.
These stations are being placed on desks of people who are not system managers
and don't know one "iota" about VPA or working sets or sysgen or authorize.
As well, we need to be able to get these up and running well in very short
order with little intervention if we are going to make a good impression.
I'd like to see a stock MODPARAMS.DAT and recommended AUTHORIZE account
quotas for each of the major environments that we will sell these machines
into. We would still need to do some tuning, but the first cut would be much
closer (and the first impression of a machine's performance is often the only
one that counts!)
-dale
|
| re .1/2
I have seen the method were you achive better performance by setting balance
set count down to force swapping. I don't buy into that as many DECW
applications 'tick'. One to many of these terrorist icons in the box and you
thrash around. It is also a poor solution for shared, large memory, server
machines.
So, I went on an adventure...
Here's a given. The best you can do in VMS is map every page in the process
the instant you activate the image. The only problem is nobody has that much
memory, and disks aren't that fast yet.
So I'll compromise. For me, opening a window indicates a intense desire to
interact with THAT window NOW. The rest of the system can ooze out the air
vents for all I care. Therefor, my demand pattern assumption is:
- I start only what I need.
- Only when I need it. (Limit Autostart.)
- I keep it in the box only if I'll reuse it today.
- When I'm done with it, I close it.
For background I use a VS3100 Color, w/2 RZ23's, 1 RZ55, 8MB, serving as a
VMS 5.2 LAVC boot node. I have one 30000 block pagefile on each of the
RZ23's, run my user accounts off one of the RZ23's and reserve the RZ55 for
VMS and applications. I normally have 2 or 3 DECTerm windows along with a
DECdecision, DECwrite, VAX Notes, VMS Mail, and Banner running at once. Yes,
it even runs DECdesign in the mix with acceptable behavior. The system will
handle some odd 5+ additional windows before it starts to 'hit the wall'.
Ok. Now that were clear on what I want my system to do, YOU have to be willing
to edit SYS$STARTUP:DECW$CHECK_PARAMS.COM and comment out the hard check on
the SWPOUTPGCNT. Somewhere is a note about a marketing paper explaining/just-
ifying why this check exists. As you can probably tell, I don't buy into
enforcing performance parameters either. At best, I think it ought to be a
warning.
The concept behind the sysgen parameters is simple. Get the window to its
WSquota as quickly as possible, and keep a modest free/modified list. The
free list is only there so 'ticking' applications can recover from forced
SWPOUTPGCNT working sets without hitting the disk. Beware changing
MSCP_BUFFERS, I happen to be booting only one other workstation over the LAVC.
As with all sysgen stories you travel at your own risk...
MAXPROCESSCNT 52 FREELIM 47
BALSETCNT 50 FREEGOAL 750
WSMAX 8192 GROWLIM 100
VIRTUALPAGECNT 50000 BORROWLIM 100
MPW_WRTCLUSTER 120
PFCDEFAULT 32 MPW_HILIMIT 655
PFRATL 1 MPW_LOLIMIT 81
PFRATH 0 MPW_IOLIMIT 2
AWSTIME 1 MPW_THRESH 200
QUANTUM 2 MPW_WAITLIMIT 655
WSINC 8192 MPW_LOWAITLIMIT 500
WSDEC 512 MSCP_BUFFERS 32
SWPOUTPGCNT 135
LONGWAIT 0
DORMANTWAIT 0
The /WSDEF, /WSQUO, and /WSEXT in AUTHORIZE are most important and depend on
how many windows you typically use. My system allows a single window to grow
comfortably to the area of about 5500 pages. At that setting every other
process on the system will have been blown to SWPOUTPGCNT or swapped out. I
have settled on /WSDEF=(about 50% of WSQUO, but not less than 1000),
/WSQUO=4000, and /WSEXT=(sysgen param WSMAX). This allows a fast switch when
working in 2 or 3 windows at the same time. Lower WSQUO to keep more
applications alive at once, at the risk of slowing the speed some of them
will start.
This concept carries to large memory "server" machines as well.
Happy windowing,
Bill K.
|
| re .-1
My fingers have 10 little minds of their own. In the last note I said VMS 5.2,
when it should have read 5.3.
Also, and more importantly, I said PFRATL should be '1' when it should be zero.
Setting PFRATL to anything but zero would wreak absolute havoc within all
of about 10 seconds after you 'write active'. I'm sorry if you went off
and did this one to yourself!
Ok. Now the suggestion. It was brought to my attention that if I really
didn't care if the rest of the system 'oozed out the vents' then I should
set MPW_WAITLIMIT and MPW_LOWAITLIMIT to something like 8192 (infinity)
also.
Bill K.
|