Determining z/OS Workload Manager velocity goals

With z/OS® Workload Manager (WLM), work is assigned to a service class. For each service class, you define both the wanted performance goal and a business importance of meeting the stated goal.

To account for Db2 address spaces in a WLM service definition, apply the following recommendations:

• Place the IRLMPROC address space in SYSSTC dispatching priority.
  This address space manages IRLM locks and latches. This address space must run at a high dispatching priority that provides little or no CPU delay.
• Place the following address spaces, which are critical for efficient system operation, in the same user-designed service class. This class must be defined with aggressive performance goals and a high importance:

  ssnmMSTR

  Contains the Db2 system monitor task and requires an aggressive WLM goal so it can monitor CPU stalls and virtual storage constraints.

  ssnmDBM1

  Manages Db2 threads and is used for system services such as page set opening. In data sharing environments, this address pace is critical for global operations such as P-lock negotiations, notifies, and global commands.

  The ssnmDIST and WLM-managed stored procedure address spaces

  Address spaces that run only the Db2 service tasks and work for Db2 that is not attributable to a single user. These address spaces typically place a minimal CPU load on the system. However, they do require minimal CPU delay to ensure good system-wide performance, and to avoid queuing of threads.

  DDF workloads, with their higher CPU demands, are controlled by the WLM service class definitions for the DDF enclave workloads. Similarly, the higher CPU demands for processing stored procedures, are controlled by the WLM service class definitions for the workloads that call the stored procedures.

  Important: The velocity goal of these address spaces must be high enough that new work and new connections can get started and placed into their own goal, or the goal of the caller.
• Specify a high importance for the Db2 workloads, typically importance 1.
  In every case, the service class with the Db2 address spaces must be set with an understanding of the overall WLM service definition in use. Use this information as a guide in setting the Db2 portion of the overall WLM policy.
• Take the following actions to ensure that the Db2 environment receives the CPU service that it requires to ensure a well running system:
  • Ensure that functions like TCP/IP and VTAM® are defined in SYSSTC.
  • If necessary to meet performance objectives, it might be appropriate to designate certain service classes as CPU Critical. Doing so provides long-term CPU protection of critical work. When you designate a service class as CPU critical, you ensure that less important work generally has a lower dispatch priority than work that is marked CPU critical. This protection can be valuable for work that is extremely CPU-sensitive. Generally, having an appropriately set goal for the Db2 service class is all that is required to ensure a well running system. However, CPU critical protection is available if needed.
• Set the velocity goal for the Db2 address spaces to be among the highest for the current LPAR.

  The intent is for the Db2 address spaces to be defined so that they experience little CPU delay. These address spaces must be defined with a WLM velocity goal.

  Typically, these address spaces are placed together into the same user-defined service class. This user-defined service class be does not need to be dedicated to these address spaces. Because they must be defined with a velocity goal, it is important to set an appropriately high goal set for this workload.

  Velocity goals are dependent on the overall LPAR logical CP configuration, and the amount of processor capacity allocated to the LPAR. LPARs that have fewer logical CPs can attain only lower velocities. Whereas, LPARs that have more logical CPs can obtain higher velocities.

  Table 1. Recommended velocity goal based on the number of central processors per LPAR

  Number of CPs defined for the LPAR	Recommended velocity goal
  1-5	50-70
  6-15	60-80
  More than 15	70-90

• For LPARs that are constrained by a lack of CPU resources and have lower priority work that uses Db2, use blocked workload support.
  This support is most important in an environment where work that uses Db2 resources runs constrained at low priorities. The low priority constrained work might hold Db2 resources required by other, more important, workloads in the system or sysplex.

  For environments where low dispatch priority Db2 workloads run in periods of CPU constraint, it might prove beneficial to help blocked workloads more frequently. Changing the default blocked interval, (BLWLINTHD in IEAOPTxx), from the default value of 20 seconds to 5-6 seconds, might provide better overall system throughput at high utilizations. However, long-term reliance on blocked workload support to accommodate CPU saturated systems is not recommended.