Guru: What Are Workload Groups And Why Should You Use Them?

September 13, 2021

Workload Groups appear to be a hidden gem of IBM i work management. In all my work with clients, I have only encountered one shop actively using workload groups. Introduced in 2010, they provide an additional control on CPU and can also be used to license software products to a fewer number of cores than are active on the partition.

Workload groups are very simple entities; you add a workload group with the Add Workload Group (ADDWLCGRP) command. You just need to give it a name and how many processor cores, called the processor limit, can be used by that workload group. The processor limit is in whole units and can be from 1 to 256. To see a list of all the workload groups on a system, use the Display Workload Group (DSPWLCGRP) command.

Once the workload group is created, it must be associated with a workload. A workload can be:

A subsystem and all jobs that run in that subsystem.
In the 7.2 release, this association is done by creating a data area named QSYS/QWTWLCGRP that contains the subsystem name and the workload group for that subsystem. Once the data area is created, the subsystem must be ended (if active) and started again for the association to take effect.

In 7.3, IBM enhanced the Create (CRTSBSD) and Change (CHGSBSD) Subsystem Description commands to include a WLCGRP parameter. An active subsystem no longer needs to be ended for the change to take effect; active jobs will continue to use the prior workload group, while new jobs that are started will pick up the change.

In all releases, message CPI146C, subsystem is using workload group, is logged in the job log of the subsystem monitor job.

A specific job.
The Change Job (CHGJOB) command has a WLCGRP parameter to associate a workload group with a specific job. The change is immediate for that job.
Jobs that have their attributes defined by a job description (7.4 and later)
The Create (CRTJOBD) and Change (CHGJOBD) Job Description commands were enhanced with the WLCGRP parameter in the 7.4 release.

Let’s look at the how workload groups can control CPU usage. Traditional work management controls for CPU are in the class object. Knobs and dials labeled maximum CPU time, time slice, and run priority controlled how a job could use CPU. These are good controls, but a low priority job can still consume a lot of CPU if there isn’t higher priority work running. A group of low priority jobs in a subsystem could all contribute to high CPU utilization. When you associate a workload with a workload group, all jobs in that workload will be limited to using no more of the processor time than specified in the processor limit.

Another use of workload groups to control CPU usage involves ad-hoc queries. Assume you have a set of users who routinely need to generate various reports against production data. These queries may be created on the fly and may be poorly written and rather expensive to run. If you can isolate these users into a specific subsystem, perhaps by routing work by user profile, that subsystem could have a workload group associated with it to constrain the amount of CPU resources used by these ad-hoc queries. The users can still access the data and generate their reports, but their impact on the system is better controlled; their queries may simply take longer to run.

Workload groups can also save money. For example, perhaps you have a partition with 24 cores and are using IBM’s MQ product. You do not want to license MQ for 24 cores because of the expense and because there is a lot of other work happening on that partition. With workload groups, you can isolate that MQ workload into its own subsystem and associate a workload group with that subsystem. This allows you to license MQ only for the number of processors specified in the workload group. The Add Workload Product Entry (ADDWLCPRDE) identifies the license term and feature of the product that is limited by the number of processors defined for the workload group. A Remove Workload Product Entry (RMVWLCPRDE) command is also available. IBM has an older document on licensing MQ with workload groups that is still applicable. I used MQ as an example, but using workload groups for licensing purposes is not limited to MQ.

Finally, it may be puzzling why the workload group commands and parameters have a C in them (WLCGRP). During development, IBM used the term ‘workload capping groups’. The commands and parameters had been set in stone, but shortly before the function became available, they simplified the name to ‘workload groups’.

Dawn May is a leading authority on work management, systems management, performance, and diagnostics, with intimate knowledge of the IBM i operating system developed through her distinguished career with IBM. She focuses her skills on helping companies troubleshoot issues and plan for the future while teaching them how to get the most out of their IBM i systems. To learn more about PDI and how to use it, or for assistance with performance issues, visit her Website, dawnmayi.com, to review her offerings.

RELATED STORIES