Informing the IBM Community

Easily Control that runaway job using IBM i Workload Groups

0
(0)

How to limit high CPU jobs easily

If you have any jobs or users that, every now and then, manage to impact the system by using a large amount of CPU, this trick may help.  There is a catch!  This method only limits jobs that have more than 1 thread.  A single thread job will only use 1 processor at a time.  Java is multi-threaded.
ProTip: You can use WRKACTJOB, then F11 twice to see the number of threads per job. Chances are, there is more multi-threading going on than you first thought.

“Workload Group” is a way to limit the number of processors certain jobs can use.  It is not very well known, I Googled “IBM i WLCGRP” and received 541 results.

Workload Groups are normally attached to Subsystems.  However with V7R4 you can now attach one to a Job Description.  It is also possible to change individual active jobs with CHGJOB regardless of the job queue or subsystem. 

 Yet another reason to be up to date with your OS and PTFs.

Note: *ALLOBJ may be needed to execute any WLCGRP commands.  You may also need *JOBCTL to create/change job descriptions, subsystem descriptions and jobs.  Users should be able to submit and work with job, depending the partition security settings.

How to limit specific jobs if I have V7R4

First create a Workload Group and give it a processor limit, in this case 1.

ADDWLCGRP  WLCGRP(MYWLCGRP1) PRCLMT(1)

DSPWLCGRP command will confirm this, any maybe more – see History below.

Next create a Job Description and associate it with the Workload Group.  The Job Queue can be a new or an existing one.  Ensure it is running in a Subsystem before submitting jobs to it. 

You can assign this Job Description to specific user profiles, or use it to submit specific jobs.

CRTJOBD JOBD(MYLIB/MYJOBDQB) JOBQ(QBATCH) WLCGRP(MYWLCGRP1)

SBMJOB CMD(DLYJOB DLY(300)) JOB(WLCGRPTEST) JOBD(MYLIB/MYJOBDQB)

Enter WRKJOB JOB(WLCGRPTEST) OPTION(*DFNA) which is also option 2 of WRKJOB. 
Page down to the last page, where you will find.

The best thing about this is that if you apply this to a job and decide to change it, no problem.

Change the processor limit on the Workload Group, this will immediately affect all jobs using the Workload Group.

CHGWLCGRP WLCGRP(MYWLCGRP1) PRCLMT(2)

Or change the job to use another Workload Group or none.

ADDWLCGRP  WLCGRP(MYWLCGRP2) PRCLMT(2)

CHGJOB JOB(WLCGRPTEST) WLCGRP(MYWLCGRP2)

or

CHGJOB JOB(WLCGRPTEST) WLCGRP(*NONE)

Check it with

WRKJOB JOB(WLCGRPTEST) OPTION(*DFNA)

Changing or removing the actual Workload Group will affect ALL jobs using the group immediately.  Changing the job or subsystem description will only affect jobs submitted after the change. 

ProTip The WLCGRP cannot be changed while a job is on the job queue.

For those on V7R3 or, to have control by Subsystem

Create a new subsystem is probably the best idea as all jobs submitted to it will be restricted.  To change an existing Subsystem simply use the ADDWLCGRP and CHGSBSD to add the Workload Group.

CHGSBSD SBSD(MYLIB/MYSBS) WLCGRP(MYWLCGRP)

Start the subsystem.  MYLIB/MYSBS has WLCGRP(MYWLCGRP), a job queue called MJOBQ and a job description MYJOBD.

STRSBS SBSD(MYLIB/MYSBS) 

Now any jobs submitted directly to MYJOBQ  or use MYJOBD will run in MYSBS and be limited to one processor.

SBMJOB CMD(DLYJOB DLY(120)) JOB(WLCGRPJOBD) JOBD(MYLIB/MYJOBD)

SBMJOB CMD(DLYJOB DLY(120)) JOB(WLCGRPJOBQ) JOBQ(MYLIB/MYJOBQ)

If the Processor Limit of the Workload Group is changed it will immediately affect all the jobs in the subsystem.  However, if a Workload Group is added or removed from a Subsystem while it is running, this will only affect NEW jobs.  Use CHGJOB to change running jobs.

For V7R1 and V7R2

The only difference is that the Workload Group is NOT defined in the Subsystem, but in a Data Area.  Use the following command to create it, although it may already exist if Web Query is installed.  Also the Subsystem has to be ended and started before a change is implemented.

CRTDTAARA DTAARA(QSYS/QWTWLCGRP) TYPE(*CHAR) LEN(2000) VALUE(‘MYSBS’) TEXT(‘SUBSYSTEMS TO USE WORKLOAD GROUPS’) AUT(*USE)

If it already exists use, after checking the start position (20, 30 etc), in this case 20

CHGDTAARA DTAARA(QSYS/QWTWLCGRP (20 10)) VALUE(‘MYSBS’)

Warning

RMVWLCGRP will cause jobs to be changed to *NONE.  The entry will remain in the Job Descriptions and the Subsystem Descriptions.   Add it back in again, the active jobs may have to be changed manually and the Subsystem will have to be restarted.

WLCGRP commands do not appear in Navigator for i, although the workload group entry is found on the job and subsystem description pages.  Similarly it is not in QSYS2.ACTIVE_JOB_INFO(), but I have created an RFE https://www.ibm.com/developerworks/rfe/execute?use_case=viewRfe&CR_ID=149488 if you want to vote for it.

History

It used to be called “Workload Capping” hence the C in the middle of WLCGRP.  It was created, I believe, to allow IBM i customers to reduce their software maintenance on processor priced software such as WebSphere MQ.  In fact, if Web Query 2.x is installed, there will be a Workload Group for it.  In this case it is using the Product 5733WQX.

     DSPWLCGRP

If Web query is active check the subsystem job

     WRKJOB JOB(QWEBQRY21) OPTION(*JOBLOG)

How useful was this post?

Click on a star to rate it!

Average rating 0 / 5. Vote count: 0

No votes so far! Be the first to rate this post.


Comments

Leave a Reply

Your email address will not be published. Required fields are marked *