zar%Xhmeia@CIT-HAMLET.ARPA (12/04/85)
I *LOVE* to tune my system. As a result, the amount of pages allocated
by VMS are usually about 13-15 percent of the physical memory. Every
time I load in new system software (like from V3.7 to V4.0) the DEC
upgrade usually sets parameters to make the system use about 25 percent
of the physical memory. In addition, one of the manuals suggests tun-
ing your system with AUTOGEN.COM and changing some parameter files
to reflect the changes your system requires. I have never gotten this
procedure to work to my satisfaction (that is "I think I can do it
better"). I'm interested in talking to other managers that have tried
to tune their system and what results they have in tuning the VMS sys-
tem.
Zar
a.k.a. Dan Zirin
Caltech Chemistry
ZAR%XHMEIA@HAMLET
P.S. The system I use has 12 Mbytes, lots
of peripherals (sp?), and limited inter-
active use (batch use is strongly encouraged).info-vax@ucbvax.UUCP (12/05/85)
> I *LOVE* to tune my system. As a result, the amount of pages allocated > by VMS are usually about 13-15 percent of the physical memory. Every > time I load in new system software (like from V3.7 to V4.0) the DEC > upgrade usually sets parameters to make the system use about 25 percent I use AUTOGEN as recommended and have had fairly good results. It tuned VMS to use about 12% of physical memory. I have a 14 Mb 785 with a heavy interactive and moderate batch load. The things I've needed to do are bump up the balance set count when I found my system swapping with 4000 free pages, and bump up VIRTUALPAGECNT for some of our applications. Other than that I (and my users) have been quite happy with AUTOGEN. /Kevin Carosso engvax!kvc @ CIT-VAX.ARPA Hughes Aircraft Co.
MHJohnson@HI-MULTICS.ARPA (Mark Johnson) (12/05/85)
We have a 780 with 10mbyte of memory (785 upgrade & 6mbyte more on loading dock...) and use AUTOGEN ok. We have a moderate interactive load with a few VERY large jobs that usually run in batch. Peak logins are around 25 or so. Just looking, we use about 15.8% of memory permanently allocated to VMS. Some of the key items I have put into MODPARAMS.DAT include: WSMAX=8096 VIRTUALPAGECNT=32768 SRPCOUNT=1900 IRPCOUNT=900 BALSETCNT=36 PFRATL=0 FREELIM=200 BORROWLIM=1000 MPW_LOWLIM=200 SWPOUTPGCNT=512 NPAGEDYN=450000 PAGEDYN=300000 SWAPFILE=48000 In comparison with AUTOGEN, I have really increased several parameters that cause MORE memory to be used. A key change is the small (relative to AUTOGEN) balance set count. On my system, this causes a moderate number of jobs (up to 10 or so) to be swapped & stay swapped during peak periods. The system performance really improved after the BALSETCNT change because the jobs in memory have far reduced paging rates & there is enough free memory for image activation as well. By the way, be sure you crank up the values of IRPCOUNT & SRPCOUNT & NPAGEDYN on your system. Don't let VMS grow those values on the fly unless you like real performance hits. You can use SHOW MEMORY/ALL/FULL to get an idea what your real need is & add about 20% to that value to allow for growth. There are a couple ways your system will crash if NPAGEDYN is not big enough as well. --Mark <MHJohnson @ HI-MULTICS>
sasaki@HARVARD.HARVARD.EDU (Marty Sasaki) (12/07/85)
I think that it is a good idea to use autogen.com to do your parameter
changes, it rationalizes the numbers and tries to change related
parameters while it is changing the ones you asked to be changed.
While I think it is a good idea, I always just make the changes in
sysgen. (Do what I say, not what I do.)
Most of our use is interactive, much of it by students in the edit,
compile, link, and run loop. We also run lots of stat packages. The
main system bottle neck is i/o and paging. As a result, I tune my
systems to have fairly large caches (of all types), with working set
adjustment parameters set to allow moderate working set extents.
The current exec is pretty large, but the free page list always has
pages on it, and the overall page fault rate is less than 30 pages/sec
with almost all of the faults being demand zero, or coming from the
modified or free page list.
The systems consist of 780's and a 785 with 8meg of memory and RA81's.
See you at DECUS? Maybe we should have a info-vax BOF meeting?
----------------
Marty Sasaki net: sasaki@harvard.{arpa,uucp}
Havard University Science Center phone: 617-495-1270
One Oxford Street
Cambridge, MA 02138