You can 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 you set up a dynamic application environment, you must set
the WLM goals for your environment.
Proper WLM goals can significantly affect your application throughput.
The WebSphere® Application Server address spaces
should be given a fairly high priority. When setting the WLM goals
for your z/OS® system, you 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
you set the have set
ManageNonEnclaveWork parameter
in IEAOPTxxWLM to
yes:
- Java garbage collection runs under this classification. Java garbage
collection is a CPU and storage intensive process. If you set the
velocity goal too high garbage collection can consume more of your
system resources than desired. If your 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 your 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 JavaServer Page compiles are managed
according to the service class to which WLM has bound the servant
for the work the servant is 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 you 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 you can. Being in a different
service class will place the work in a different servant which allows
WLM much more latitude in managing the goals.
- Define unique WLM report classes for servant regions and for applications
running in your 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.
Avoid trouble: If you 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.
gotcha
- 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 left unclassified in the service
definition. If you 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 WebSphere Application
Server 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.
![[Updated in February 2013]](../../deltaend.gif)
feb2013