STEINBERGER@KL.SRI.COM (Richard Steinberger) (06/21/88)
I have been reading the VMS Tuning Guide provided (free) from Touch Technol-
ogies (they market the Dynamic Load Balancer). The guide advises setting
MPW_HILIMIT (limit at which VMS starts writing pages from the modified
page list to disk. Sets a limit on the MP list size) at 15 percent of the
size of physical memory. The claim is made that the loss of physical
memory is more than compensated by a reduced paged I/O activity.
This seems like a rather large number for this sysgen parameter,
as DEC set the default at 500 pages. Has anyone followed Touch's advise?
Have you noticed a significant performance improvement? We run large
images, use large pagefiles and often encounter applications where much
paging is required even with large WSEXT values. I am thus trying to
evaluate whether increasing MPW_HILIMIT (and MPW_WAITLIMIT) is a
reasonable thing to do (our current setting is 655, physical memory
is 32768 pages and VMS already uses 4400+ of these).
Any comments or other rules of thumb?
-Ric Steinberger
steinberger@kl.sri.com
-------PSYDAVE@UBVMSC.CC.BUFFALO.EDU (Dave Straitiff) (06/21/88)
Dan Esbensen who wrote the Dynamic Load Balancer and the booklet
you are refering to gives a couple reasons for raising MPW_HILIMIT.
This parameter tells VMS to dump the whole modified page list into the
page file when this number is reached. That's a lot of I/O overhead.
Most of what Dan recommends is oriented towards systems with a large
amount of memory. You are not really losing any memory by setting
this high, but rather keeping more pages around in physical memory.
The modified page list is purged to replentish the free page list.
What you are doing is keeping a lot more modified pages around in the
hope that MPW_HILIMIT will be reached less often and therefore prevent
a number of hard page faults and I/Os. Many pages will be immediately
faulted back in. The idea is to make it a soft fault and not a hard one.
Testing a high number is not going to hurt you. It is worth giving a
try. As in all tuning, it is based on your applications and hardware.
This concept may or may not help in your environment. Too low of a value
will probably hurt though. Digital's numbers are not always a good
reference for what is a reasonable value. Many defaults are the same on
Vax 730s and 8800s, they are usually only best guesses. The new version
of autogen may correct some of this by collecting stats on a running CPU
for later tuning. As the title says, "Rules of Thumb", 15% may not
be the right number for you. Try it high, try it low, try it inbetween,
and see what it does for you. A last note is on MPW_WAITLIMIT, it should
be the same as MPW_HILIMIT. The system could deadlock if MPW_WAITLIMIT
was lower than MPW_HILIMIT.
Tuning can be a lot of fun and very informative, but it usually only
produces a marginal increase in performance. Poor or excessive tuning
may even hinder performance. I'd approach it with a little reservation.
Good Luck!
Dave...
============================================================================
David M. Straitiff Bitnet: PsyDave@UBvms
Computer Resource Manager Internet: PsyDave@UBvms.cc.buffalo.edu
Phone: (716)689-8093
Speech Research Laboratory
Department of Psychology
State University of New York at Buffalo
Buffalo, New York 14260
============================================================================OBERMAN@ICDC.LLNL.GOV ("Kevin Oberman, LLNL, 422-6955, L-156", 415) (06/21/88)
>I have been reading the VMS Tuning Guide provided (free) from Touch Technol- >ogies (they market the Dynamic Load Balancer). The guide advises setting >MPW_HILIMIT (limit at which VMS starts writing pages from the modified page >list to disk. Sets a limit on the MP list size) at 15 percent of the size of >physical memory. The claim is made that the loss of physical memory is more >than compensated by a reduced paged I/O activity. > >This seems like a rather large number for this sysgen parameter, as DEC set the >default at 500 pages. Has anyone followed Touch's advise? Have you noticed a >significant performance improvement? We run large images, use large pagefiles >and often encounter applications where much paging is required even with large >WSEXT values. I am thus trying to evaluate whether increasing MPW_HILIMIT (and >MPW_WAITLIMIT) is a reasonable thing to do (our current setting is 655, >physical memory is 32768 pages and VMS already uses 4400+ of these). Any >comments or other rules of thumb? 15% is about whrer we keep our MPW_HILIMIT. We did this to reduce pagging I/O activity, and it was very effective. The Modified Page List is a cache of pages released from working sets which are different from the page originally loaded from disk. If the pages have not been actually written to disk, they may be restored to the original working set if needed. We do ray-tracing and as a result move through large arrays in a nearly random pattern. This results in trmendous paging activity. An enlarged MPW greatly reduces the disk activity. Not to mention speding up the execution of the code. Since VMS will force a modified page write if the free list gets too small, increasing the MPW_HILIMIT seemed a reasonably painless method of decreasing paging I/O at only a moderate impact if memory ran low. And since we have a lot of memory, that is unlikely. R. Kevin Oberman Lawrence Livermore National Laboratory Internet: oberman@icdc.llnl.gov (415) 422-6955 Disclaimer: Don't take this too seriously. I just like to improve my typing and probably don't really know anything useful about anything.
kenw%noah.arc.CDN@ean.ubc.ca (Ken Wallewein) (06/26/88)
I've been following this discussion, and it's encouraged me to do a bit of
digging.
We've been running memory-rich in the past, althought that's changing.
MPW_HILIMIT is at 6000, and MPW_LOLIMIT at 3000.
However, one thing is bothering me: I can't seem to get the modified list
above about 600 pages, and it's usually somewhere between 50 and 300. With
the free list running around 16,000 blocks, it just doesn't seem right.
Here's an edited SYSGEN listing of what I believe are the pertinent
parameters. Can anybody see anything that could be a problem? I'm baffled.
Parameters in use: Active
Parameter Name Current Default Minimum Maximum Unit Dynamic
-------------- ------- ------- ------- ------- ---- -------
MPW_WRTCLUSTER 96 96 16 120 Pages
MPW_HILIMIT 6000 500 0 16384 Pages
MPW_LOLIMIT 3000 32 0 16384 Pages
MPW_THRESH 4000 200 0 16384 D
MPW_WAITLIMIT 6000 500 0 16384 D
PFRATL 0 0 0 -1 Flts/10Sec D
PFRATH 30 120 0 -1 Flts/10Sec D
WSINC 150 150 0 -1 Pages D
WSDEC 35 35 0 -1 Pages D
AWSMIN 50 50 0 -1 Pages D
AWSTIME 20 20 1 -1 10Ms D
SWPOUTPGCNT 80 60 0 -1 Pages D
FREELIM 90 32 16 -1 Pages
FREEGOAL 327 200 16 -1 Pages
GROWLIM 326 63 0 -1 Pages D
BORROWLIM 408 300 0 -1 Pages D
PHYSICALPAGES 532480 532480 2048 532480 Pages
PFRATS 0 0 0 -1 Flts/10Sec D
/kenw
A L B E R T A
Ken Wallewein R E S E A R C H
kenw@noah.arc.cdn C O U N C I Lewilts%Ins.MRC.AdhocNet.CA%Stasis.MRC.AdhocNet.CA%UNCAEDU.@CORNELLC.CCS.CORNELL.EDU.BITNET (Ed Wilts) (06/29/88)
Just a reminder to all people who want to play with the parameter MPW_HILIMIT.
Ensure that MPW_WAITLIMIT is EXACTLY EQUAL to MPW_HILIMIT. If they are un-
equal the following will happen:
When a processes modifies a page and MPW_WAITLIMIT is reached, the
process will enter a RWMPB state. It will stay that way until
MPW_HILIMIT is reached at which point SWAPPER will write out the
modified pages and normall processing continues. It is easy
to see what happens if MPW_HILIMIT > MPW_WAITLIMIT: processes will
enter the RWMPB state and stay there forever because MPW_HILIMIT
will never be reached.
I just spent the morning trying to figure out why my system kept hanging as
soon as users starting to use it (I just know I shouldn't let users on).
Why does SYSGEN not check for this obvious attempt to shoot yourself in the
foot (VMS 5.0?) ?
.../Edewa@csdgwy.csd.unsw.oz (07/05/88)
In article <2022*kenw@noah.arc.cdn>, kenw%noah.arc.CDN@ean.ubc.ca (Ken Wallewein) writes: > I've been following this discussion, and it's encouraged me to do a bit of > digging. > > We've been running memory-rich in the past, althought that's changing. > MPW_HILIMIT is at 6000, and MPW_LOLIMIT at 3000. > > However, one thing is bothering me: I can't seem to get the modified list > above about 600 pages, and it's usually somewhere between 50 and 300. With > the free list running around 16,000 blocks, it just doesn't seem right. > According to what I've been told at one VAX/VMS performance seminar, it does not make sense to define a large MPW_HILIMIT. The reason is that whenever a process with pages in the modified list terminates, the whole list is written to disk, so its size gets down to zero. That's probably why it can never grow really big. I never found any reference to it in any documentation, but my observation of the multiple VAX/VMS systems confirm this. On many ocassions I actually saw a zero-size modified list. An additional concern regarding a large modified page list is, that when it is all written back to disk, all processes with pages in it will hard-pagefault at the same time. This introduces rather undesirable oscillating system behaviour. Regards, +----------------------------------------------------------------------+ | E.Z. Bem, ASCnet: ewa@csdgwy.csd.unsw.oz | | VAX/VMS Systems Group, Infopsi: ewa@csdgwy.unsw.edu.au | | University of New South Wales, FAX: 61 2 662 8665 | | PO Box 1, Kensington, 2033 NSW, Phone: 61 2 697 2920 | | AUSTRALIA | | | | Daily a clever man learns something, daily a wise | | man gives up a certainty, perhaps... | +----------------------------------------------------------------------+
graham@DRCVAX.ARPA (07/20/88)
On the subject of the MPL discussion, Mike Pung correctly writes: >One comment concerning Frank's response is to note that the ALL-IN-1 product >DOES use global sections and thus each time an ALL-IN-1 user's process >terminates the Modified Page List (MPL) is flushed (i.e. ALL pages are >written, not just down to MPW_LOLIMIT). So if your are running ALL-IN-1 and >you have a large MPL, then you may see pauses in the system as the >Modified Page Writer is busy clearing the MPL. In this case, it would be >better to set a moderate to small MPL and set up large user working sets. I am running, among other things, a Microvax II for nothing but All-in-1. This machine has 16 mb of memory, so resources are not a problem. I have played "Tune-up Masters" with thie machine for two years. Mike is right, a 500 page MPL is the largest it should be, and 300 does not do badly either. We use 2500 page working sets and find that we get good response. I did some extensive revisions of other sysgen parameters, though. The idea of freelim being only 100 or so blocks by default rubbed me the wrong way, so I raised freelim to 1000. I then had to adjust freegoal, borrowlim, weinc and wedec, also. Finally, we have a system where about 16-18 allin1 users can coexist pretty well. Another important thing with Allin1, be sure they aren't using the qualifier that creates a default subprocess unless they ABSOLUTELY need it. Those subprocesses eat up memory and are a big waste. Just my $0.02 worth, Dan Graham graham@drcvax.arpa -------------------------------------------------------------- "You're kidding, THAT is an opinion? THAT is drivel!!" ------
EVERHART%ARISIA.DECnet@GE-CRD.ARPA (07/22/88)
M.S. Pung writes that the All-in-One product writes out modified pages a lot... He asked for comments, so here goes: Why would ANYONE use all-in-one (aka all-in-Fun) when the Vax Professional Workstation package (from your friendly local VAX SIG tapes, courtesy of Jim Downward) does basically the same things, is free, available in source, does NOT write modified pages so much, and runs (by one benchmark) about 15 TIMES FASTER than all-in-one??? (That's 1500% better, for those who prefer that style...) You will need to relink some pieces for VMS V5, and VPW needs perhaps an hour of your time to customize for YOUR system. It remains an excellent package, easy to add to, and easy to use. I find it a good thing to keep around for those needing an intro to using tools on the VAX. Incidentally, since VPW defines a good many symbols, I define VPW as a command to define the symbols. The command file redefines the VPW symbol and starts it, so the overhead occurs on first use, rather than at every login. This trick works for a variety of larger packages of this sort, and I recommend it generally. Glenn Everhart Everhart%Arisia.decnet@ge-crd.arpa
woods@blia.BLI.COM (Michael Nowacki) (07/28/88)
I'll bet a large number of system manglers would be interested to see a dump of the SYSGEN params on the uVAXII that's been running A1 exclusivly for 2 years. Even if they're not, I am. -- |\ /| | \/ | _|ike |_ uucp: ...!ucbvax!mtxinu!blia!woods