 |
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.
|
|
|
|
|
