(ZOS) Workload management (WLM) tuning tips for z/OS

Use the administrative console to provide the job control language (JCL) PROC name for the servant and the JCL Parm for the servant and thereby set up a dynamic application environment. Even if we set up a dynamic application environment, we must set the WLM goals for the environment.

Proper WLM goals can significantly affect the application throughput. The WebSphere Application Server address spaces should be given a fairly high priority. When setting the WLM goals for our z/OS system, we might want to:

• Classify location service daemons and controllers as SYSSTC or high velocity.

• Use STC classification rules to classify velocity goals for application servers.

  Early in the life of the servant, or if we have set the ManageNonEnclaveWork parameter in IEAOPTxxWLM to yes:

  • Java garbage collection runs under this classification. Java garbage collection is a CPU and storage intensive process. If we set the velocity goal too high garbage collection can consume more of our system resources than desired. If our Java heap is correctly tuned, garbage collection for each servant should run no more than 5% of the time. Also, providing proper priority to garbage collection processing is necessary since other work in the servant is stopped during much of the time that garbage collection is running.
  • JavaServer Page file compiles run under this classification. If the system is configured to do these compiles at runtime, setting the velocity goal too low can cause longer delays waiting for JavaServer Page file compiles to complete.

  If the ManageNonEnclaveWork parameter in IEAOPTxxWLM is set to no, or is not specified, most Java garbage collection and most JavaServer Page compiles are handled according to the service class criteria established for the servant that they are assigned to for processing.

  Application work is classified under the work manager.

• Set achievable percentage response time goals.

  For example, a goal that 80% of the work will complete in .25 seconds is a typical goal. Velocity goals for application work are not meaningful and should be avoided.

• Make your goals multi-period.

  This strategy might be useful if we have distinctly short and long running transactions in the same service class. On the other hand, it is usually better to filter this work into a different service class if we can. Being in a different service class will place the work in a different servant which allows WLM more latitude in managing the goals.

• Define unique WLM report classes for servant regions and for applications running in the application environment. Defining unique WLM report classes enables the resource measurement facility (RMF) to report performance information with more granularity.

• Use the wlm_maximumSRCount=x and wlm_minimumSRCount=y variables to control the maximum and minimum number of servants, if the WLM configuration is set to no limit.

  To specify values for these variables, in the administrative console, click Servers > Server Types > WebSphere application servers, and select the appropriate application server.

  If we specify a value for the wlm_maximumSRCount variable, the value must be greater than or equal to the number of service classes defined for this application environment. If the value is less than the number of defined service classes, timeouts might be caused because there is an insufficient number of servants available..

• Periodically review the results reported in the RMF Postprocessor workload activity report:
  • Transactions per second (not always the same as client tran rate)
  • Average response times (and distribution of response times)
  • CPU time used
  • Percent response time associated with various delays

• Watch out for work that defaults to SYSOTHER. As stated in the z/OS Information Center topic Subsystem-Specific Performance Hints, work in subsystems that use enclaves can suffer performance degradation if the service definition is unclassified. If we do not add classification rules for this work in your service definition, it is automatically assigned to the SYSOTHER service class, which has a discretionary goal.
• Watch for error message: BBOO0037E Function IWMSRCRR failed with RC=8,REASON=00000868 occurring in a control region.

  Restriction: In considering workload management (WLM) processing on your z/OS system with active WAS address spaces, this message results when the number of servers attempting to register to WLM has surpassed the maximum of 256. Specifically, the 257th server (and subsequent servers) that attempt to register with WLM will fail with this message. The 256 maximum is a fixed system restriction and cannot be changed.

Define application server processes

Classifying z/OS workload