zowe / docs-site

Documentation for the Zowe project
https://docs.zowe.org/
Creative Commons Attribution 4.0 International
69 stars 135 forks source link

Document recommended Workload Management setup for ZWE* #3840

Open balhar-jakub opened 2 weeks ago

balhar-jakub commented 2 weeks ago

Is your request for enhancement related to a problem? Please describe.

The zowe startup takes all the available resources within the system.

Describe the solution you'd like

One correct way to solve the problem is to properly set up the class within the Workload Manager, which limits the resources available to the Job. We should document the recommended configuration for the Workload Management Setup.

Related doc pages

It's going to be a new one within the Installation procedure.

Additional context

The work probably will need to happen together with the server squads.

balhar-jakub commented 2 weeks ago

Following is excerpt from z/OSMF documentation on the topic of WLM setup.

Setup an appropriate performance goal on WLM

In z/OS system, we usually using Workload Management (WLM) define performance goals for workloads in business terms. WLM will monitor the system and adapt how much resource, such as CPU or storage, should be given to meet those goals.

z/OSMF workload can also benefit from WLM by setting up an appropriate performance goal. The following will introduce the general method to setup z/OSMF performance goal.

First, confirm the WLM feature is enabled. Usually z/OSMF already defined this feature in the server.xml file which specified zosWlm-1.0.

Second, create the classification rules for z/OSMF. The CB classification rule is defined for WAS related transaction. z/OSMF also use this classification rule. The CN (Collection Name) and TC (Transaction Classes) should be created. The "Qualifier Name" of "Transaction Class" should be align with what is defined in z/OSMF parmlib option "WLM_CLASSES". By default, they are "IZUGHTTP" for z/OSMF transactions and "IZUGWORK" for long running task of Software Management plugin. It is necessary to specify the server directory name in qualifier name. The server directory name is zosmfServer which we abbreviated as zosmf*. Note that it must match exactly so mixed case is required. Here is an example:

* Subsystem Type CB - Rules for z/OSMF (Transactions) 
Classification: 
  Default service class is IZUGWORK 
    There is no default report class. 
      Qualifier Qualifier Service Report 
  # type name Class Class
  - ---------- ---------- -------- --------
  1 CN zosmf* IZUGWORK 
  2 . TC . IZUGHTTP IZUGHTTP RSMPETRN 
  2 . TC . IZUGWORK IZUGWORK

Third, create the required service classes. We create two service classes for z/OSMF, IZUGHTTP and IZUGWOR. The IZUGHTTP service class is for foreground z/OSMF transactions (except asynchronous beans). The IZUGWORK service class is for long running asynchronous beans and for unexpected z/OSMF work, not otherwise classified. The following is an example:

* Service Class IZUGHTTP - WebSphere transactions 
  Base goal: 
  CPU Critical = YES I/O Priority Group = NORMAL 
    # Duration Imp Goal description 
    - --------- - ---------------------------------------
    1 2 80% complete within 00:00:02.000 

* Service Class IZUGWORK – Low Priority 
  Base goal: 
  CPU Critical = NO I/O Priority Group = NORMAL 
    # Duration Imp Goal description 
    - --------- - ---------------------------------------
    1 Discretionary

If the workload performance can’t satisfy your expectation you can tuning the performance goal by changing the importance and the goal.

The last, install and active the WLM policy. You can use both WLM panel and z/OSMF web UI to finish this step. z/OS Management Facility V2.4 Resource Requirements Be aware, if you tuning WLM goal, assure that you have a sufficient test.

balhar-jakub commented 2 weeks ago

Put Zowe into TSOMED WLM policy and make sure it applies to ZWE* jobs.

This is still a robust service class, but lower than the regular TSO user community. Previously these tasks were ending up in TSO service class and that was negatively impacting the entire user community because these TSO foreground tasks are at the "top of the food chain" and your z/OSMF foreground tasks tend to be CPU heavy due to the fact you're querying the system. Now these OTX tasks are lower to start with and will fall to a lower period of the multi-period service class sooner.