[Info-vax] vms base priority watch

Jose Baars peutbaars at googlemail.com
Tue Jul 12 17:24:55 EDT 2011


I assume the data is in RMS files, and also that somewhere in
the past it has been established that raising process priority
helps finishing reports more timely.

I'm not a performance specialist, but I've seen this once or twice,
and in both cases was caused by horrible applications in an
interpreted
language and remote lock contention/ high mpsync.

The solution was concentrating all (or most) I/O on one node of the
cluster to eliminate remote locking, and adding global buffers to the
RMS files.
And of course replacing the most offensive reports by fast reliable
COBOL versions.

This was on ancient versions of VMS (around 7.1), and newer versions
are much better at handling this, but the performance benefits still
apply.

In other situations, raising priority wouldn't really help, but
wouldn't
harm much either. Unless forced to, I wouldn't put chasing the how
and why of this priority rise at the top of my personal priority list.

Some ideas:

Have you looked at MPSync with the monitor mode command?
Is this higher than, let's say 10% at the busy times?
Have a look at monitor rlock (on all cluster nodes) and see if you
see numbers in the  100000's, or thousands at remote locks.

If you see this, or you are just curious, Google for Keith Parris
openvms
lock, and see if you can make chocolate of his advice on thse
subjects.

Also, read the manual on the monitor mode command, and google
for it too. After properly digesting the rather dense information, it
gives you a pretty good insight of what might be going wrong.

Ask HP for advice if you have a support contract, and/or hire
an independent specialist (some of whom figure on several
OpenVMS forums).




More information about the Info-vax mailing list