In a 2010 7.1 announcement, there was a one-sentence statement that I thought would be good to expand upon:
IBM i 7.1 workload management enhancement enables clients to limit to the number of cores on which a selected workload can run concurrently.
So what is this, why would you want to use it and how do you get it?
IBM i’s work management capabilities have long been a strength of the operating system. The capability to configure subsystems and memory pools to isolate workloads has been an important architectural design that allowed i to support multiple, different workloads concurrently on the same partition.
However, as the hardware has become more powerful, and partitions have become larger with more cores, additional controls for managing work within a partition have became more important. One thing the IBM i development team has been looking at for a long time was how to prevent one workload from consuming all of the CPU resources available. Although you could define subsystems and memory pools, it wasn’t been very easy to limit the amount of CPU a workload used. The CPU time parameter is a class parameter, so all jobs that used the same routing entry or prestart job entry had the same configuration for the amount of CPU time they could use. Not many environments used the CPU time control simply because jobs generally need to run to completion, regardless of the amount of CPU time required; thus this really was not effective in controlling the utilization of processor resources.
This newly announced workload management enhancement provides a way to control the number of processor cores that can be concurrently used by a workload so you can now limit the processor resources consumed by a workload.
This enhancement allows you to define what are called “workload groups,” and for each workload group you can assign the number of cores that you want to allow that group to use. Then you associate a workload group with a subsystem so the jobs in that subsystem are limited to the number of cores defined by the workload group. There’s also the capability to associate a workload group with an individual job, if you want more granular control.
It might be good to provide an example of how workload groups can work for you…
One thing I often hear about is how ad-hoc queries can be disruptive to a production environment. You want your users to get at the data they require, but you don’t want that work to interfere with your mission-critical workloads. By using subsystem configuration for database server jobs, you could have these ad-hoc queries originated by users from their PCs run in their own subsystem and have this subsystem associated with a workload group. By doing this, these ad-hoc queries can be put into a ‘processing container’ to ensure they’re kept to a limited amount of system capacity. The subsystem that has been assigned to a workload group will have all jobs and their associated threads limited to the number of processing cores specified in the workload group. This same concept also applies to individual jobs; you can associate a job with a workload group. If the workload group has a processor core limit of one, then that job and all its threads will only be allowed to run on a single processor core. If this job is running on a multiple threaded core, multiple threads may be running for that designated jobs, but only a single core will be used at a time.
This feature provides the capability to allow mission-critical business applications the resources they need, while restricting other applications to fewer processor resources, and further strengthens IBM i’s work management capabilities.
This support was delivered on IBM i 7.1 with PTF SI39795 in 2010 and is in the base operating system in subsequent releases. Workload group configuration was enhanced in the 7.3 release.
This blog post was edited for currency on February 1, 2020.
This blog post was originally published on IBMSystemsMag.com and is reproduced here by permission of IBM Systems Media.