|
HP OpenVMS Systemsask the wizard |
|
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.
|