HP OpenVMS Systems

Ask the Wizard

HP OpenVMS Systems

OpenVMS information

» What's new on our site
» Upcoming events
» Configuration and buying assistance
» Send us your comments

HP OpenVMS systems

» OpenVMS software
» Supported Servers
» OpenVMS virtualization
» OpenVMS solutions and partners
» OpenVMS success stories
» OpenVMS service and support
» OpenVMS resources and information
» OpenVMS documentation
» Education and training

Quick Links

» Non-javascript page
» Ask the Wizard

Test Drive OpenVMS

» OpenVMS I64 test drive
» Java test drive

Other information resources available to you include:

» OpenVMS freeware
» ECO kits, software and hardware support, prior version support
» Alpha SRM, ARC, and AlphaBIOS firmware updates
» ENCOMPASS - HP user group
» OpenVMS software downloads, OpenVMS freeware CD-ROM
» OpenVMS firmware locations
» DECconnect passive adaptor charts
» Cables reference guide
» MicroVAX console commands
» OpenVMS student research

Select a topic below to see Questions Frequently Asked by partners

» Using the online documentation library(installing BNU from the asap SDK)
» Global sections(how to create and use.)
» xx$CREATE_BUFOBJ system service(usage)
» Ethernet address(methods of determination)
» Shareable images(cookbook approach to creating one)
» Sharing data/code at absolute addresses(a guide with examples)
» Determining the Alpha microprocessor
» Using GETSYI to get hardware status

Evolving business value

» Business Systems Evolution
» AlphaServer systems transition planning
» Alpha RetainTrust program

Related links

» HP Integrity servers
» HP Alpha systems
» HP storage
» HP software
» HP products and services
» HP solutions
» HP support
disaster proof
HP Integrity server animation
HP Integrity server animation
Content starts here

Ask the Wizard Questions

Modified Page Writer tuning

The Question is:

I have a serious problem at our V5.2-2 VAX/VMS site.  In order to try
to improve system performance, I increased the MPW parameters.  The
changes did not prove to be beneficial.  So, I tried to restore them
to their original values but I have not been abl e to.  To make
matters worse, VMS seems to have further augmented them.

We have a VAX 3100/90, equipped with 128 MB memory and 5 RZ28 and 1
RZ25 disk drives, that is the boot node for a cluster that includes
one other machine--a VAXStation 4000/60.  The 3100/90 has been
'super-charged' with a Nemonix accelerator board.  (The Nemonix
board, which doubles the clock speed and increases the cache from 256
KB to 2 MB has halved our transaction time while providing and extra
20% CPU).

The application is a student registration system that was developed
using Powerhouse from Cognos.  The typical user working set is
approximately 5000 pages.  The user's WSEXTENT is 5500 while the
WSDEF and WSQUOTA are set at 2048.  We have 53 users during  peak
operation.  While memory is scarce, we have more than ample disk
capacity and we incur approximately 500 faults per second.  Of this
number,  10 to 20 are hard faults.  I have implemented four 100,000
block page files with each on a separate disk.

MPW_IOLIMIT is at the default of 4.

The original MPW parameters are as follows:

                                Original        Modified        Present

MPW_WAITLIMIT                   10605           15900           34580
MPW_IOLIMIT                     4               4               4
MPW_WRTCLUSTER                  120             120             120
MPW_HILIMIT                     10485           1573            31437
MPW_LOWAITLIMIT                 10365           15548           15718
MPW_LOLIMIT                     120             120             13099
MPW_THRESH                      200             200             128

VMS also changed MMG_CTLFLAGS for 3 to 1

If I perform a conversational boot, I can see that the parameters in
VAXVMSSYS.PAR are use but when the system is actually up and running,
the values are changed.  I can change the values using SYSGEN and
WRITE ACTIVE (one must be very careful doing this- -a mistake in order
of change can result in a hung system) but if I reboot or run AUTOGEN
and reboot the wrong parameters are ACTIVE while the desired ones are
CURRENT.  Our page fault rate has more than doubled and our
transaction time has increased.

One solution may be to restore the system disk but I feel that this
may not help.  Any ideas?

The Answer is:


    Rule for MPW_IOLIMIT is 3+# pagefiles + #swapfiles

    If parameters are changing dynamically, look for tools such as Dynamic
    Load Balancer or ROBOtune.  These dynamically change parameters and may
    not be helping you as much as just setting the parameters correctly in
    the first place might.

    MPW parameters look ok except someone messed with MPW_LOLIMIT which
    is seldom used anymore except under pool expansion and such.

    AUTOGEN usually wants to set MMG_CTLFLAGS to 3 or 255 -- never just 1.

    Sounds like MODPARAMS.DAT may need to be cleaned up a bit too.
    Remove all entries pertaining to MPW_* or FREELIM, FREEGOAL, BORROWLIM,
    If WSINC is at its default, it can be increased to a higher value such
    as 512 or 1024 on your system.

    On PowerHouse systems, it is sometimes better to keep a few extra pages
    on the free list by increasing FREEGOAL from its default of 12000 (in
    your config) to something closer to 24000 to encourage more trimming.

    Be careful not to force swapping by lowering BALSETCNT. Swapping in
    PowerHouse systems can be very painful.  It is better to use proactive
    swapping and trimming rather than forcing swapping using balsetcnt.

    Establish a baseline for parameters and performance then make changes
    sparingly, measuring the benefit as you go. Back out changes that
    exhibit no apparent benefit.

   In addition to the comments around dynamic changes to the values
   of SYSGEN parameters -- something that OpenVMS does not do once the
   system has passed the basic parameter sanity checks -- it's distinctly
   possible these systems are simply overloaded and need to be upgraded.

   There is a guide to system tuning provided in the performance management
   manual -- system tuning requires a systematic and system-wide approach.

   If there are definite intervals of inactivity on individual processes,
   I would consider the the SWPOUTPGCNT parameter, in an attempt to force
   an inactive process to swap out during intervals of inactivity, rather
   than incrementally trimming it back.

   You have mentioned fault rates, but not CPU loading and CPU modes -- I
   would look at these factors and see if a system upgrade is warranted.
   I'd also make certain the I/O queues did not indicate a performance
   restriction on a particular disk spindle.  (All of this is covered in
   the performance manual.)

    Using SWPOUTPGCNT is an old approach that seldom applies unless we're
    satisfying a free list starvation and the swapper has reached critical
    mode.  If MMG_CTLFLAGS is enabled, you will almost never swap the old
    way and that's a good thing.  The old way of swapping caused processes
    to actually have their lists trimmed, forcing them to rejustify their
    list sizes when they became active again...

    Proactive swapping will begin when the list hists FREEGOAL and swaps
    process at current size...

    Powerhouse applications have been known to connect to RMS indexed files
    multiple times often requesting 5 buffers of 4 - 10 KB each per user.
    In a particular case I analyzed, each user had an average of 20 files
    with 20 buffers of 4Kb each. Some 1.5Mb or 3000 pagelettes of private
    pages each. The solution for that customer was to give some 20 major
    files 50 - 200 global buffers each: $SET FILE/GLO=42 HOT:*.DAT
    Combined with a reduction of the per-connect number of buffers from
    its default (5 for many files) to an explicit 2 by issuing the
    following command before entering powerhouse:

    	$SET RMS /IND/BUF=2

    Note, this is counter intuituve tuning... normally the more buffer
    the merrier, but when memory is scarce and sharing is possible...

    In that case, each process ended up using some 1000 pagelettes VM
    less, and touch for fewer of the pages gining much better paging.

    As always, your mileage may vary. To find out whether this technique
    might be of use to your application I suggest you use SDA as follows:
    	SDA> SET PROC "Some_powerhouse_user_process_name"
    	SDA> SHOW PROC/CHAN  ---> see which dat files are open
    	SDA> SHOW PROC/RMS=BDBSUM ---> see one data line per buffer used.