HP OpenVMS Systems

ask the wizard
Content starts here

Process Priorities, Scheduling?

» close window

The Question is:

Is it possible to move the priority boundary for realtime processes from 16 to
 say, 32?  The objective is to expand the range of non-realtime processes.
In other words, I would like to expand the range of process priorities that
 receive AWS and dynamic priority handling from 0-15 to 0-31.  Currently we
 have from 200 to 300+ processes (per server) running on numerous 1000As and
 DS20Es.  Only 3 or 4 (per se
rver) of the processes priorities' are set above 16.  Our prioritization
 strategy is a basic arrangement of low 0-3, medium 4-7, med high 8-11 and high
 12-15.  Ideally each process is assigned a base priority at the low end of its
 assigned band.  The SWAP
PER process has remained at priority 16 on all systems.
This strategy has worked well.  I have always been reluctant to use realtime
 priorities because I saw that WS adjustment and dynamic priority was handled
 quite nicely in the non-realtime zone.  But 300+ processes are getting a bit
 much to stuff into the f
our slots.
Please advise.

The Answer is :

  No, there is no means to alter the real-time and the timeshare
  priority ranges.  These ranges are coded into OpenVMS and into
  various OpenVMS and customer applications.
  The OpenVMS Wizard is mystified as to what you are trying to
  achieve.  (OpenVMS time-sharing priorities should generally be
  left alone, within broad general categories of lower and
  slightly higher priorities, with most interactive users all
  sharing one priority.  By default, priority four (4).)
  Most OpenVMS systems will operate with batch and non-critical
  processing generally operating at somewhere between one and three
  inclusive, timesharing and interactive at four, and a very few
  applications or servers running at five or higher.
  Great care must be used to avoid what is known as a priority
  inversion, as well -- where a lower-priority process blocks
  a higher-priority process by holding a critical resource.
  OpenVMS does try to float process priorities to (eventually)
  release these blockages, but it is best to avoid creating these.
  (Please see the PIXSCAN and LONGWAIT parameters, among others.)
  Perhaps the OpenVMS class scheduler, OpenVMS Galaxy partitions,
  and/or more processing power (or reduced system load) can solve
  whatever problem(s) you seek to address here.
  As you are well aware with your experience with the AlphaServer
  DS20 series systems, the AlphaServer 1000A series systems are
  comparatively underpowered by current standards.  If these must
  support large numbers of processes, please follow the steps
  around system tuning, and please expect to require additional
  memory (or conversly, to use LONGWAIT or SWPOUTPGCNT parameters
  to reduce physical memory requirements) -- please see the OpenVMS
  Performance Management Manual.  Priorities are just one part of
  the system performance equation, and priorities may or may not be
  the best way to address system performance.
  All discussions of parameters and priorities and tuning aside,
  the closer you can maintain a system to AUTOGEN and installation
  norms, the easier it will be to manage, upgrade, or recover.
  If you do choose to alter paramters, please use MODPARAMS and
  AUTOGEN, and please document your changes and your settings.

answer written or last revised on ( 13-MAY-2003 )

» close window