Main content
The OpenVMS Class Scheduling System
Introduction
How many people are aware of the class scheduling system on OpenVMS, I wonder? This article will briefly discuss the preemptive system normally used by OpenVMS, and compare it with the class scheduling system.
Preemptive Scheduling
Most OpenVMS systems managers and programmers will be familiar with the system of preemptive scheduling that the operating system uses by default. In this system, a computable process at a higher priority preempts a lower priority process that is currently using the CPU, causing the lower priority process to yield the CPU, even if the lower priority process has not reached the end of its quantum.
With the clever implementation of priority boosts that the operating system applies by default when certain events occur in a process (for example, the process's priority is boosted when an I/O completes, with the assumption that the process will go computable shortly thereafter), this system works extremely well.
Generally, a systems manager will leave interactive processes at base priority four, and batch jobs will be set up to run at some lower priority. (Which priority to set batch queues to is sometimes a contentious issue with system managers. Some prefer to set batch queues to 3 and some prefer zero. I'm in the "3" camp, as this still gives preemptive powers to interactive users at base priority of 4, and allows me to prioritize batch processing to boot.)
While preemptive scheduling is a fair system, sometimes you don't want to be fair (or you might want to be more flexible than preemptive scheduling allows). With class scheduling, you can grant specific amounts of the CPU to processes based on username, UIC, or account.
Class Scheduling
Class scheduling is implemented in the SYSMAN utility as a set of commands to define classes based on username, UIC, or account. There are some additional qualifiers that you will want to look at, /WINDFALL in particular.
The commands to enable class scheduling allow you to specify primary and secondary days, and hour ranges for the classes.
Let's have a look at a concrete example. We have a nasty little CPU hog, which unfortunately is a third party application that we have no control over. It consistently sucks up the entire CPU's processing power, and when this happens, other developers complain that they can't get any work done. A MONITOR PROCESS/TOPCPU looks like this when the evildoer goes active:
OpenVMS Monitor Utility
TOP CPU TIME PROCESSES
on node xxxxxx
8-JAN-2007 16:48:58.83
0 25 50 75 100
+ - - - - + - - - - + - - - - + - - - - +
22977031 Nasty Evildoer 99 ▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒
229F58F1 BATCH_7823
+ - - - - + - - - - + - - - - + - - - - +
Now let's create a class to limit the amount of CPU the process can consume. The process is running under username "EVILDOER". We will create a class to limit the CPU for this username to 25 percent during working hours, Monday to Friday, and allow them free reign on the weekends and any time outside the primary hours we specify:
$ mcr sysman
SYSMAN> class add limit_evildoer/cpulimit=(primary, 8-17=25)/user=evildoer
SYSMAN> class show/all/full
Node xxxxxx:
------------
Class name: LIMIT_EVILDOER Windfall: Disabled
Maximum CPU time for Primary Days:
25% ( 8am - 5pm )
Maximum CPU time for Secondary Days:
None
Primary Days: Mon Tue Wed Thu Fri
Secondary Days: Sat Sun
Nodes:
xxxxxx
User names:
EVILDOER
SYSMAN>
Note that windfall is disabled, which hard-limits the CPU available to this username to 25%
Now, when the evil process goes active during the day, we see the following from MONITOR:
OpenVMS Monitor Utility
TOP CPU TIME PROCESSES
on node xxxxxx
8-JAN-2007 16:52:25.79
0 25 50 75 100
+ - - - - + - - - - + - - - - + - - - - +
22947887 Nasty Evildoer 25 ▒▒▒▒▒▒▒▒▒
2295C0BD BATCH_4311 3 ▒
+ - - - - + - - - - + - - - - + - - - - +
Even though the process we are limiting is attempting to place exactly the same workload on the CPU as previously, it is now effectively limited to 25% of the machine. As mentioned before, using /WINDFALL can be an especially good way of limiting a process (or groups of processes) because if the CPU is idle, they will still get some percentage of the machine, even though they have used up the limit imposed by the class.
Also remember that the class percentage applies to all processes that match the class definition. So if we had two evildoer processes, each would get 12½% of the CPU.
You can enable and disable the classes dynamically using the SUSPEND and RESUME verbs in SYSMAN. And you can find out if a process is class scheduled by issuing the SHOW PROCESS/SCHEDULING_CLASS command.
More bits and pieces
There are some additional commands that are worth being aware of. In particular, the SET PROCESS/SCHEDULING_CLASS is worth keeping in mind. While this command doesn't affect the permanent class scheduling database, it's a quick way to add a process to a class if needed. For this reason alone, I believe it's worth having a couple of classes defined, so you can instantly limit the amount of CPU a process consumes.
Also, for the programmers out there, there's a system service called sys$sched (), that allows you to implement your own class scheduler. There is an example of this in sys$examples:class.c. Note that you can't class schedule a process with both this system service and the SYSMAN utility.
Conclusion
I hope this short article gives you some ideas as to how you could use class scheduling on OpenVMS to your advantage. It can be a far more flexible way to limit CPU usage. As a final thought, it can also be used to guarantee CPU availability to meet service level agreements.
