Chapter 7. Performance optimization 291
Table 7-6 shows the job execution properties parameters on the agents.
Table 7-6 Job execution properties
7.4 Best practices
In the previous sections we defined what parametes can be changed in order to
tune the Tivoli Dynamic Workload Broker. Now we describe how these
parameters can influence the performance of the product and what are some of
the best practices to follow when changing them.
7.4.1 Server
Table 7-7 discusses best practices for the server parameters.
Table 7-7 Server - Best practices
Property Definition Default
workmanager.maxjobs Specifies the maximum number of jobs
that can be run concurrently on a
resource. When this limit is exceeded,
any subsequent jobs assigned to the
resource remain in Submitted to Agent
status.
40
notifier.maxretries Specifies the maximum number of
attempts for the Workload Agent to notify
clients.
480
notifier.retryinterval Specifies the Workload Agent retry
interval between each notification
attempt. The time unit is seconds.
60 seconds
FailQInterval Decreasing this number causes the Job Dispatcher to recieve
failing situations quicker, but it would require a lot of CPU
resources if the jobs usually take long to recover, because the Job
Dispatcher will try multiple times to recover the jobs. If the a job
requires a long time to run, then it is probably better to set this
parameter to higher values than the default ones. One example
could be a Tivoli Workload Scheduler agent dealing with a new
symphony file. If there are no such kinds of jobs, or they have very
little impact on the Tivoli Dynamic Workload Broker, this parameter
can be set to lower values.
292 Getting Started with Tivoli Dynamic Workload Broker Version 1.1
MaxNotificationC
ount
The same considerations made for the FailQInterval are also
applicable for this parameter, as this should be increased as longer
downtimes are expected for jobs requiring long time to terminate.
MoveHistoryData
FrequencyInMins
Increasing this number causes the Job Dispatcher to check less
frequently for the job to be moved. The consequence of this is that
the volume of the jobs in the Job Repository may be higher and the
queries may take more time to complete. Tivoli Dynamic Workload
Broker servers with high job throughput may require lower values,
as low throughputs may allow higher values. In any case, this
parameter does not influence the performance for a great extend.
SuccessfulJobsM
axAge
The considerations made for the
MoveHistoryDataFrequencyInMins are also applicable for this
parameter.
UnsuccessfulJob
sMaxAge
The considerations made for the
MoveHistoryDataFrequencyInMins are also applicable for this
parameter.
ArchivedJobsMax
Age
The considerations made for the
MoveHistoryDataFrequencyInMins are also applicable for this
parameter.
MaxProcessingW
orkers
Its total value (MaxProcessingWorkers * 2 + 20) should not exceed
the maximum number of threads of the Job Dispatcher work
manager (the default is set to 50 and can be increased) and the
JDBC maximum connections (default set to 100). To check or
modify the maximum number of threads of the Job Dispatcher work
manager, open the Websphere Application Server administrative
console and go to Resources Asynchronous beans Work
managers JobDispatcherWorkManager. To check or modify
the maximum number of JDBC connections, open the
administrative console and go to Resources JDBC
providers ITDWBProvider Data sources
ITDWBDataSource Connection pools.
HistoryDataChun
k
This parameter is meant to limit the lock escalation in the Job
repository when old job data archiving occurs. Consider using
lower values if lock escalation occurs and the Tivoli Dynamic
Workload Broker server fails in archiving jobs.

Get Getting Started with Tivoli Dynamic Workload Broker Version 1.1 now with O’Reilly online learning.

O’Reilly members experience live online training, plus books, videos, and digital content from 200+ publishers.