If you performed capacity planning, you should have information about the types of users
and their expected response times. You can use this information to construct, determine the
effectiveness of, and tune your Db2 workload management
configuration.
Assume that you performed capacity planning and that the data in
the following table represents the results of this exercise for work
types and response time goals:
Table 1. Results of
capacity planning
| Type of work |
Application |
Goal |
Importance |
Expected throughput |
| Order entry |
orderentryapp.exe |
Obtain an average response time < 1 second |
High |
10 000 (both inserts and updates) per day |
| Business intelligence queries |
businessobjects.exe |
Obtain an average response time < 10 seconds |
High |
100 queries per day |
| Batch processing |
batchapp.exe |
Maximize throughput |
Low |
5000 updates per day |
| Other |
All other applications |
Best effort |
Low |
100 activities per day |
Based on the data in the preceding table, you might create three
service classes (ORDER_ENTRY_SC, BI_QUERIES_SC, and BATCH_SC) and
three workloads (ORDER_ENTRY_WL, BI_QUERIES_WL, and BATCH_WL) to assign
work to the service classes. After creating the service classes and
workloads, you might create a statistics event monitor to collect
aggregate activity information, such as the activity lifetime histogram
for each service class. Assume that the data in the following table
compares the average daily count of activities in each service class
(computed from the activity lifetime histogram) with the volumes that
were predicted in the capacity planning exercise:
Table 2. Activities each day
| Service class |
Predicted activities per day |
Actual activities per day |
| ORDER_ENTRY_SC |
10 000 |
9700 |
| BI_QUERIES_SC |
100 |
115 |
| BATCH_SC |
5000 |
5412 |
| SYSDEFAULTUSERCLASS |
100 |
85 |
The observed data indicates that the capacity planning estimates
were accurate. The data in the following table compares the average
activity lifetimes (obtained from the activity lifetime histogram)
with the response time goals determined during capacity planning and
shows that activities in the BI_QUERIES_SC service class are not meeting
their response time objectives.
Table 3. Response times
| Service class |
Response time goal |
Actual average lifetime |
| ORDER_ENTRY_SC |
< 1 second |
0.8 seconds |
| BI_QUERIES_SC |
< 10 seconds |
30 seconds |
| BATCH_SC |
|
2 seconds |
| SYSDEFAULTUSERCLASS |
|
10 minutes |
With
Db2
workload management, you can use different approaches when addressing the problem of the business
intelligence queries not meeting their response time goals:
- Limiting the concurrency of lower-importance service classes
- Allowing the operating system workload manager to provide less processor resource to
less-important service classes
- Modifying the agent and I/O prefetcher priorities for the service classes
- Using any combination of the previous three approaches
Assume that processor time is the resource that is causing the
business intelligence queries to fail to meet their goals. Also assume
that you use the operating system workload manager to give the SYSDEFAULTUSERCLASS
service class less processor resources than other service classes.
You can then capture aggregate activity information over a period
of days to observe whether the changes to the CPU allocation provide
the results that you expect. The data in the following table shows
another comparison between response time goals and actual average
lifetimes computed from the histograms after you made the operating
system workload manager changes. All service classes are now meeting
their response time objectives and, because of the processor time
reallocation, activities in the SYSDEFAULTUSERCLASS service class
have had their response times doubled.
Table 4. Response
times after reconfiguration
| Service class |
Response time goal |
Actual average lifetime |
| ORDER_ENTRY_SC |
< 1 second |
0.6 seconds |
| BI_QUERIES_SC |
< 10 seconds |
9.5 seconds |
| BATCH_SC |
|
1.5 seconds |
| SYSDEFAULTUSERCLASS |
|
20 minutes |