VMS SYSTEM TUNING

[vmsserbo]

How do you tune a VAX system after an upgrade. What do you tune? Look for Etc!

It's been a long time !

[Jefferson Humber · Accepted solution]

Miles,

I personally use AUTOGEN as a good starting point, make sure you have at least 48hrs uptime first though.

And make sure your MODPARAMS.DAT is in order too.

J

[vmsserbo]

So do I wait 48 hours and the run autogen ?

What is the exact command for autogen ! I assume I look at the agensparams.report

[Jefferson Humber]

Miles,

Before running AUTOGEN I reccomend you have a read of the HP System Managers manuals, available here...

http://h71000.www7.hp.com/doc/os82_index.html

I believe one of them has a chapter devoted to AUTOGEN, try http://h71000.www7.hp.com/doc/82FINAL/aa-pv5nj-tk/aa-pv5nj-tk.HTMl

There are many options you can choose when invoking AUTOGEN, some just suggest changes, others actually change parameters and reboot your system for you !!!

Proceed with caution,

Jeff

[Arch_Muthiah]

Miles,

This is the syntax,
$ @SYS$UPDATE:AUTOGEN start-phase end-phase execution-mode

start-phase: Is the phase where AUTOGEN is to begin executing.

end-phase: Is the phase where AUTOGEN is to complete executing.

execution-mode: any one of the below
FEEDBACK--Use feedback.
NOFEEDBACK--Do not use feedback.
CHECK_FEEDBACK--Use feedback if it is valid. If feedback is invalid, ignore it, but continue executing through the end phase.
Blank -- Use feedback if it is valid. If it is not valid, quit before making any modifications.

And details about the AUTOGEN Phases, please see the link under "15.4.3 AUTOGEN Phases"

http://h71000.www7.hp.com/doc/73final/6017/6017pro_067.html



Archunan

[Robert Gezelter]

Miles,

AUTOGEN after a reasonable period of gathering statistics is certainly a good start.

Beyond that, when I am tuning a system, I make it a point to look at the behavior of both the systems and the applications. Many so called-tuning sessions do not, IMHO, pay sufficient attention to applications utilization issues. I have found that it is not unusual for these to overwhelm the results achieved with changes in system parameters.

While it is dated, I have presented this at several DECUS symposia (originally, it was a requested session for the DECUS Local User Group at NASA's Marshall Space Flight Center. Checking my www site, I see that that particular session has not been posted (I am a little behind in back-posting material from before the site existed). I know that I saw the slide set recently as I was working on the backlog.

I hope that the above is helpful.

- Bob Gezelter, http://www.rlgsc.com

[John Abbott_2]

> So do I wait 48 hours and the run autogen ?

Under a "typical" workload, what ever you deem that is !

As Robert suggests, the autogen is a good start, see it as a bit of a sanity check/starting point.

If you keep your system up for several weeks/months you might want to consider runing autogen again before you reboot.

As a hint, try this sequence, worth nosing through the manual to understand what's going on here...
@sys$update:autogen savparams
@sys$update:autogen getdata genparams
@sys$update:autogen setparams !(commit autogen suggested changes)

PS. After a VMS upgrade I thought AUTOGEN was automatically run anyway ? (may depend on what version you're using).

John.

[Ian Miller.]

Note do
@sys$update:autogen savparams
when the system is busy as some of the information saved depends on current load.

I usually do this
@SYS$UPDATE:AUTOGEN GETDATA TESTFILES

to get a report. Its always worth reviewing the contents of MODPARAMS.DAT as there is often historical items which are no longer better.
Generally the fewer lines in MODPARAMS the better.

Do look at the system performance with MONITOR (or other tool of your choice). You may not need to do anything. Also remember that user quotas may need changing if there is now more memory.

[Robert Gezelter]

Miles,

You are in the best position to evaluate your workload.

Workload (and therefore the information that AUTOGEN can capture about the needs of the workload) vary often differ tremendously from site to site, day to day, and machine to machine.

For example, a quick look at a typical member of a VMScluster will show that the workload will (among other reasons) vary depending on:
- how many other cluster members are online
- day of the year (e.g., end of week, month, year processing)
- time of day

When setting system parameters, it is often best to find a way to force the "worst case" (i.e., highest demand) on resources and set the parameters accordingly. Thus, your configuration will be able to accomodate the maximum load (plus, hopefully, a additional reserve for expansion and safety margin).

Remember, the worst time to discover a configuration limit is when eight out of nine members of the VMScluster are down due to a hardware or power issue, you are running end of year (deadline critical) processing and supporting the entire enterprise on a single node while working to get the other nodes online.

- Bob Gezelter, http://www.rlgsc.com

[Arch_Muthiah]

Miles,

There are two types of tuning on VAX/VMS
1. Manual Tuning
2. Dynamic Tuning (Automatic)

The manual Tuning has the following problem...
One, it is a very tedious and time-consuming task. It requires many hours/days of analysis.

Two, after each change to system parameters the system must normally be shut down and then rebooted. This is a MAJOR inconvenience to your users.

Three, you are only able to tune for "average overall" performance. If there is a sudden change in the work load, all of your tuning efforts can be for nothing.

For Dynamic Tuning for VAX there are couple tools, one is already discussed in this forum, that is "Dynamic Load Balancer"

This automatic tuning of DLB plus saves time and guarantees the best possible OpenVMS performance.

The automatic tuning of DLB plus is an expert system that dynamically adjusts SYSGEN and process parameters as often as every six seconds. It saves a tremendous amount of time compared to manual tuning and guarantees that your CPU and Memory resources will be used to achieve the best possible performance. DLB reclaims wasted memory and allocates it for optimal use, ensures that CPU resources are optimally used and provides vital information for eliminating I/O bottlenecks. It even tunes the VMS paging system.

Performance benefits of DLB Plus include:

Improved response times
Increased throughput
Reduced hard page faults
Reduced or eliminated CPU bottlenecks
Increased available free memory
Support more users on the system simultaneously
Increased system capacity


Archunan

[comarow]

Miles,

First of all, do you have a performance problem?

The rule of thumb is after an upgrade, a change of load or changing hardware,
wait for a day or two, make sure you've had the full load on the system, and execute
autogen with feedback.


That said, I highly recommend never doing an autogen with an automatic reboot. Always check what it changed. Know your feedback.
Feedback must be for at least 24 hours with your peak load.

After running autogen, it creates that long,
file, agen$params.report. while it is valuable, and it's very important to look for error messages, I prefer the reader's digest version.

$set term/width = 132
$diff/par setparams.dat

It will compare the last two versions of setparams.dat. The new one will be on the left.

My own personal rule is make sure it didn't change any shadow or cluster parameters you didn't intend to, or reduce any parameters significantly. If it did, make the changes to modparams.dat. That's why I never automatically reboot.

The center does have the Performance Cookbook, which some people have the URL for.

Have fun.