Version Tivoli Provisioning Manager Capacity Planning

Comments

Description

Transcript

Version Tivoli Provisioning Manager Capacity Planning

Linux on IBM System z
October 2010
Tivoli Provisioning Manager Version
7.1.1.1: Sizing and Capacity Planning
Linux end to end Performance team:
Dr. Juergen Doelle,
David Sadler
TPM Performance team:
Mark Leitch, Andrew Kaye-Cheveldayoff
1
Linux on IBM System z
October 2010
Table of Contents
About this publication ................................................................................................................................................................4
Authors...................................................................................................................................................................................4
Acknowledgments .................................................................................................................................................................4
Chapter 1. Introduction .............................................................................................................................................................5
Chapter 2. Summary .................................................................................................................................................................5
Chapter 3. Tivoli Provisioning Manager version 7.1.1.1 product description............................................................................7
Tivoli Provisioning Manager version 7.1.1.1 overview............................................................................................................7
TPM version 7.1.1.1 Scalable Distribution Infrastructure .......................................................................................................8
Provisioning server.............................................................................................................................................................9
Distribution servers ............................................................................................................................................................9
Tivoli Common Agent targets...........................................................................................................................................10
TPM version 7.1.1.1 Deployment Engine .............................................................................................................................10
Chapter 4. Benchmark environment .......................................................................................................................................12
Hardware components.........................................................................................................................................................13
Hardware used in the TPM version 7.1.1.1 study ............................................................................................................14
Software components ..........................................................................................................................................................15
Monitoring ............................................................................................................................................................................15
Chapter 5. System setup.........................................................................................................................................................16
Java RMI garbage collection interval...................................................................................................................................16
Kernel swappiness parameter .............................................................................................................................................16
TPM throttling .......................................................................................................................................................................17
TPM server tuning ................................................................................................................................................................17
DB2 tuning ...........................................................................................................................................................................19
Linux setup...........................................................................................................................................................................19
Guest setup..........................................................................................................................................................................19
Chapter 6. Benchmark description .........................................................................................................................................20
Concurrent administration scenario for SDI .........................................................................................................................20
QuickFind.........................................................................................................................................................................20
Software distribution.........................................................................................................................................................21
Concurrent administration scenario for DE ..........................................................................................................................21
QuickFind.........................................................................................................................................................................22
Deployment Engine workload ..........................................................................................................................................22
Differences between the TPM version 5.1.1.1 and TPM version 7.1.1.1 test environments.................................................23
Chapter 7. Benchmark results using the SDI interface ...........................................................................................................25
SDI results: Tuning the benchmark systems........................................................................................................................25
Comparing TPM version 7.1.1.1 results with TPM version 5.1.1.1 results............................................................................27
Chapter 8. Benchmark results using the Deployment Engine interface .................................................................................30
Using the DE interface and the concurrent administrator workload mix ..............................................................................31
Using the Deployment Engine interface and a 100% Deployment Engine workload ..........................................................36
Scaling the workflow and administrator ratio with a constant number of total workflows.................................................36
Scaling workflows per administrator ................................................................................................................................38
Page response times ...........................................................................................................................................................41
Scaling the number of administrators with a 100% DE workload.....................................................................................42
Scaling z/VM LPAR memory size .....................................................................................................................................43
Comparing SDI and DE....................................................................................................................................................44
Chapter 9. Memory overcommitment......................................................................................................................................45
z/VM memory management overview ..................................................................................................................................45
2
Linux on IBM System z
October 2010
Execution times....................................................................................................................................................................49
Working set size of the guests .............................................................................................................................................51
What happens with the pages .............................................................................................................................................52
Chapter 10. I/O bandwidth......................................................................................................................................................55
Network throughput for TPM, DB2 and DCD depot servers ................................................................................................55
Network throughput from all servers ....................................................................................................................................56
Chapter 11. Sizing recommendations.....................................................................................................................................57
100% DE workload...............................................................................................................................................................58
60% QuickFind and 40% DE workload ................................................................................................................................60
60% QuickFind and 40% SDI workload ...............................................................................................................................60
Memory ................................................................................................................................................................................62
Appendix A. Tuning steps........................................................................................................................................................64
TPM system tuning...............................................................................................................................................................64
DB2 system tuning ...............................................................................................................................................................66
ITDS system tuning ..............................................................................................................................................................67
DCD depot system tuning....................................................................................................................................................68
Setting the Java garbage collection interval to one hour .....................................................................................................69
Appendix B. Guest setup.........................................................................................................................................................74
z/VM Linux guest setup........................................................................................................................................................74
TPM guest setup ..................................................................................................................................................................74
DB2 guest setup ..................................................................................................................................................................75
ITDS guest setup .................................................................................................................................................................75
DCD depot guest setup .......................................................................................................................................................76
Appendix C. How to define the throttles ..................................................................................................................................77
References...............................................................................................................................................................................78
Notices .....................................................................................................................................................................................79
Terms and conditions ..............................................................................................................................................................81
3
Linux on IBM System z
October 2010
About this publication
This document provides results for Tivoli® Provisioning Manager (TPM) version 7.1.1.1 on IBM
System z10™ using a variety of concurrent administrator workloads.
Authors
Linux® end to end Performance team: Dr. Juergen Doelle, David Sadler
TPM Performance team: Mark Leitch, Andrew Kaye-Cheveldayoff
Acknowledgments
Special Thanks to Giorgio Corsetti, Antonio Perrone, Fabio Fava, and Ugo Madama from the IBM
Rome performance team for their support and guidance in benchmark and TPM-related questions.
4
Linux on IBM System z
October 2010
Chapter 1. Introduction
This section introduces IBM Tivoli Provisioning Manager (TPM) and the TPM version 7.1.1.1 study.
IBM Tivoli Provisioning Manager (TPM) is an enterprise management application. It provides a
centralized and intuitive interface to automate data center provisioning activities and manage IT
resource life cycles. TPM integrates with various devices to enable highly accurate server
provisioning and software deployment. TPM version 7.1.1.1 for Linux on IBM System z® has recently
been made available as an update to TPM version 5.1.1.1.
This study is referred to as 'the TPM version 7.1.1.1 study' for the remainder of this document.
This document provides results for TPM version 7.1.1.1 on an IBM System z10 using various
concurrent administrator workloads. These workloads emulate system provisioning as would be
typical in a customer environment.
Chapter 2. Summary
This study evaluated the performance of Tivoli Provisioning Manager (TPM) version 7.1.1.1 on
Linux for IBM System z, as a follow-up to an earlier study using TPM version 5.1.1.1. A primary
intention of this study is to generate data for sizing and capacity planning.
The TPM version 5.1.1.1 study can be found in this location:
http://www.ibm.com/developerworks/linux/linux390/perf/tuning_pap_websphere.html#tpm
TPM version 7.1.1.1 is a major redesign of the TPM product, which behaves very differently than the
earlier TPM version 5.1.1.1. Also, the significant changes in workload and environment makes it
difficult to compare the TPM version 7.1.1.1 results with the prior version 5.1.1.1 results. For
example, the current workload can be considered more comprehensive and heavier when compared
to the earlier version 5.1.1.1 workloads. In general, TPM version 7.1.1.1 demonstrates slightly
reduced CPU utilization, with an associated shift of CPU load from the database server to the TPM
(application) server. In addition to the slightly reduced CPU requirements, the TPM server and the
database server require more memory in the new environment.
In order to achieve the new study results, a successful tuning was initially done. This phase almost
doubled the number of administrators served per minute, and increased the efficiency in terms of the
amount of work done per CPU (between 14% and 18%) compared to the out-of-the-box installation.
The two interfaces of TPM, Software Distribution Infrastructure (SDI) and Deployment Engine (DE),
were tested. For the DE interface, a new benchmark was developed to emulate DE-driven file
distribution. Both interfaces are used with the standard workload, called 'concurrent administrators
workload'. This workload runs a mixture of 60% QuickFind (checking the software levels of a
5
Linux on IBM System z
October 2010
possible set of targets) and 40% File Distribution. The DE interface was also tested with a 100% DE
workload variation.
Comparing the mixed workload for SDI and DE revealed very similar behavior. This behavior was
expected, because 60% of the workload is doing the same work (QuickFind scenario). With regards
to the different File Distribution mechanisms, the study shows that the CPU utilization is at a slight
advantage for SDI, with higher workloads.
Two test scenarios were used with the 100% DE workload
 Scaling the ratio of workflows and administrators with a constant number of total workflows.
 Scaling the workflows per administrator with a constant number of administrators.
When increasing the number of administrators with a constant total number of workflows, the
additional effort (associated with the larger number of administrators) affected the execution times of
the test only at the higher number of administrators. In general though, as the number of
administrators increases, the CPU load also increases steadily. Scaling workflows per administrator
with a constant amount of 100 administrators shows the impact of the two types of throttling (global
and per task concurrency). These throttling mechanisms are used to control the load on the system at
the creation point, and prevent an overloaded system from leading to unpredictable behavior due to
system resource constraints (CPU or memory).
A memory overcommitment test was done using the mixed DE workload, to determine useful
guidelines to avoid system resource issues caused by an excessively high level of memory
overcommitment. As the size of main memory is decreased, fewer guest memory pages can be held in
real memory, and more pages must be moved to the paging devices. Moving of memory to paging
devices leads to waiting guests. The best performance is observed when the total memory
corresponds to the sum of the WSS sizes from the TPM and DB2® servers, in the scenario without
any memory overcommitment. These servers are the ones with the highest memory requirements
with intensive memory usage.
An important factor for that step is that z/VM® handles the reduction of the LPAR memory size by
reducing the WSS size without any paging activity. This reduction of the WSS size leads to better
performance than when the environment had plenty of memory. Decreasing the LPAR memory size
further, to the sum of the size of the database memory and the Java™ heap (a decrease of 60%),
shows a very moderate performance decrease (increase in execution time by 14%), while the system
already shows significant effort for paging. Considering the large amount of saved memory, this size
seems to be a highly acceptable compromise regarding resource saving and operability. However,
decreasing the memory further results in execution time increasing so dramatically that this
reduction is to be avoided. The conclusion is that in a TPM environment, the physical memory size
must be at least the sum of the database memory and Java heap. Of course, more memory has the
potential to provide a faster system.
6
Linux on IBM System z
October 2010
The page response times for the SDI and DE scenarios are a comparison point in the study. The SDI
workload by design distributes more of the workload to infrastructure outside of the management
server. The DE workload drives higher management server resource utilization, which has an impact
on page response times. Given that the DE workloads can consist of custom workflows, the
recommendation for running DE workloads at high scale is to ensure that custom code efficiently
uses management server resources, coupled with effective global and local task throttling to further
control server utilization and minimize impact to the users.
The network bandwidth required for the communication between the TPM server, administrators,
and the other TPM components (DB2, ITDS) is moderate in all tested scenarios, and can be easily
driven with one OSA card attached to a VSWITCH. However, the network load from the Dynamic
Content Delivery (DCD) depot (or the file distribution system) produces a high load, not in terms of
throughput, but in terms of I/O requests per second. Therefore, a separate network connection for
the interface for the file distribution to the end points is recommended, to ensure that other
communication is not affected.
Finally, at the end of the study, sizing recommendations are given for both CPU and memory based
on the tested scenarios.
Chapter 3. Tivoli Provisioning Manager version 7.1.1.1 product description
A general overview of Tivoli Provisioning Manager version 7.1.1.1 is provided, along with a
description of the Scalable Distribution Infrastructure (SDI) and the Deployment Engine (DE).
Tivoli Provisioning Manager version 7.1.1.1 overview
Tivoli Provisioning Manager (TPM) version 7.1.1.1 is a major redesign of the TPM infrastructure,
with enhanced functionality.
TPM version 7.1.1.1 offers the next generation of data center management capabilities. It is based on
the earlier TPM version 5.1.1.1 release, with a number of demonstrated improvements.
The most significant improvement is that TPM version 7.1.1.1 is integrated with the IBM Tivoli
Process Automation Engine (TPAE). This base provides a common integration point for TPAEenabled products (such as Tivoli Service Request Manager, Tivoli Service Automation Manager).
Through this common integration, common services are available across the products including
Database Management System access, security audit enablement, and user interface customization.
In terms of functionality, TPM version 7.1.1.1 offers a number of improvements when compared to
TPM version 5.1.1.1. Some of these improvements include:
1. New user interface capabilities, including start centers based on roles
2. Compliance automation, including closed-loop desired state management
3. Patch management automation
7
Linux on IBM System z
October 2010
4.
5.
6.
7.
Software provisioning automation
Support for task invocation from IBM Service Management processes
Virtualization and server management enhancements, with enhanced support for cloud computing
Reporting enhancements, including exploitation of the Business Intelligence and Reporting Tools
(BIRT) engine
8. Additional platform support for both the TPM server and managed targets
From a server infrastructure perspective, TPM version 7.1.1.1 offers the following improvements
when compared to TPM version 5.1.1.1:
 64-bit exploitation
 DB2 version 9.5, with out-of-the-box usage of database autonomic support for self-tuning memory
management
 WebSphere® Application Server Network Deployment (WAS ND) version 6.1
 Java Runtime Environment (JRE) version 1.5
 Java Database Connectivity (JDBC) Type 4 exploitation
 Deployment Engine performance improvements, including global throttle support and theability to
achieve higher task throughput with reduced overall management server impact
 Advanced configuration options for network support (Internet Protocol Version 6) and security
(Federal Information Processing Standard 140-2)
As a result of these improvements, TPM version 7.1.1.1 provides a superior base for enterprise data
center management, when compared to the earlier version of TPM. This superiority shows greater
potential for out-of-box performance, as well as reduced cost of ownership for managing TPM. A
fundamental goal of this paper is to demonstrate the performance aspects of TPM version 7.1.1.1,
including direct comparisons with TPM version 5.1.1.1.
TPM version 7.1.1.1 Scalable Distribution Infrastructure
The Scalable Distribution Infrastructure (SDI) is one of the interfaces of TPM used to manage
software distribution.
The Scalable Distribution Infrastructure (SDI) is used to centrally manage software distribution. Core
services such as the Dynamic Content Delivery (DCD) and Device Management Service (DMS)
perform the actual software distribution and federated job management operations.
The SDI includes the following main components:
 Provisioning server
 Distribution servers
 Tivoli Common Agent targets
8
Linux on IBM System z
October 2010
Provisioning server
The provisioning server is the server on which Tivoli Provisioning Manager (TPM) is installed. Table
1 lists the components of the SDI that are installed on the provisioning server.
Table 1. SDI components installed on the provisioning server
Component
Description
Dynamic Content
Delivery
Management
Center
• Provides centralized control of the upload, replication, and download
of files.
• Monitors the state of depot servers, and stores statistics about file
data and download activity.
• Implements a distribution policy that sends bulk data to some or all
the distributed depot servers, in advance of when that data is
needed.
Device Manager
Federator
• Resides on the provisioning server and is configured to act as a
federated server.
• Implements a job distribution policy that provides incoming jobs to all
the regional agents.
Agent Manager
TPM uses the Common Agent Services for software distribution and
compliance. Common Agent Services provides an infrastructure for
managing the computer systems in your environment.
The Agent Manager is the server component of the Common Agent
Services. Through its functions, the clients obtain information about
agents and resource managers.
• The Agent Manager performs these functions:
– Enables secure connections between managed target
computers.
– Maintains the database information about the target computers
and the associated agents and sub-agents running on them.
– Processes queries against that database from resource
managers.
The Agent Manager includes a registration service, which performs
these functions:
– Processes security certificates and registration requests.
– Tracks common agents and resource managers.
– Collects and forwards status.
Distribution servers
Distribution servers connect to the provisioning server, or directly to the target computers. Table 2
lists the components of the distribution servers.
9
Linux on IBM System z
October 2010
Table 2. Distribution server components
Component
Description
Device Manager
Federated Agent
• The agents are installed on distribution servers and are configured to
communicate with the federator to get command jobs, and to
distribute them to the set of clients installed on the target computers.
• The agents on the distribution server periodically communicate with
the federator and detect when there is network connectivity.
Dynamic Content
Delivery
• Depots act as a file server, ensuring that endpoints can download
files without putting bandwidth strain on the enterprise network.
• The Dynamic Content Delivery depots communicate with the
management server to check for published files that should be
cached locally.
Tivoli Common Agent targets
Distribution servers connect to the target computers. Table 3 lists the components of the target
computers.
Table 3. Target computer components
Component
Description
Device Manager Subagent
Clients are installed as device manager subagents on the target
computers. The target computers may be geographically remote
form the TPM server, for example in a branch office configuration.
Clients are used for receiving job tasks and returning results to the
agents.
Dynamic Content Delivery
Subagent
Subagents are installed on all the managed systems or target
computers, in order to download files from depot servers or from
other clients.
Tivoli Common Agent
• Resides on the target computers, and acts as a common
container for all the subagents.
• The deployed agent software collects data from, and
performs operations on, managed resources on behalf of a
Tivoli management application. The deployed agent
software provides shared system resources and secure
connectivity.
TPM version 7.1.1.1 Deployment Engine
The Deployment Engine (DE) a TPM interface that is an alternative to SDI, and is also used to
manage software distribution.
10
Linux on IBM System z
October 2010
The Deployment Engine (DE) provides a task execution engine at the core of TPM. The DE runs
automation scripts that are typically referred to as 'provisioning workflows'. The provisioning
workflows can invoke operations directed to manage targets. These are key differences between the
SDI and DE approaches:
 DE-based provisioning workflows do not require that the Tivoli Common Agent (TCA) is installed
on the managed target (SDI does require the TCA).
 DE-based provisioning workflows are run on the TPM server, while SDI-based operations run only
on the managed target.
The DE has different functional characteristics compared to the SDI infrastructure. The DE also has
different performance characteristics. DE-based workloads impact TPM server capacity and sizing.
For TPM version 7.1.1.1, there are two notable performance improvements:
Global throttle support to provide DE resiliency, even under heavy workloads.
1.
Improved DE efficiency, in particular a large reduction in DBMS server workload when running
DE-based workflows.
As a result, TPM version 7.1.1.1 DE offers the ability to achieve higher task throughput with
increased resiliency, and reduced management server impact when compared to earlier TPM
releases.
11
Linux on IBM System z
October 2010
Chapter 4. Benchmark environment
This section describes the hardware and software setup for the TPM environment, as Linux guests of
a z/VM LPAR on an IBM System z10.
The benchmark environment used in the TPM version 7.1.1.1 study consists of an IBM System z10
processor with four guests. Figure 1 is an illustration of the benchmark environment for the base
tests. The IBM Tivoli Directory Server (ITDS) guest represents a specific implementation of a
Lightweight Directory Access Protocol (LDAP) enterprise directory server.
Figure 1. Benchmark environment for the TPM version 7.1.1.1 base tests
12
Linux on IBM System z
October 2010
Hardware components
This section describes the physical and virtual resources assigned to the z/VM LPAR and the Linux
guests that host the TPM environment. The network configuration and the setup to drive the
workload are also described.
The test environment has a z/VM system with several guests to run the various components. Table 4
describes the hardware components used for the test environment.
Table 4. Hardware used in the test environment of the TPM version 7.1.1.1 study
Host
System
Operating
system
Number of
CPUs
z/VM
z/VM 5.4
10
Memory
Network
Architecture
28 GB + 2 GB
extended
two OSA 1 Gb and two
VSWITCHs (with attached
OSAs)
System z10
LPAR
WebSphere
Linux
6
Application
RHEL 5.4*
Server for TPM
8 GB - 13.5 GB VSWITCH and one OSA 1
Gb
z/VM guest
ITDS (LDAP)
server
Linux
1
RHEL 5.4*
1.5 GB - 2 GB
VSWITCH
z/VM guest
DB2 (TPM)
Linux
4
RHEL 5.4*
8 - 12 GB
VSWITCH
z/VM guest
DCD Depot
(file server)
Linux
1
RHEL 5.4*
1 - 2 GB
VSWITCH and one OSA 1
Gb
z/VM guest
Total
System z10
z/VM
virtual:
physical:
IBM System z LPAR
12
10
28 GB
28 GB +
2 GB extended
two VSWITCHs
two OSA 1 Gb
Client workstations
®
One IBM Rational Linux RHEL
Performance
5.3 or later
Tester
2
2 GB
One 1 Gb
IBM System x
6 endpoint
simulators
2-4
2 GB
One 1 Gb
System x
Linux RHEL
4.3 or later
* TPM version 5.1.1.1 run on an existing Linux SLES 10 SP1 system
Note: CPU and memory allocations were varied according to the individual test case.
13
®
Linux on IBM System z
October 2010
Hardware used in the TPM version 7.1.1.1 study
The TPM version 7.1.1.1 study used an IBM System z10, between six and nine endpoint simulators,
two Rational Performance Test (RPT) systems, two VSWITCHs, three Gigabit Ethernet OSA cards,
and an IBM System Storage™ DS8000® device.
The following hardware components were used for the TPM version 7.1.1.1 study. See also Table 4.
 One IBM System z10 LPAR with:
–
–
–
–
10 IFLs
28 GB RAM
2 GB Expanded Storage
One z/VM guest for each of these software components:
x TPM Server
x Dynamic Content Delivery (DCD) Depot Server
x DB2 Server
x IBM Tivoli Directory Server (ITDS)
 Between six and nine endpoint simulators
 These are IBM System x processors with the Linux operating system, used to drive a simulated
workload of thousands of target computers. Red Hat Enterprise Linux (RHEL) 4U3 dual core and
quad core x86-based processors were used.
 Two IBM Rational Performance Testers (RPTs). One system was required to run the Rational
Performance Tester software, and one system was used to drive the load for the concurrent
administration scenarios. Red Hat Enterprise Linux Server release 5.3 was on the load driving
system.
 A VSWITCH with an attached OSA port for communication between TPM, DB2, ITDS, and to the
administrators and the endpoints.
 A VSWITCH with an attached OSA port for the DCD depot server, connecting to the simulated
endpoints.
 An IBM System Storage DS8000 device providing 500 GB DASD (approximately 40% of this
space was used for the benchmark).
14
Linux on IBM System z
October 2010
Software components
This section describes the software products and versions used for the TPM version 7.1.1.1 study.
The following software components were used in the TPM version 7.1.1.1 study:
 Red Hat Enterprise Linux (RHEL) Server release 5.4
 TPM version 7.1.1.1 (64-bit). The benchmark is based upon TPM version 7.1.1.1, which includes:
WebSphere Application Server Network Deployment 6.1 FP23, which includes IBM HTTP Server
6.1 FP23
 IBM DB2 version 9.5 FP 5 (64-bit)
 IBM Tivoli Directory Server (ITDS) version 6.2
 One DCD depot
 IBM Rational Performance Tester version 8.1.1, which was used to drive concurrent administration
for the IBM System z performance benchmark.
 TPM Agent Simulator
The agent simulator is used to simulate file distribution scenarios across thousands of managed
targets, using a few physical machines. In this study, an internal end point emulator was used to
represent a total of 6,000 virtual machines (endpoints). Each emulated endpoint looks like a real
endpoint to the TPM server infrastructure, meaning that it had its own IP address, GUID, home
directory and SSL certificates. The agent simulator used in this benchmark has several
enhancements when compared to earlier benchmarks. These enhancements improve the accuracy of
the simulator, when modeling a typical customer environment.
Monitoring
Several tools were used for monitoring test results, depending on the monitoring targets (either Linux
or z/VM).
The monitoring tools sadc and sar were used for Linux monitoring. For z/VM guest monitoring, the
z/VM performance toolkit was used.
Special focus is on the following reports:
 CPU
– Guest CPU: FCX112 General User Resource Utilization
– System CPU: FCX144 Processor Activity, by Time
 User wait states: FCX135 Average User Wait State Data, by Time
 User memory: FCX113 User Paging Activity and Storage Utilization
 Virtual network: FCX269 - Virtual Network Device Activity
15
Linux on IBM System z
October 2010
Chapter 5. System setup
To tune the system, various parameters of the environment were adapted and optimized to the
workload.
Java RMI garbage collection interval
One tuning step was to set the Java RMI garbage collection interval to one hour (from the standard
configuration of one minute). This change leads to much better utilization of the Java heap. The
improvement in the Java heap utilization was correlated with a higher memory utilization on the
TPM server. The guests were then re-sized to the minimum values that could be used without
approaching a point of noteworthy swapping.
For instructions on how to perform the RMI garbage collection modification, see Setting the Java
garbage collection interval to one hour. Note that this configuration is part of the default TPM
configuration beginning with TPM version 7.2.
Kernel swappiness parameter
The swappiness value, which is exported to the /proc/sys/vm/swappiness file, is a parameter
that sets the kernel's balance between reclaiming pages from the page cache and swapping out
process memory. The reclaim function works (in a very simplified way) by calculating these numbers:
distress value
A measure of how much trouble the kernel is having freeing memory. The first time that the kernel
decides that it must start reclaiming pages, the distress value is zero. If more attempts are required,
that value increases, approaching a maximum value of 100.
mapped_ratio
An approximate percentage of how much of the system's total memory is mapped (part of a process's
address space), within a given memory zone.
vm_swappiness
The swappiness parameter, which is set to 60 by default.
Using these numbers, the kernel calculates its swap_tendency using this formula:
swap_tendency = mapped_ratio / 2 + distress value + vm_swappiness
If the swap_tendency is less than 100, the kernel reclaims only page cache pages. When the
swap_tendency is greater than 100, however, pages that are part of some process's address space are
also considered for reclamation. So, if life is easy, with a vm_swappiness value of 60, and distress
value of zero, the system does not process memory until it reaches 80% of the total.
16
Linux on IBM System z
October 2010
Users who would like to never see application memory swapped out can set vm_swappiness to zero.
This setting causes the kernel to ignore process memory until the distress value becomes quite large.
TPM throttling
Throttling is an effective mechanism used by TPM for managing workloads at high scale. Without
throttling, the system load might exceed system capacity either for CPU or memory. The right sized
throttle improves the resiliency and throughput of the system.
For the SDI, throttling is generally accomplished by configuring the agent polling period that
determines the rate at which agents contact the management server. For the Deployment Engine,
there are two throttle points that could be utilized:
Task level concurrency
This throttle point determines how many workflows run concurrently for a specific task. It is an
effective throttle per administrator, and ensures that each administrator has the chance to submit
and run workflows. One administrator cannot dominate system resources by submitting a task before
other administrators.
Global concurrency
This throttle point determines how many workflows run globally for each instance of the Deployment
Engine. This feature was introduced in TPM version 7.1.1.1.
For the task level concurrency, the default value is 5. A value of 10 is used in the TPM version
7.1.1.1 study, and is the recommended value.
For the global concurrency, the recommended setting depends on the workload profile and available
system resources. The recommendation is:
1. Start with a value of 600 (default is 1000), and monitor the system using FCX112 General User
Resource Utilization report. The parameter to look at is the %CPU parameter.
2. The value can be increased, in increments of 50, as long as the TPM guest is not fully utilized.
3. When the system is fully utilized, the value can be decreased, in increments of 50.
Appendix C. How to define the throttles provides detailed instructions on how to manage the throttle
points.
TPM server tuning
The TPM server (including WebSphere) settings are defined in TPM system tuning.
Understanding the relevant Java Virtual Machine (JVM) instances for the TPM server, and their
associated JVM heaps, is critical to TPM server tuning. Table 5 shows the most important JVM heap
memory allocations for the TPM server.
17
Linux on IBM System z
October 2010
Table 5. TPM heap size tuning
Heap
Minimum
size
Maximum
size
Installation Used for
LWI
64 MB
1.7 GB
Default
DE
CAS
(server1)
1 GB
2 GB
Tuned
SDI (Agent
This heap size has been
manager CAS increased to accommodate the
registration) agent community used for the
SDI-based scenarios.
Recommendation
This heap should never be
reduced in size. In certain
situations (described below), it
might be worth increasing the
heap allocation.
If the SDI infrastructure and
TCA are not used in
deployment, this heap size can
remain at the default settings.
MXServer 4 GB
6 GB
Tuned
User Interface This heap size has been
(UI), SDI
increased to support the high
concurrency UI workloads of
the benchmark. The heap size
could be reduced (minimum 2
GB, maximum 4 GB) for
reduced user workloads.
DMGR
512 MB
1 GB
Default
WebSphere
ND
(deployment
manager of
WebSphere
ND)
Not relevant to workload. This
heap size should not be
changed.
Node
Agent
50 MB
256 MB
Default
WebSphere
ND
Not relevant to workload. This
heap size should not be
changed.
Total
Approx. 5.6
GB
Approx. 11
GB
The most critical heap is the MXServer heap. This heap has been increased significantly to support
both our large scale user and SDI workloads. Without this tuning our workloads would not have been
sustainable. In addition, the CAS (server1) heap has also been increased to support a high agent
workload. The LWI heap primarily impacts the Deployment Engine workload, though it also includes
some base SDI engines as well.
18
Linux on IBM System z
October 2010
It is worthwhile to note that the benchmark tests used the default LWI heap. In general, the global
and task level throttles for the Deployment Engine have a direct relationship to the recommended
heap size. The benchmark tests demonstrate excellent throughput based on the default
configuration. However, it is possible to increase overall Deployment Engine throughput by
increasing the global and task throttles, along with an associated increase in the LWI heap allocation.
In summary, heap tuning should be done based on the expected workload. For the following
workloads, the heaps that are relevant are listed:
 UI only workload: MXServer
 UI and SDI based workload: MXServer, CAS
 UI and DE based workload: MXServer, LWI
 UI, SDI, and DE based workload: MXServer, CAS, LWI
DB2 tuning
The DB2 specific settings are defined in DB2 system tuning. Note that DB2 was upgraded to DB2
version 9.5 FP 5 (from FP 3a), because the memory management in FP 5 is improved.
Linux setup
The Linux setup for TCP/IP and system limits for each server is described in Appendix A. Tuning
steps.
Guest setup
The z/VM guest setup is described in Appendix B. Guest setup.
19
Linux on IBM System z
October 2010
Chapter 6. Benchmark description
The benchmark used in the TPM version 7.1.1.1 study is described in detail, including test scenarios
and tuning, results from a TPM version 5.1.1.1 study from 2009, and changes to the TPM version
5.1.1.1 environment to improve performance.
Concurrent administration scenario for SDI
This section describes the concurrent administration workload for the SDI interface.
The concurrent administration scenario for SDI represents typical use of TPM for a specific number
of administrators. They perform TPM user interface operations and drive a number of operations for
managed endpoints.
This scenario involves the following parameters:
 Number of concurrent administrators: 10, 50, 100
 Number of endpoints managed per administrator: 100
 Number of administrator activities: two, specified as follows:
QuickFind
60% of the administrators, iterating 10 times each
Software distribution
40% of the administrators, iterating 10 times each
A more detailed description of each individual activity is given in the next sections.
QuickFind
This scenario represents a TPM administrator who logs in to the TPM user interface and performs
some tasks.
1. Log in to the Start Center
2. From the Start Center, use the data model object finder defined in the Start Center to filter for a
specific provisioning computer.
3. Select filtered target to show general computer details.
4. Display the hardware details.
5. Display the software details.
6. Return to the Start Center.
7. Logout.
20
Linux on IBM System z
October 2010
Software distribution
This scenario represents a TPM administrator who logs in to the TPM user interface and performs
some software distribution tasks.
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
Log in to the Start Center.
From the Start Center, click GoTo -> Deployment -> Software Management -> Software
Product Distribution.
From the Software Product Distribution page, click Select Software.
From the pop-up menu, filter for the chosen software module.
Select the software module.
Click OK.
From the Software Product Distribution page, in the target section click Select button then
select groups.
From the pop-up menu, filter for the correct Provisioning Group.
Select the Provisioning Group.
Click OK.
From the Software Product Distribution page, click Submit.
From the Provisioning Task Tracking page, click Refresh.
Wait 10 seconds and then click Refresh.
Repeat the previous step 5 times.
Return to the Start Center.
Logout.
Concurrent administration scenario for DE
This section describes the concurrent administration workload for the DE interface.
The concurrent administration scenario represents typical use of TPM for a specific number of
administrators. They perform TPM user interface operations and drive a number of operations for
managed endpoints. To complement the SDI-based scenario described in the previous sections, a
DE-based scenario has been constructed to demonstrate the TPM version 7.1.1.1 DE improvements.
This scenario uses the following parameters:
 Number of concurrent administrators: 10, 50, 100
 Number of endpoints managed per administrator: 100
 Number of administrator activities: two:
QuickFind
60% of the administrators, iterating 10 times each
Deployment Engine Workload
40% of the administrators
A more detailed description of each activity is given in the following sections.
21
Linux on IBM System z
October 2010
This study also describes a 100% DE workload. This workload involves 100% of the administrators
exercising the DE aspect of the workload (instead of the standard distribution of 60% QuickFind and
40% DE).
QuickFind
This scenario represents a TPM administrator who logs in to the TPM user interface and performs
some tasks.
1. Log in to the Start Center
2. From the Start Center, use the data model object finder defined in the Start Center to filter for a
specific provisioning computer.
3. Select filtered target to show general computer details.
4. Display the hardware details.
5. Display the software details.
6. Return to the Start Center.
7. Logout.
Deployment Engine workload
This scenario represents a TPM administrator who logs in the TPM user interface and performs a
Deployment Engine (DE) task.
1. Log in the Start Center.
2. From the Start Center, click GoTo -> Task Management -> Provisioning Tasks -> Task
Definitions.
3. From the Task Definitions page, click MyTask (established as a favorite task).
4. Select Action -> Run Provisioning Task.
5. Select Targets -> Group.
6. Select the Provisioning Group.
7. Click Submit.
8. From the Provisioning Task Tracking page, click Refresh.
9. Wait 10 seconds and then click Refresh.
10. Repeat the previous step 5 times.
11. Return to the Start Center.
12. Logout.
22
Linux on IBM System z
October 2010
The deployment engine workload is highly dependent on the actual task being invoked. The
deployment engine task used in the benchmark is intended to simulate the installation of a package
on a remote system (endpoint). The simulation consists of these steps:
1.
General initialization, including:
 Text and Java processing to determine the script invocation string.
 Performing a Data Center Model (DCM) query to determine the endpoint host name.
2.
Running the script to simulate package installation using ssh, including:
 Scriptlet invocation to determine the local TPM instance identifier.
 Performing the device execute command to run the package installation script on the TPM
server. The script itself uses ssh to connect to the endpoint and start a sequential set of timers
to simulate the following steps:
3.
a.
Checking if the installation package already exists on the endpoint (timer value 5
seconds ± 20%).
b.
Copying the installation package to the endpoint (timer value 60 seconds ± 20%).
c.
Unpacking and installing the package on the endpoint (timer value 900 seconds ±
20%).
Emulating the activity using a timer is done to ensure consistent behavior for all end
point operations, and to minimize the impact of capacity limitations caused by the end
point simulator systems.
Performing a DCM import to update the data center model information related to the endpoint.
The DCM import XML file is generated and customized for each endpoint.
Differences between the TPM version 5.1.1.1 and TPM version 7.1.1.1 test environments
Due to historical reasons, the various environments from the different tests and test phases are
different. It is important to understand the impact of the differences to the workload, in order to
interpret the results.
When comparing the current results on TPM version 7.1.1.1 (the 2010 benchmark described in this
paper) with the results from the TPM version 5.1.1.1 test (the 2009 benchmark published
previously), it is important to understand the differences in the test environment, and the impact of
these differences on the test results.
The TPM version 5.1.1.1 results are available at this location:
http://www.ibm.com/developerworks/linux/linux390/perf/tuning_pap_websphere.html
23
Linux on IBM System z
October 2010
Table 6 summarizes the differences between the TPM version 5.1.1.1 and TPM version 7.1.1.1
environments. Three environments are described:
TPM version 5.1.1.1 (2009)
The environment of the 2009 IBM System z10 benchmark that has been previously published.
TPM version 5.1.1.1 (2010)
An iteration of the 2009 benchmark on the latest system. The intent was to provide a baseline on the
current environment as a point of comparison.
TPM version 7.1.1.1 (2010)
The new TPM version 7.1.1.1 benchmark, which is the primary subject of this paper.
Table 6. Test environments: TPM version 5.1.1.1 compared to TPM version 7.1.1.1
Item
TPM
version
5.1.1.1
(2009)
TPM version TPM version
5.1.1.1
7.1.1.1
Impact
(2010)
(2010)
Linux distribution
SLES 10
SP1
SLES 10 SP1 RHEL 5.4
Polling period
3600
seconds
1800 seconds 720 seconds The shorter polling period leads to
a heavier load on the system.
Number of loaded
end points
20,000
6000
30,000
The larger number of loaded end
points leads to larger tables and
indexes. Queries that work on all
data need more time and increase
the load on the database.
Number of active
end points
20,000
6000
6,000
The large number of endpoints
increases the length of the test
until all endpoints are served.
However, the load on the system is
determined by the polling period.
Benchmark
V5
V5
benchmar benchmark
k
V7
benchmark
Results are comparable in a
limited manner.
V5
Package dependencies might be
different, no performance impact
Endpoint emulator
V5
V7
No impact is expected.
Number of end
points per system
2222/2224 2222/2224
1000
The more end points that the
system emulates. the heavier is the
load on the end point, and there is
a greater chance that end points
become a bottle neck.
File size
100 MB
10 MB
The larger file size is related to
more effort expended by the
depot, and higher network traffic.
10 MB
24
Linux on IBM System z
October 2010
Chapter 7. Benchmark results using the SDI interface
These results are for the concurrent administrator workload using the SDI interface. The
environment was tuned and the results are compared with the earlier version, TPM version 5.1.1.1.
For this test, the number of concurrent administrators was scaled from 10, to 50, to 100. The
workload is described in Concurrent administration scenario for SDI.
SDI results: Tuning the benchmark systems
These tests compare results of TPM version 7.1.1.1 using the SDI interface, before and after the
systems are tuned to maximize throughput.
This test compares of the out-of-the-box and the tuned setup for throughput and CPU load. Figure 2
shows the throughput modifications measured in administrators served per minute. Figure 3 shows
the CPU load of the z/VM LPAR measured in multiples of IFLs accordingly.
A more detailed description of the tuning and system setup can be found in System setup, Appendix
A. Tuning steps, Appendix B. Guest setup, and Appendix C. How to define the throttles.
Figure 2. Throughput measured in number of administrators served per minute, when scaling
the number of concurrent administrators
25
Linux on IBM System z
October 2010
Figure 3. CPU load of the z/VM LPAR when scaling the number of concurrent administrators
Observation
Applying the tuning steps doubles the number of administrators served per minute for 10 and 50
administrators. The highest workload with 100 concurrent administrators shows a lower
improvement, but the value is still greater than 20%. The CPU load increases according to the higher
throughput, but not according to the increase in throughput, except for the case with 10 concurrent
administrators.
Conclusion
These tuning steps could be considered as a very successful way to improve the throughput. It also
increases the amount of work done per CPU between 14% and 18%, except for 10 concurrent
administrators. Increasing the RMI garbage collection interval reduces the frequency of timertriggered garbage collection calls from one every minute to one every hour. This reduction leads to a
much more efficient usage of the Java heap, resulting in higher throughput, and lower CPU
utilization. This change has been kept for all remaining tests in this study, and is the default behavior
for TPM version 7.2.
For instructions on how to perform the RMI garbage collection modification, see Setting the Java
garbage collection interval to one hour.
26
Linux on IBM System z
October 2010
Comparing TPM version 7.1.1.1 results with TPM version 5.1.1.1 results
These tests compare results of TPM version 7.1.1.1 with TPM version 5.1.1.1 in the new
environment (referred to as new TPM version 5.1.1.1) and the original TPM version 5.1.1.1 results.
Figure 4 shows the rate of administrators being served per minute, when scaling the number of
concurrent administrators from 10, to 50, to 100.
Figure 4. Throughput measured in administrators served per minute, when scaling the number
of concurrent administrators
Observations
At a value of 10 concurrent administrators, the data from all three environments is very close.
However, the TPM version 5.1.1.1 results in the new environment are slightly higher than the TPM
version 7.1.1.1 results. For the other measurement points, the TPM version 7.1.1.1 throughput is
much higher. In relation to the TPM version 5.1.1.1 data from the prior test environment, the
behavior of TPM version 7.1.1.1 is now comparable, but the workload is significantly higher, which is
demonstrated by the reduction of the polling period by a factor of five.
Conclusions
These results demonstrate clearly the limitation of comparing these results, especially when the test
conditions are quite different. The new TPM version 5.1.1.1 environment comes closer to the current
TPM version 7.1.1.1 environment, but the TPM version 7.1.1.1 workload could be considered much
more challenging, because of a reduction of the polling period by a factor of three, and a five times
larger size of the database. Keeping this factor in mind, the results show that TPM version 7.1.1.1
manages this higher workload much better than TPM version 5.1.1.1.
27
Linux on IBM System z
October 2010
Figure 5 shows the LPAR CPU load from these tests. This figure shows how much workload in terms
of administrators per minute can be driven by 1% CPU.
Figure 5. The amount of workload that can be driven by 1% CPU, expressed in terms of
administrators per minute, when scaling the number of concurrent administrators
Observations
The new TPM version 5.1.1.1 environment drives the most workload with a certain amount of CPU,
except for 100 concurrent administrators, where it degrades. TPM version 7.1.1.1 starts lower, but it
does not show the degradation at 100 concurrent administrators. The older TPM version 5.1.1.1
environment provides the lowest efficiency, which means that it provides the lowest throughput per
CPU. In general, the larger the number of concurrent administrators, the more work gets done for
the invested amount of CPU.
Conclusions
Comparing TPM version 5.1.1.1 in the prior and the new environments shows clearly that the new
environment is very well tuned. Much more work is done for the same amount of CPU, even when
the workload is higher. The TPM version 7.1.1.1 data shows the impact of the higher workload,
which requires more CPU. The fact that the system works more efficiently with a larger number of
administrators indicates that there is an administrator-independent minimum amount of CPU used to
drive the whole environment.
28
Linux on IBM System z
October 2010
Figure 6 shows the resource utilization for the various guests (called TPM components) of the TPM
environment, for a more detailed comparison using 100 concurrent administrator. Keep in mind that
the throughput is comparable.
Figure 6. CPU load of the TPM components at 100 concurrent administrators
Observations
With TPM version 7.1.1.1, the CPU load on the TPM system is significantly increased, and the CPU
load on the DB2 system is significantly decreased. The total load is decreased by approximately half
of a CPU.
Conclusions
It seems that the internal structure of the organization of the work has changed significantly.
Associated with this change is a shift of CPU load from the database server to the TPM (application)
server. Overall, the CPU load on the TPM version 7.1.1.1 system is lower.
Figure 7 illustrates the memory usage of the individual components of TPM.
29
Linux on IBM System z
October 2010
Figure 7. Real memory utilization of the TPM components at 100 concurrent
administrators
Observations
The memory utilization of TPM version 7.1.1.1 is significantly higher than the memory utilization of
TPM version 5.1.1.1. The memory utilization of the DCD depot guest is approximately half, but the
total amount is small.
Conclusions
The graph shows the memory sizes as allocated from z/VM, which might be much lower than the
guest definition due to optimization processes from z/VM. The higher memory usage on the TPM
system is expected to be dedicated to the higher load now running on the TPM system. The different
behavior for the DCD depot is not expected, and requires further investigation.
Chapter 8. Benchmark results using the Deployment Engine interface
These results are for the TPM version 7.1.1.1. study using the DE interface. Both the concurrent
administrator workload mix of 60% QuickFind and 40% DE, and a set of tests using a workload of
100% DE are analyzed. An extensive analysis of memory overcommitment scenarios are done.
Finally, the page response times of some scenarios and the network throughput is reviewed.
30
Linux on IBM System z
October 2010
Using the DE interface and the concurrent administrator workload mix
These results are for the concurrent administrator workload using the DE interface in the tuned
environment. The results are compared with results from the SDI interface.
These tests use the concurrent administrator scaling, and the workload used was the mixed workload,
60% QuickFind and 40% DE. In all scenarios, the tuned environment was used as described in SDI
results: Tuning the benchmark systems. The workload is described in Concurrent administration
scenario for DE.
The execution time of the workload was measured with the number of concurrent administrators set
to 10, 50 and 100. The measurement data was collected from the time that RPT starts the recorded
scripts until the last user has completed the recorded script. The test is considered complete at this
point. Measurement data is not collected after this point.
These measurements give a view of how the system performs as the number of administrators
increases, and compares the results with the SDI results.
Figure 8 shows the execution times for the concurrent administrator scenarios using either SDI or
DE. Note that smaller values are the better ones.
31
Linux on IBM System z
October 2010
Figure 8. Comparison of the execution times from the DE and the SDI interface for the
concurrent administrator workload mix
Observation
The two mixed workloads have almost identical execution times, when scaling the number of
concurrent administrators.
Conclusion
The similar behavior is primarily caused by the commonly used QuickFind component of the
workload. This component takes longer than either the SDI or DE components of the workload.
CPU load for z/VM
Figure 9 shows the CPU load of the whole z/VM LPAR for the concurrent administrator scenarios
using either SDI or DE.
32
Linux on IBM System z
October 2010
Figure 9. Comparison of the CPU load from the DE and the SDI interface for the concurrent
administrator workload mix
Observations
The CPU utilization for the mixed DE workload is very similar to the SDI workload, except for the
highest workload point with 100 concurrent administrators.
Conclusion
It is not surprising that both workloads show a very similar behavior, given both workloads are
performing 60% the same activity (QuickFind) and that the measurement phase does not complete
until the last administrator has finished its work.
However, there is a slight advantage in terms of CPU resources required drive the workload at the
higher workloads for SDI. This advantage is most likely due to the distributed infrastructure of the
SDI interface, which leads to a more balanced load than the centralized deployment mechanism used
by DE.
33
Linux on IBM System z
October 2010
CPU load for TPM and DB2 guest
Figure 10 and Figure 11 depict how the total CPU load from the z/VM LPAR is distributed over the
DB2 and the TPM servers for the SDI and the DE workloads. The contributions from the DCD depot
and the ITDS servers are so small that they are not shown here.
Figure 10 shows CPU load for the TPM and DB2 guest and from the z/VM LPAR for concurrent
administrator workload mix using the SDI interface, and Figure 11 shows the same data, but with DE
interface replacing the SDI interface.
Figure 10. CPU load for the TPM and DB2 guest and from the z/VM LPAR for concurrent
administrator workload mix using the SDI interface.
34
Linux on IBM System z
October 2010
Figure 11. CPU load for the TPM and DB2 guest and from the z/VM LPAR for concurrent
administrator workload mix using the DE interface
Observations
For both scenarios, the CPU load on the TPM server is higher than for the DB2 server. In the DE
scenario, the CPU load increases nearly linearly for all scaling steps, where the CPU usage from the
DB2 server increases faster than from the TPM server. The CPU utilization for the SDI scenario stays
nearly flat when scaling from 50 to 100 concurrent administrators.
Conclusion
The general observation is that the DE-based workload places a higher load on both the TPM and
DB2 servers. The primary reasons for this observation are:
 The DE workload explicitly runs workflows that use TPM management server resources.
Alternatively, the SDI workload pushes jobs to be run by the remote targets.
 The workflow started by the DE workload is performing explicit database operations, including
XML import-based operations that are typically high cost.
The specific scenario run for the benchmark can be considered typical workflow behavior. In
general, this study shows the need to perform capacity planning based on workload profiles for
specific workflows, particularly when custom (customer written) workflows are involved.
35
Linux on IBM System z
October 2010
Using the Deployment Engine interface and a 100% Deployment Engine workload
These results are for a workload with 100% Deployment Engine (DE) activity. The number of
administrators and workflows are scaled. The use and impact of the two types of throttling are
illustrated.
There are two test scenarios used with the DE interface and the workflow scaling:
1.
Scaling the workflow and administrator ratio with a constant number of total workflows.
2.
Scaling the number of workflows per administrator, with a constant number of administrators.
In all scenarios, the tuned environment was used as described in SDI results: Tuning the benchmark
systems.
Scaling the workflow and administrator ratio with a constant number of total workflows
In this scenario, the total number of workflows is held to a constant value of 100. The total number
of workflows is defined as the product of the number of administrators multiplied by the number of
workflows per administrator. In this scenario, the number of administrators is set to 1, 10 and 100.
Therefore, for 1 administrator the number of scheduled workflows is 100, for 10 administrators it is
10, and for 100 administrators it is 1.
The test is started by an RPT recorded script, and the test is concluded when all scheduled
workflows have completed. The throttles are defined in a way that they do not limit the workload.
Execution times
Figure 12 shows the impact on execution times, when scaling the number of administrators with a
constant number of submitted workflows.
36
Linux on IBM System z
October 2010
Figure 12. Execution times, when scaling the number of administrators with a constant number
of submitted workflows
Observations
The average execution time is almost identical for 1 and 10 administrators. When increasing the
number of administrators to 100, the execution time increases.
Conclusions
Because the total number of workflows is the same, any change in behavior must be caused by the
number of administrators and the way that the workflow is submitted (all workflows from one
administrator, or a certain fraction from several administrators). The expectation is that there is a
certain overhead related to the number of administrators, but the impact on execution time becomes
visible only with a larger number of administrators.
CPU load
Figure 13 shows the impact on CPU load, when scaling the number of administrators with a constant
number of submitted workflows.
37
Linux on IBM System z
October 2010
Figure 13. CPU load, when scaling the number of administrators with a constant number of
submitted workflows
Observations
As the number of administrators increases, the CPU load on both the TPM and DB2 servers
increases linearly. The CPU load increases faster for the DB2 server than for the TPM server.
Conclusion
Even without the QuickFind component, there are several tasks that are related to the individual
administrator, such as the login process and the working space management. These tasks are
overhead, which scales with the number of administrators, while the requirements for the 100
workflows itself remains constant. Sizing recommendations has a more detailed consideration of the
CPU requirements for that workload.
Scaling workflows per administrator
In this scenario, the number of administrators is held constant at 100, and the number of workflows
scheduled per administrator is set to: 1, 10 and 100.
This results in the total number of workflows as follows:
One workflow per administrator
1 * 100 = 100 workflows in total
38
Linux on IBM System z
October 2010
Ten workflows per administrator
10 * 100 = 1,000 workflows in total
One hundred workflows per administrator
100 * 100 = 10,000 workflows in total
Execution times
Figure 14 shows the impact on execution times, when having 100 concurrent administrators and
scaling the amount workflows issued per administrator.
Figure 14. Execution times for scaling the number of workflows issued from 100 administrators.
The value for 100 workflows is extrapolated based on the results for 1 and 10 workflows.
Observations
The execution time increases with the increasing number of workflows in a nonlinear manner. The
value for 100 workflows per administrator is 30 minutes longer than expected, based on the results
for 1 and 10 workflows per administrator.
39
Linux on IBM System z
October 2010
Conclusion
Because the workload increases linearly with the increasing number of workflows, a linear scaling is
expected. The nonlinear behavior with 100 concurrent administrators and 100 workflows is caused
by throttling.
Deployment Engine throttling
The DE workload throttles are set to limit the total number of DE workflows executing concurrently,
according to the values in Table 7.
Table 7. Scaling workflows per administrator: Impact of throttling
Number of
administrators by
number of
workflows
Total number of
workflows
Global
throttle
Per task
concurrency level
Scenario affected by throttle
100 x 1
100
600
10
100 x 10
1,000
600
10
None
Global throttle
100 x 100
10,000
600
10
Global throttle and per task
concurrency
Table 7 shows that only the first scenario, with a single workflow for each of the 100 administrators,
is not affected by any throttle. The scenario with 100 administrators running 10 workflows is limited
by the global throttle, which limits the amount of parallel running workflows to 600. The remaining
workflows are queued and run when the first workflows are done.
The scenario with 100 administrators running 100 workflows is limited by both the global throttle
and also by the per task concurrency value. It seems that the per task concurrency has a higher
throttling effect than the global throttle, because the execution time of this scenario is 30 minutes
longer than the expected time, based on extrapolating from the results of the 1 and 10 workflows per
administrator scenarios.
CPU load
Figure 15 shows the impact on CPU load, when scaling the number of workflows for 100
administrators.
40
Linux on IBM System z
October 2010
Figure 15. CPU load for scaling the number of workflows (1, 10, 100) issued from each of 100
administrators
Observations
The CPU load increases by 20% when comparing the first scenario (100 administrators with one
workload) with the second scenario (100 administrators with 10 workloads). The third scenario (100
administrators with 100 workloads) has a reduction in CPU load.
Conclusion
Throttling reduces the CPU load and increases the workload duration. The expectation was that the
scenarios with 10 and 100 workflows per administrator would behave the same, because the global
throttle limits the amount of parallel running workflows to 600. The per task concurrency influences
only the contribution from each administrator to these 600 workflows. But the fact that the run time
for the 100 workflows is elongated more than expected, and the CPU load is lower, indicates that the
limitation by the per task concurrency stretches the workload over time. However, throttling is a
useful mechanism to control the load at the creation point. This control prevents an overloaded
system from causing unpredictable behavior due to system resource constraints.
Page response times
The section studies the response times for various memory pages used from the workloads of this
study.
41
Linux on IBM System z
October 2010
Page response times were studied while varying the number of administrators and LPAR memory
size. Page response times were also compared between the SDI and DE workloads.
Scaling the number of administrators with a 100% DE workload
Figure 16 shows the response times with 10, 50, and 100 administrators, all of which have 100
workflows consisting of 100% DE.
Figure 16. Response times for the various tasks in the 100% DE workload, when using 10, 50,
and 100 administrators, each of which has 100 workflows
Observation
This scenario shows the impact of varying the number of administrators (10, 50, 100) while the
number of workflows per administrator remains constant (100). In general, the response times show
degradation as the number of administrators increases. Increasing the administrators by a factor of 5
(from 10 to 50) results in a 3.5 times increase in page response times on some pages. Increasing the
administrators by a factor of 2 (from 50 to 100) shows a slightly more then linear increase in page
response times.
Conclusion
The response times show the impact of increasing workloads on the management server, driven by
both the increased number of users and the associated (management-server based) DE workload that
42
Linux on IBM System z
October 2010
they are driving. SDI workloads tend to have more immunity from this impact, as generally
demonstrated in Figure 10 and Figure 11). This scenario demonstrates the need for proper capacity
planning and tuning based on DE workload execution profiles.
Note: The throttling of the DE workload puts an upper limit on the global and task level concurrency
used by the Deployment Engine workload. Increasing the throttle limits to support more concurrent
workflows can increase the amount of CPU used, depending on the workflows being run. This may
result in worse page response times. However, if you decrease the throttle limits to reduce the
number of concurrent workflows, page response times may improve due to less CPU being used by
the deployment engine workload and reduced overall system resource contention.
Scaling z/VM LPAR memory size
Figure 17 shows the results of scaling the z/VM LPAR memory size.
Figure 17. Reduced memory: 50 administrators and 100 workflows
Observations
This scenario shows the impact of varying the memory with a constant workload of 50 administrators
and 100 workflows. The memory variation is in general:
 Full memory requirement met.
43
Linux on IBM System z
October 2010
 Sufficient memory for both the application server Java heap configuration and the DB2 server
buffer pool configuration.
 Sufficient memory for the application server Java heap configuration.
 10% less than the allocation of memory to provide sufficient memory for the application server
Java heap configuration.
In general, there is minimal response time degradation when the LPAR memory is sized to contain
the Java heap and DB2 buffer pools. When the memory size is decreased to less than this value,
significant and progressive degradation is strongly evident. Overall, the LPAR memory can
significantly affect TPM page response times (in the worst case, increasing page access time from 6
seconds to 141.5 seconds).
Conclusion
The LPAR memory should be configured large enough to contain the Java heap and DB2 buffer
pool memory allocation, or else immediate and significant response time degradation occurs.
Comparing SDI and DE
Figure 18 shows the response times for two scenarios: 60% QuickFind and 40% SDI, and 60%
QuickFind and 40% DE. In both scenarios, 50 administrators are used.
Figure 18. Response time with 50 administrators: SDI versus DE workloads
44
Linux on IBM System z
October 2010
Observation
This scenario shows the page response times for the distinct SDI and DE scenarios. In general, the
response time of a set of pages shows degradation when using DE as opposed to SDI. Changing the
backend workload increases the page response time on average by a factor of 2.68. This graph shows
that with the DE workload, the system reaches IFL saturation at an earlier point and thereby
increases the page response times.
Conclusion
Once again, the response times show the impact of increasing workloads on the management server,
in this case driven by the DE workload. The DE workload is driving higher management server
utilization, resulting in IFL saturation, and poorer page response times. SDI workloads tend to drive
lower management server utilization, and have more immunity from this impact. This scenario once
again demonstrates the need for proper capacity planning and tuning based on DE workload
execution profiles.
Chapter 9. Memory overcommitment
Virtualization allows the use of more virtual memory than available physical memory. The
capabilities and the limits for memory overcommitment were analyzed, and rules are determined for
the TPM environment to prevent poor system performance.
In this test, the size of the z/VM LPAR memory was reduced to create well-defined memory
overcommitment scenarios. The impact on the execution times was then measured.
In all scenarios, the tuned environment was used as described in SDI results: Tuning the benchmark
systems. In particular, note that the memory size in the guest definition was not changed. A workload
of 60% QuickFind and 40% DE was used.
The working set size (WSS) of a virtual machine is a projection of the number of pages that are
allocated in real storage, in order to process a virtual machine's transaction efficiently (that is, with a
minimum number of page faults). The working set size is based on the virtual machine's run history
and is calculated each time that the virtual machine is dropped from the dispatch list. Virtual
machine pages that are not in real storage are located in paging storage, either in expanded storage
or on paging devices (DASD).
z/VM memory management overview
The z/VM system maps the virtual memory of the guests into the real memory storage of the IBM
System z machine. Figure 19 illustrates an overview of z/VM memory management.
45
Linux on IBM System z
October 2010
Figure 19. z/VM memory management
The guests experience only the virtual view, which means that there are active pages and inactive
pages. Inactive pages are currently not in use (but might have been used in the past). Only the active
pages, the pages that are at the moment in use, need to be mapped to real memory. If there are not
enough real memory frames to contain all the virtual memory pages for active guests, the virtual
46
Linux on IBM System z
October 2010
pages for the active guests are moved to XSTOR. XSTOR is a very fast paging device, implemented in
the expanded storage of the LPAR. When XSTOR becomes full, the memory pages for the guests are
moved from XSTOR to DASD paging space.
When running with memory overcommitment, it is important that all pages that are in use at a
certain moment in time are in real memory, otherwise the guest must wait until z/VM brings the page
into real memory. The important question is whether it is possible to determine ahead of time how
much memory a guest requires as minimum, and how much is required for the best performance.
It is already known that:
 There is a significant performance impact when Java heaps are not mapped to real memory.
 Unused pages, such as the memory from idling guests, do not require real memory.
It is expected that:
 Database memory pools behave like Java heaps, which means that they contribute to the active
memory requirement.
 Page cache requires a smaller number of active pages. Even the page cache portion from a Linux
system can become very large; the system is not working on all pages intensively at the same
moment in time.
Using these considerations, the memory types of the servers used in this benchmark are classified as
follows:
 The TPM server provides a Java heap of approximately 8 GB (MXServer, LWI) with associated
memory for native heap, whose size is on the order of hundreds of megabytes (such as 300 MB
average for the tested workloads). See TPM system tuning).
 The DB2 system had a peak allocation for memory pools in the tests of approximately 2.2 GB
(maximum configured approximately 4 GB).
 The memory requirement of the ITDS is unknown. It is used at such a low level in the test
scenarios, that its requirements are ignored in subsequent memory considerations.
 The DCD depot is not used for the DE workload. Therefore, the DCD depot represents an idling
guest, which is assumed to need no memory at all.
The memory size for the basic setup was determined by adding up the sizes of all the guests. An
attempt was made to run without any memory overcommitment, but the guest sizes resulting from
the tuning phase slightly exceed the amount of memory available. After the tuning phase, the real
memory of the z/VM LPAR was reduced in four steps:
1. To the size of the total number of pages in the working set for the TPM and DB2 server guests
(parameter WSS, as reported in the performance toolkit report FCX113 User Paging Activity and
Storage Utilization), in the basic setup with no memory overcommitment.
47
Linux on IBM System z
October 2010
2. Because these guests are expected to exert the most memory pressure, an important condition of
this step was that z/VM must not show any paging activity.
3. To the size of the sum of WebSphere allocated Java heap and DB2 memory.
4. To the size of the WebSphere allocated Java heap.
5. To the size of the WebSphere allocated Java heap minus 10%.
Table 8 shows real memory sizes used.
Table 8. Real memory size of the z/VM LPAR, reduced in four steps
Step number
Basic setup
Description
Maximum available physical memory (28 GB)
•
Real memory size in GB
28672
Sum of all guest sizes (31 GB)
1
Size of the total number of pages in the working
set of the TPM and DB2 server guests, from the
basic setup
26368
2
Size of the sum of WebSphere allocated Java
heaps and DB2 memory
10240
3
Size of the WebSphere allocated Java heaps
7168
4
Size of the WebSphere allocated Java heaps
minus 10%
6400
Because the size of the virtual storage allocated to each virtual machine (guest) was not changed, the
real memory size reductions cause the z/VM system to start to locate active virtual memory pages in
either XSTOR or paging DASD.
The 60% QuickFind and 40% DE workload was run with 50 administrators and 100 workflows per
user. It is important to note that the mixed workload contains a loop of ten iterations for each user.
The mixed DE workload was used to create a scenario where there is more pressure on system
resources. The QuickFind component of the mixed DE workload requires more TPM and DB2 server
resources.
The DE mixed workload was measured from the start of RPT recorded script execution until the end
of the execution of the recorded script by the last user.
48
Linux on IBM System z
October 2010
Execution times
Figure 20 shows the execution times for 60% QuickFind and 40% DE workload mix when
decreasing the LPAR memory size. Note that smaller values are the better ones.
Figure 20. Execution times for 60% QuickFind and 40% DE workload mix when decreasing the
LPAR memory size
Observations
The best result is produced by the first scaling step, the reduction of the z/VM memory to the WSS
sizes from guests with the highest memory load, as reported in the basic setup. At a memory size of
approximately 10 GB (size of Java and DB2 memory pools), the execution time is getting worse
(increases) by 14%, with a memory saving of 60% compared to the best result. When reducing the
real memory size further, the impact on the execution time is dramatic. The next 30% reduction (size
of Java heaps only) doubles the execution times. The last step, with 10% less than the Java heap size,
increases execution time further by 40%. This step saves 76% of the memory, at the cost of a more
than three times longer execution time.
49
Linux on IBM System z
October 2010
Conclusion
The best performance is achieved when the total memory is smaller (-8%) than the sum of the guest
sizes. There seems to be a phase where z/VM can handle this reduction by optimization of the page
handling without any paging activity. Decreasing the LPAR memory further, to the sum of the size of
the database memory and the Java heaps (60% decrease), shows a very moderate performance
degradation (increase in execution time by 14%), while the system shows already significant effort for
paging. But considering the large amount of saved memory, this performance degradation seems to
be an acceptable compromise concerning resource saving and operability. However, when decreasing
the memory further, the execution time increase so dramatically that this step is to be avoided.
CPU load
Figure 21 shows the CPU utilization for 60% QuickFind and 40% DE workload mix when decreasing
the LPAR memory size.
Figure 21. CPU load for 60% QuickFind and 40% DE workload mix when decreasing the LPAR
memory size
50
Linux on IBM System z
October 2010
Observations
In the first scaling steps, the CPU load of the LPAR is exactly on the top of the bars from TPM and
DB2, indicating a very low CPU portion spent for the z/VM CP program. As the reduction of main
memory continues further, the gap between the CPU load from the LPAR (yellow line) and the CPU
load from the TPM and DB2 guests (blue and red bars) becomes larger.
Conclusion
As the size of main memory decreases, fewer guest memory pages can be held in real memory and
more pages have to be moved to the paging devices. The fewer guest memory pages that are in real
storage, the higher the probability that the guest attempts to access a page that is not in real storage,
and a page fault occurs. Then the guest must wait until z/VM brings in the requested page. If it
comes from the XSTOR, the page might be available relatively soon. But if the page comes from a
DASD device, there could be a considerable wait time for the guest. While waiting for the requested
memory page, the corresponding process does not use CPU cycles. That fact is the reason why the
CPU load for the guests decrease, because they are waiting for their memory pages. In proportion,
the cost for z/VM page management increases significantly because of increasing resources expended
for page migration.
The database memory and Java heaps should be backed with physical memory, because reducing the
memory below that size has a significant performance impact. Decreasing the memory size to less
than that value severely affects system performance.
Working set size of the guests
The following analysis illustrates what happens with the pages from the guests when scaling down
the LPAR memory size. Figure 22 shows the change in working set size (WSS), which is the number
of memory pages in real memory for a guest (also called resident pages).
51
Linux on IBM System z
October 2010
Figure 22. Impact of LPAR size scaling to the working set size (WSS)
Observations
The working sets of the guest are decreased proportional to the size of real memory. The number of
memory pages for ITDS and DCD depot servers quickly becomes so small that they are not visible in
the chart. Also, the WSS of the DB2 system shrinks heavily, but slower than the DCD depot and
ITDS servers. The majority of the memory pages are from the TPM guests.
Conclusion
The working set size must shrink when the real memory shrinks. A criteria used by z/VM to decide
which pages stay in real memory is to look at the pages from all guests, and keep those pages that are
in use at the current moment. This chart shows clearly that the TPM, respectively the Java heap, is
heavily used in its whole memory size. Note that the last state of acceptable performance is the one
with a real memory size of 10 GB. The pages of the database were moved out of real memory before
Java heap pages. However, when the number of pages in real memory is reduced to less than the size
of the DB2 memory pools and Java heap, the performance starts to degrade substantially.
What happens with the pages
The previous section showed that when the LPAR memory size is reduced, the working set size of
the guests must be reduced as well. This analysis explains what happened with the pages.
52
Linux on IBM System z
October 2010
z/VM has a two stage paging setup. The first paging device is the XSTORE, which is a very fast
paging device because it is in memory. However, XSTOR has a limited size. The second paging
device is on DASD, where a very large amount of memory can be stored temporarily. However,
DASD is much slower than XSTOR.
Figure 23 and Figure 24 show where the memory pages of the TPM and the DB2 guests reside in the
various scaling steps.
Figure 23. Utilization of the paging devices for the pages of the TPM guest when decreasing the
LPAR memory
53
Linux on IBM System z
October 2010
Figure 24. Utilization of the paging devices for the pages of the DB2 guest when decreasing the
LPAR memory
Observations
The charts for both TPM and DB2 servers show that in the first scaling step, where the LPAR size is
reduced to the sum of the WSS size from the TPM and DB2 servers in the basic scenario, the total
size of pages is reduced without using any paging devices. This scenario has the best performance.
Reducing the memory further decreases the total number of pages, with a flattening slope. Looking
at the performance, it seems that the scenario with 10 GB has a very good mixture of memory and
paging device usage, where the important pages are in memory, and degradation due to paging
activity is minimized.
Conclusion
The important criteria of the first scaling step is that z/VM is able to decrease the WSS size by a
significant amount, without any swapping activity. These reduced working sets decrease the effort
used for memory handling in z/VM. The expectation is that this reduction causes the performance
improvement shown in this step. The memory required in main memory (and expanded storage) fits
very well with the size of the Java heaps assumed to be relevant for TPM (8 GB) and the peak
allocation shown from the DB2 database (2.2 GB).
The memory pressure from the TPM server and the DB2 server seems to be very different. The
garbage collection of the Java heap could be considered as the critical activity for TPM memory
pages (with regards to memory overcommitment). When the garbage collection runs, it accesses all
54
Linux on IBM System z
October 2010
heap pages during the cleanup period. The database buffer pools are used as a cache holding the
mostly used pages in memory. That leads to the pattern where pages from the TPM server are held in
memory as long as possible, but when swapped they go immediately to the paging DASD. While
pages of the DB2 server leave the main memory earlier than pages from the TPM server, there is a
significant number of DB2 server pages in the XSTOR (which could be considered with its size of 2
GB as small for this level of memory overcommitment).
Chapter 10. I/O bandwidth
Understanding the network utilization is important to correctly size the network bandwidth, and
prevent contention inside the system.
For an impression of the required I/O bandwidth, the network utilization is analyzed using the 60%
QuickFind and 40% SDI workload mix, with 100 concurrent administrators. This scenario is
expected to have the highest load on the I/O devices.
Network throughput for TPM, DB2 and DCD depot servers
Figure 25, and Figure 26 show the average network utilization from the TPM server, the DB2 server,
and the DCD depot server. The vertical bars show the minimum and the maximum values.
Figure 25. Average network utilization from the TPM and DB2 servers. The error bars show the
minimum and the maximum values
55
Linux on IBM System z
October 2010
Figure 26. Average network utilization from the DCD depot server. Error bars show the
minimum and the maximum values
Observation
The maximum network throughput values for TPM and DB2 servers together are about 100 Mb/sec.
This traffic travels over a shared VSWITCH with a 1 Gb OSA card to the network. The maximum
throughput for the DCD depot server is approximately 250 Mb/sec. A 1 Gb OSA card should be able
to handle these throughput requirements. However, the execution times of the tests were shorter
when the DCD depot server had a separate OSA card. The reason for that is that the network
throughput is limited by two parameters, either throughput in terms of Megabits per second or
throughput in terms of packages per second. In this study, the DCD depot produced a very high
number for packages sent per second (35,000).
Conclusion
When taken in combination with the traffic from the TPM and DB2 servers, the limits of a 1 Gb OSA
card were reached. An alternative for using two OSA ports (one for the VSWITCH, and a separate
OSA port for the DCD depot) is the use of a 10 Gb OSA card.
Network throughput from all servers
Figure 27 illustrates the network throughput from all servers, measured over the time of the test run.
56
Linux on IBM System z
October 2010
Figure 27. Network throughput from all servers during the test run
Observation
The network load for the TPM and DB2 servers is relatively constant, and moderate, over the run
time. The load from the DCD depot is at zero for a long time period, but when the software
distribution phase starts this load reaches high peaks.
Conclusion
When sizing the network capacity for the DCD depot, the peak loads should always be considered;
the average over the run time is misleading.
Chapter 11. Sizing recommendations
Based on the measured CPU utilization and memory configurations, sizing suggestions are developed
for three workloads.
Note: All sizing suggestions are based on the results in the described environment, and on the
described standard benchmark workloads. Any customer TPM scenario might require additional
detailed adjustments to optimize a specific customer workload in a specific environment.
The CPU utilization and the resulting sizing suggestions are presented for three scenarios:
 0% QuickFind and 100% DE workload
 60% QuickFind and 40% DE workload
 60% QuickFind and 40% SDI workload
57
Linux on IBM System z
October 2010
The sizing recommendations consist of two parts:
 The number of virtual CPUs for the guests
 The amount of physical IFLs for the z/VM LPAR
The CPU numbers for virtual guests could be considered as an upper limit of the CPU capacity that a
certain guest can use. The amount of physical IFLs for the z/VM LPAR limits the total CPU capacity
available. This physical CPU capacity is dispatched by z/VM to the virtual CPUs of the guests
according to the requested amount and the priority. In all tested scenarios, all guests had the same
priority.
100% DE workload
For this workload, the system is throttled:
 Globally to 600 workflows (referred to as 'system')
 Per administrator to 10 workflows (referred to as 'admin')
The workload consist of two phases for each administrator:
 In the User Interface (UI) phases, the workload defines the administrator and the workflows, and
submits the workflows.
 In the DE phase, the workflows are executed.
Each phase has individual CPU requirements as shown in Table 9. The Throttling row indicates
whether a scenario is subject to a throttle, and which type of throttle was used.
Table 9. CPU utilization for the UI and the DE phase for the 100% DE workload
CPU utilization for 0% QuickFind and 100% DE workload
Number of administrators
1
10
100
100
100
Number of workflows per
administrator
100
10
1
10
100
Total number of workflows
100
100
100
1,000
10,000
Execution times (h:mm:ss)
0:20:12
0:20:14
0:23:01
0:46:36
4:43:48
Workload type
z/VM guests
LPAR
Throttling
UI
DE
UI
DE
UI
DE
UI and
DE
DE
UI and
DE
DE
TPM server
4.47
2.55
5.0
2.79
5.76
2.35
5.94
2.97
5.35
2.24
ITDS server
0.01
0.01
0.01
0.01
0.01
0.01
0.01
0.01
0.01
0.01
DB2 server
0.61
0.14
0.72
0.15
0.66
0.14
0.93
0.24
1.22
0.41
z/VM
5.10
2.71
5.75
2.96
6.46
2.51
6.92
3.25
6.62
2.69
No
No
58
No
System
System and
admin
Linux on IBM System z
October 2010
These data lead to the following sizing suggestions:
 CPU capacity for UI activity:
– Up to 100 workflows in total:
5.09 + 0.3 * ln (number of administrator) (ln = natural logarithm)
– Up to 600 workflows in total:
Consider adding 0.5 IFLs (there are a significant number of workflows starting already during UI
processing.)
 CPU capacity for the DE activity:
– Up to 100 workflows: 2.75 IFLs
– Up to 350 workflows: 3.0 IFLs (estimated)
– Up to 600 workflows: 3.25 IFLs
The CPU requirements for the UI phase are much higher than for the DE phase. Assuming that most
workflows are not started before UI is done, the sizing considers only UI requirements, which would
provide sufficient CPU capacity for the DE phase, provided that there is no significant overlap.
Otherwise, the sizing values for UI and DE must be added.
This assumption results in the sizing recommendation shown in Table 10.
Table 10. Sizing recommendation for the 100% DE workload, assuming no significant overlap of UI
and DE phases
Sizing for 0% QuickFind and 100% DE workload, based on UI
Number of administrators
1
10
Number of workflows per administrator
100
10
Total number of workflows
100
100
5
5
z/VM
guests virtual CPUs
TPM server
LPAR - IFLs
100
100
100
1
10
100
100 600 (1,000) 600 (10,000)
6
6
6
ITDS server
1
1
1
1
1
DB2 server
1
1
1
1
2
z/VM
5
6
7
7
7
In order to save IFLs:
 Decreasing the number of IFLs from the LPAR is a possibility. This decrease limits the initial UI
activity (which takes longer), but do not decrease this value to less than the DE portion of 3 IFLs.
 The throttles must also be decreased to ensure an error-free system.
Note: Ensure that no guests have more virtual CPUs than the z/VM has physical IFLs.
59
Linux on IBM System z
October 2010
60% QuickFind and 40% DE workload
The measured CPU utilization is shown in Table 11
Table 11. CPU utilization for the 60% QuickFind and 40% DE workload
CPU utilization for 60% QuickFind and 40% DE workload
Number of administrators
10
Number of workflows per administrator
Total number of workflows
Execution times (h:mm:ss)
z/VM guests
LPAR
50
100
100
100
100
4,000
20,000
40,000
0:21:00
0:27:21
0:36:42
TPM server
2.55
4.03
4.94
ITDS server
0.01
0.01
0.01
DB2 server
0.55
1.61
2.69
z/VM
3.13
5.69
7.68
These data lead to the sizing recommendation shown in Table 12.
Table 12. Sizing recommendation for the 60% QuickFind and 40% DE workload
Sizing for 60% QuickFind and 40% DE workload
Number of administrators
Number of workflows per administrator
Total number of workflows
z/VM guests
LPAR
TPM server
10
50
100
100
100
100
4,000
20,000
40,000
3
4
5
ITDS server
1
1
1
DB2 server
1
2
3
z/VM
3
6
8
10
50
100
0:36:51
60% QuickFind and 40% SDI workload
The measured CPU utilization is shown in Table 13.
Table 13. CPU utilization for the 60% QuickFind and 40% SDI workload
CPU utilization for 60% QuickFind and 40% SDI workload
Number of administrators
Execution times (h:mm:ss)
z/VM guests
LPAR
0:20:40
0:22:31
TPM server
2.21
4.12
4.5
ITDS server
0.01
0.01
0.01
DB2 server
0.49
2.05
2.12
z/VM
2.74
6.23
6.75
These data lead to the sizing recommendation shown in Table 14.
60
Linux on IBM System z
October 2010
61
Linux on IBM System z
October 2010
Table 14. Sizing recommendation for the 60% QuickFind and 40% SDI workload
Sizing for 60% QuickFind and 40% SDI workload
Number of administrators
z/VM guests
LPAR
10
50
100
TPM server
3
5
5
ITDS server
1
1
1
DB2 server
1
3
3
z/VM
3
7
7
Memory
For the virtual memory of the guests and the physical memory of the z/VM LPAR, recommended
memory sizings are shown in Table 15.
Table 15. Recommended memory sizings for the virtual memory of the guests and the physical
memory of the z/VM LPAR
Memory in MB
z/VM guests
TPM server
ITDS server
All active Java heaps: 8
GB
Virtual memory
14,102
DB2 server
DCD depot
server
Peak partition
memory: 2.2 GB
Maximum partition
memory: 4 GB
1,120
12,536
z/VM LPAR
Minimum
Best
Real memory
11,264
26,368
944
Rules for real memory sizing based on the tested scenarios:
 Best configuration
The best results were produced when the LPAR size was set to the sum of working set size (WSS)
from the TPM guests from the scenario with no memory overcommitment.
– See PerfKit Panel FXC113 User Paging Activity and Storage Utilization.
 Minimum configuration
The minimum configuration is the sum of all active Java heaps and DB2 memory plus 10%.
– The sum of all Java heaps is generally calculated by determining which Java heaps are
involved in the workload, and assuming that all heaps are used at the maximum size along with
a buffer for the native heaps of the JVMs.
x In the case of the DE workload, this would be the sum of the maximum LWI heap size and
the maximum MXServer heap size, plus 10% for native heap usage.
62
Linux on IBM System z
October 2010
x In the case of the SDI workload, this would be the sum of the maximum LWI heap size, the
maximum MXServer heap size, the maximum CAS server heap, size plus 10% for native
heap usage.
x In the case with a high SDI and DE workload, the calculation would be the same as the SDI
workload; however the LWI size might need to be increase in order to support the additional
concurrency.
x Native heap usage can consist of several items, such as: thread stack size, socket buffers, JIT
storage space, native libraries, and so forth. Due to this the memory consumption, the native
heap size is generally very dynamic and based on workloads. The size might be different
when using a workload other then the one described in this paper.
x For DB2 memory size, use the sum of MAX_PARTITION_MEM from "SELECT * FROM
TABLE (SYSPROC.ADMIN_GET_DBP_MEM_USAGE()) AS T".
– Note that in the calculations above, the peak allocation of the DB2 buffer pools was less than
the maximum configured size. Using this peak value for the estimate of the required memory
bears the risk that when memory allocation increases, the size of the minimum configuration
increases and the system runs in a state with increasing response times caused by the lack of
real memory.
 Changing from the Best to the Minimum configuration saves 60% memory, with a performance
decrease of 14%. Reducing the LPAR size to a value less than that minimum value might lead to a
significant performance degradation.
 DB2 tends to cause swapping, therefore setting /proc/sys/vm/swappiness to 0 is
recommended.
– This configuration recommendation comes from the DB2 team as well.
 Adding additional types of workloads or servers will increase the need for real memory.
63
Linux on IBM System z
October 2010
Appendix A. Tuning steps
These tuning steps were applied to the TPM, ITDS, DB2, and DCD depot systems for the
benchmarks. Instructions for changing the Java garbage collection interval to a value of one hour are
also provided. Any customer environment might need additional tuning.
Note: Take note of these points:
1. For the tuning steps for each z/VM guest, the name of the file to receive the tuning parameters is in
bold right in front of the file contents.
2. These changes take effect when the system is restarted. Changes in /etc/sysctl.conf can also be
activated using this command:
sysctl -p /etc/sysctl.conf
TPM system tuning
For the TPM system, important tuning steps are for the network, resource limits, shared memory
setup, WebSphere specific tuning, and heap sizes.
Red Hat Tuning
To disable SELINUX:
/etc/selinux/conf
SELINUX=disabled
/etc/sysctl.conf
net.ipv4.ip_forward = 0
net.ipv4.conf.default.rp_filter = 1
net.ipv4.conf.default.accept_source_route = 0
net.ipv4.tcp_syncookies = 1
kernel.core_uses_pid = 1
kernel.msgmnb = 65536
kernel.msgmax = 65536
kernel.shmmax = 68719476736
kernel.shmall = 4294967296
#Tuning gc_thresh for high emulator load
net.ipv4.neigh.default.gc_thresh1 = 1024
net.ipv4.neigh.default.gc_thresh2 = 2048
net.ipv4.neigh.default.gc_thresh3 = 8096
net.ipv4.tcp_rmem = 4096
98304
4194304
net.ipv4.tcp_wmem = 4096
65535
4194304
net.ipv4.tcp_mem = 196608
262144 393216
net.ipv4.tcp_max_syn_backlog = 2048
net.ipv4.tcp_fin_timeout = 30
64
Linux on IBM System z
October 2010
net.ipv4.tcp_rfc1337 = 1
net.core.somaxconn = 512
net.core.netdev_max_backlog = 1024
net.core.rmem_default = 262141
net.core.wmem_default = 262141
net.core.rmem_max = 262141
net.core.wmem_max = 262141
net.ipv4.tcp_keepalive_time = 3600
/etc/security/limits.conf
root
nofile
tioadmin
nofile
32767
32767
WebSphere tuning
To access the various WebSphere Administration panels to set the appropriate values, use these
paths after logging in the WebSphere administrative console of either MXServer or Server1 (CAS):
for Transport chains
Application servers -> MXServer/Server1 -> Web container -> Web container transport chains
for Thread pools
Application servers -> MXServer /Server1 -> Thread Pools
for Data source connection pools
Resources -> Data sources -> CDSDataSource -> Connection pools
for Java environment settings
Application servers -> MXServer /Server1 -> Process Definition -> Java Virtual Machine
Set the values according to this list:
MXServer
SDIServerTransportChain timeout of 600 seconds
SDIMutualTransportChain timeout of 600 seconds
SDIMutualTransportChain uses the SDIServerThreadPool
CDSDataSource connection pool set to min 10 max 150
(Transport chains)
(Transport chains)
(Data source
connection pools)
JVM Heap set to min 2048MB max 6144MB
(Java environment
settings)
Set the Java rmi garbage collection interval to 1 hour
(See Setting the Java garbage collection interval to one hour)
CAS (Server1)
chain_EP_9511 timeout of 600 seconds
chain_EP_9512 timeout of 600 seconds
chain_EP_9513 timeout of 600 seconds
WebContainer thread pool set to min 25 max 100
JVM Heap set to min 1024MB max 2048MB
65
(Transport chains)
(Transport chains)
(Transport chains)
(Thread pools)
(Java environment
settings)
Linux on IBM System z
October 2010
AgentRegistry connection pool set to a min 10 max 200 (Data source
connection pools)
LWI (Deployment Engine)
$TIO_HOME/lwi/conf/overrides/TPM.javaopt contains user defined overrides
for
setting java options for the LWI process. The default file contains:
-Xmx1700M
Djava.security.policy=/opt/IBM/tivoli/tpm/config/tpm.policy
The following arguments can be used to set the initial and maximum size of the memory allocation
pool (heap).
-Xmx
Specifies the maximum size of the memory allocation pool.
-Xms
Specifies the initial size of the memory allocation pool.
DB2 system tuning
For the DB2 system, important tuning steps are for the network, resource limits, shared memory
setup, and DB2-specific tuning.
Note that DB2 was updated to FP 5.
Red Hat Tuning
The swapiness value (file /proc/sys/vm/swappiness) on the DB2 server was set to zero.
To disable SELINUX:
/etc/selinux/conf
SELINUX=disabled
/etc/security/limits.conf
ctginst1
stack
ctginst1
nofile
root
stack
root
nofile
unlimited
65536
unlimited
65536
[[email protected] benchmark]$ ulimit -a
core file size
(blocks, -c) 0
data seg size
(kbytes, -d) unlimited
66
Linux on IBM System z
October 2010
scheduling priority
(-e)
file size
(blocks, -f)
pending signals
(-i)
max locked memory
(kbytes, -l)
max memory size
(kbytes, -m)
open files
(-n)
pipe size
(512 bytes, -p)
POSIX message queues
(bytes, -q)
real-time priority
(-r)
stack size
(kbytes, -s)
cpu time
(seconds, -t)
max user processes
(-u)
virtual memory
(kbytes, -v)
file locks
(-x)
0
unlimited
32768
32
unlimited
65536
8
819200
0
unlimited
unlimited
32768
unlimited
unlimited
/etc/sysctl.conf
net.ipv4.ip_forward = 0
net.ipv4.conf.default.rp_filter = 1
net.ipv4.conf.default.accept_source_route = 0
net.ipv4.tcp_syncookies = 1
kernel.core_uses_pid = 1
kernel.msgmnb = 65536
kernel.msgmax = 65536
kernel.shmmax = 68719476736
kernel.shmall = 4294967296
DB2 tuning commands
Note: All commands must be run from the DB2 instance owner user ID (for example, ctginst1).
db2set DB2_WORKLOAD=TPM
db2 update db cfg using dbheap automatic;
db2 update db cfg using logbufsz 1024;
db2 update db cfg using auto_reorg on immediate;
db2 update db cfg for maxdb71 using AUTO_STMT_STATS OFF
db2 update db cfg for maxdb71 using STAT_HEAP_SZ AUTOMATIC
db2 update db cfg for maxdb71 using UTIL_HEAP_SZ 5120
Note: The auto_reorg setting requires an associated policy to define the maintenance window for the
implementation.
ITDS system tuning
For the ITDS system, important tuning steps are for the network and shared memory setup.
Red Hat Tuning
To disable SELINUX:
67
Linux on IBM System z
October 2010
/etc/selinux/conf
SELINUX=disabled
/etc/sysctl.conf
net.ipv4.ip_forward = 0
net.ipv4.conf.default.rp_filter = 1
net.ipv4.conf.default.accept_source_route = 0
net.ipv4.tcp_syncookies = 1
kernel.core_uses_pid = 1
kernel.msgmnb = 65536
kernel.msgmax = 65536
kernel.shmmax = 68719476736
kernel.shmall = 4294967296
DCD depot system tuning
For the DCD depot system, the network tuning is a very performance-critical step.
Red Hat Tuning
To disable SELINUX:
/etc/selinux/conf
SELINUX=disabled
/etc/sysctl.conf
#Tuning gc_thresh for high emulator load
net.ipv4.neigh.default.gc_thresh1 = 1024
net.ipv4.neigh.default.gc_thresh2 = 2048
net.ipv4.neigh.default.gc_thresh3 = 8096
net.ipv4.tcp_rmem = 4096
98304
4194304
net.ipv4.tcp_wmem = 4096
65535
4194304
net.ipv4.tcp_mem = 196608
262144 393216
net.ipv4.tcp_max_syn_backlog = 2048
net.ipv4.tcp_fin_timeout = 30
net.ipv4.tcp_rfc1337 = 1
net.core.somaxconn = 512
net.core.netdev_max_backlog = 1024
net.core.rmem_default = 262141
net.core.wmem_default = 262141
net.core.rmem_max = 262141
net.core.wmem_max = 262141
net.ipv4.tcp_keepalive_time = 3600
/etc/security/limits.conf
*
nofile
68
32767
Linux on IBM System z
October 2010
Setting the Java garbage collection interval to one hour
This section describes how the Java garbage collection interval is increased, to avoid unnecessary
triggering of garbage collection.
To set the Java garbage collection interval to a value of one hour, complete these steps:
1. Issue this command:
vi $TIO_HOME/lwi/conf/overrides/TPMconfig.properties
2. Add the lines in bold, between the lines that are not in bold.
sun.rmi.dgc.ackTimeout=2000
sun.rmi.dgc.server.gcInterval=3600000
sun.rmi.dgc.client.gcInterval=3600000
start.tpm.engines.policyengine=false
3. Log in to WebSphere admin
http://hostname:9060/admin
4. Navigate to Application servers -> MXServer -> Java Process and Management -> Process
Definition. See Figure 28.
69
Linux on IBM System z
October 2010
5. Figure 28. Java Processes and Management page, showing the Process Definition selection
6. Click Java Virtual Machine. See Figure 29.
70
Linux on IBM System z
October 2010
7. Figure 29. Process Definition page, showing the Java Virtual Machine selection
8. In the Generic JVM Arguments field, add this line:
"-Dsun.rmi.dgc.client.gcInterval=3600000 -Dsun.rmi.dgc.server.gcInterval=3600000"
See Figure 30.
71
Linux on IBM System z
October 2010
9. Figure 30. Java Virtual Machine page, showing the Generic JVM arguments field
10.
Click Apply.
11.
Click Review. See Figure 31.
72
Linux on IBM System z
October 2010
12.
Figure 31. Application servers page, showing the Review selection
13.
Click Synchronize Changes with Node.
14.
When synchronization completes, logout.
15.
Restart TPM.
73
Linux on IBM System z
October 2010
Appendix B. Guest setup
These instructions are used to set up the z/VM, TPM, DB2, ITDS, and DCD depot guests.
z/VM Linux guest setup
The resources for CPU, memory, and network are assigned as virtual devices to the z/VM guests.
Table 17 shows the definitions for the z/VM Linux guests. Note the following points:
 The depot server has a separate, directly attached OSA card (no VSWITCH), to avoid network
contention due to the high traffic volume created by the file transfers.
 The memory sizes for the TPM server and DB2 server were increased. Table 16 describes the
changes made in the memory allocated for various z/VM guests. The increase in DB2 memory was
required to reduce swapping at the Linux level when the workload was executed. Table 17
provides the overall summary view.
Table 16. Memory layout variations for the z/VM Linux guests
Memory values
TPM server
DB2 server
ITDS server
DCD depot
server
Initial memory values
10 GB
8 GB
2 GB
2 GB
Tuned memory values
13.5 GB
12 GB
1.5 GB
1 GB
Table 17. z/VM Linux guest setup
Number of
Amount of
virtual CPUs memory
Host name
Network interface
LNX00080
One internal NIC to VSWITCH testsw1 6
13.5 GB
TPM server
LNX00081
One internal NIC to VSWITCH testsw5 1
1 GB
Depot server
LNX00082
One internal NIC to VSWITCH testsw1 4
12 GB
DB2 server
LNX00083
One internal NIC to VSWITCH testsw1 1
1.5 GB
ITDS server
Function
The z/VM guests were interconnected by a z/VM guest LAN configured as a VSWITCH using these
commands:
CP DEF VSWITCH testsw1 RDEV 720 controller * ETH
CP DEF VSWITCH testsw5 RDEV 750 controller * ETH
TPM guest setup
To set up the TPM guest, these commands must be issued from a user with the correct privilege class
for the commands being issued.
/* base linux system packs */
74
Linux on IBM System z
October 2010
'ATT 7a85 LNX00080 7a85 '
:
'ATT 7db1 LNX00080 7db1 '
/* number of cpus */
'SEND CP LNX00080 DEF CPU 1'
'SEND CP LNX00080 DEF CPU 2'
'SEND CP LNX00080 DEF CPU 3'
'SEND CP LNX00080 DEF CPU 4'
'SEND CP LNX00080 DEF CPU 5'
/* nic adapter*/
'SEND CP LNX00080 define nic 6100 qdio '
'SEND CP LNX00080 couple 6100 to system testsw1'
/* storage size */
'SEND CP LNX00080 DEF STOR 13824M'
DB2 guest setup
To set up the DB2 guest, these commands must be issued from a user with the correct privilege class
for the commands being issued.
* base linux system packs */
'ATT 7b84 LNX00082 7b84 '
:
'ATT 7eb1 LNX00082 7eb1 '
/* number of cpus */
'SEND CP LNX00082 DEF CPU 1'
'SEND CP LNX00082 DEF CPU 2'
'SEND CP LNX00082 DEF CPU 3'
/* nic adapter*/
'SEND CP LNX00082 define nic 6100 qdio '
'SEND CP LNX00082 couple 6100 to system testsw1'
/* storage size */
'SEND CP LNX00082 DEF STOR 12G'
ITDS guest setup
To set up the ITDS guest, these commands must be issued from a user with the correct privilege
class for the commands being issued.
* base linux system packs */
'ATT 7b88 LNX00083 7b88 '
:
'ATT 7894 LNX00083 7894 '
/* nic adapter*/
'SEND CP LNX00083 define nic 6100 qdio '
'SEND CP LNX00083 couple 6100 to system testsw1'
75
Linux on IBM System z
October 2010
/* storage size */
'SEND CP LNX00083 DEF STOR 1536M'
DCD depot guest setup
To set up the TPM guest, these commands must be issued from a user with the
correct privilege class for the commands being issued.
* base linux system packs */
'ATT 7a93 LNX00081 7a93 '
:
'ATT 7b83 LNX00081 7b83
'
/* nic adapter */
'SEND CP LNX00081 define nic 6750 qdio '
'SEND CP LNX00081 couple 6750 to system testsw5'
/* storage size */
'SEND CP LNX00081 DEF STOR 1G'
76
Linux on IBM System z
October 2010
Appendix C. How to define the throttles
The global and the per task throttles are defined in the TPM version 7.1.1.1 setup.
Global throttle
This value is set in the $TIO_HOME/config/deploymentengine.xml configuration file. The default
value is 1000.
<deploymentengine>
<!-- The maximum number of concurrent workflows -->
<maximum-concurrent-workflows>1000</maximum-concurrent-workflows>
</deploymentengine>
Per thread throttle
This value is managed in the TPM user interface, under Global Settings. See Figure 32 for the path
to the Global Settings page. Select the Variable named default concurrency level. The field is at the
bottom of the panel, illustrated in Figure 33. The default value is 5. The minimum value is 1 and the
maximum value is 1024.
Figure 32. TPM version 7.1.1.1 Global settings page
77
Linux on IBM System z
October 2010
Figure 33. Setting the per thread throttle value
References
These references provide more information about some specific topics addressed in the TPM version
7.1.1.1 study.
 TPM version 5.1.1.1
 TPM 5.1.1.1: 64 Bit System z10 Benchmark Results IBM Integrated Service Management (ISM)
Library white paper
http://www.ibm.com/software/ismlibrary?NavCode=1TW10107R or
http://www.ibm.com/developerworks/linux/linux390/perf/tuning_pap_websphere.html#tpm
 Memory overcommitment
http://www.vm.ibm.com/perf/tips/memory.html
 Page reorder
http://www.vm.ibm.com/perf/tips/reorder.html
 TPM Version 7: A Deployment Engine Cluster Solution (Leitch, Zhao, Postea), IBM Integrated
Service Management (ISM) Library white paper
http://www.ibm.com/software/ismlibrary?NavCode=1TW1010889
 TPM and TSAM Version 7: Database Configuration and Hygiene Recommendations (Leitch), IBM
Integrated Service Management (ISM) Library white paper
http://www.ibm.com/software/ismlibrary?NavCode=1TW101088
78
Linux on IBM System z
October 2010
Notices
This information was developed for products and services offered in the U.S.A.
IBM may not offer the products, services, or features discussed in this document in other countries.
Consult your local IBM representative for information on the products and services currently
available in your area. Any reference to an IBM product, program, or service is not intended to state
or imply that only that IBM product, program, or service may be used. Any functionally equivalent
product, program, or service that does not infringe any IBM intellectual property right may be used
instead. However, it is the user's responsibility to evaluate and verify the operation of any non-IBM
product, program, or service.
IBM may have patents or pending patent applications covering subject matter described in this
document. The furnishing of this document does not grant you any license to these patents. You can
send license inquiries, in writing, to:
IBM Director of Licensing
IBM Corporation
North Castle Drive
Armonk, NY 10504-1785
U.S.A.
For license inquiries regarding double-byte (DBCS) information, contact the IBM Intellectual
Property Department in your country or send inquiries, in writing, to:
IBM World Trade Asia Corporation
Licensing 2-31 Roppongi 3-chome, Minato-ku
Tokyo 106-0032, Japan
The following paragraph does not apply to the United Kingdom or any other country where such
provisions are inconsistent with local law: INTERNATIONAL BUSINESS MACHINES
CORPORATION PROVIDES THIS PUBLICATION "AS IS" WITHOUT WARRANTY OF ANY
KIND, EITHER EXPRESS OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED
WARRANTIES OF NON-INFRINGEMENT, MERCHANTABILITY OR FITNESS FOR A
PARTICULAR PURPOSE. Some states do not allow disclaimer of express or implied warranties in
certain transactions, therefore, this statement may not apply to you.
This information could include technical inaccuracies or typographical errors. Changes are
periodically made to the information herein; these changes will be incorporated in new editions of
the publication. IBM may make improvements and/or changes in the product(s) and/or the
program(s) described in this publication at any time without notice.
79
Linux on IBM System z
October 2010
Any references in this information to non-IBM Web sites are provided for convenience only and do
not in any manner serve as an endorsement of those Web sites. The materials at those Web sites are
not part of the materials for this IBM product and use of those Web sites is at your own risk.
IBM may use or distribute any of the information you supply in any way it believes appropriate
without incurring any obligation to you.
Licensees of this program who wish to have information about it for the purpose of enabling: (i) the
exchange of information between independently created programs and other programs (including
this one) and (ii) the mutual use of the information which has been exchanged, should contact:
IBM Corporation
Software Interoperability Coordinator, Department 49XA
3605 Highway 52 N
Rochester, MN 55901
U.S.A.
80
Linux on IBM System z
October 2010
Terms and conditions
Permissions for the use of these publications is granted subject to the following terms and conditions.
Personal Use: You may reproduce these publications for your personal, noncommercial use provided
that all proprietary notices are preserved. You may not distribute, display or make derivative works of
these publications, or any portion thereof, without the express consent of the manufacturer.
Commercial Use: You may reproduce, distribute and display these publications solely within your
enterprise provided that all proprietary notices are preserved. You may not make derivative works of
these publications, or reproduce, distribute or display these publications or any portion thereof
outside your enterprise, without the express consent of the manufacturer.
Except as expressly granted in this permission, no other permissions, licenses or rights are granted,
either express or implied, to the publications or any data, software or other intellectual property
contained therein.
The manufacturer reserves the right to withdraw the permissions granted herein whenever, in its
discretion, the use of the publications is detrimental to its interest or, as determined by the
manufacturer, the above instructions are not being properly followed.
You may not download, export or re-export this information except in full compliance with all
applicable laws and regulations, including all United States export laws and regulations.
THE MANUFACTURER MAKES NO GUARANTEE ABOUT THE CONTENT OF THESE
PUBLICATIONS. THESE PUBLICATIONS ARE PROVIDED "AS-IS" AND WITHOUT
WARRANTY OF ANY KIND, EITHER EXPRESSED OR IMPLIED, INCLUDING BUT NOT
LIMITED TO IMPLIED WARRANTIES OF MERCHANTABILITY, NON-INFRINGEMENT, AND
FITNESS FOR A PARTICULAR PURPOSE
81
Tivoli Provisioning Manager version 7.1.1.1: Sizing and capacity planning
Copyright IBM Corporation 2010
IBM Systems and Technology Group
Route 100
Somers, New York 10589
U.S.A.
Produced in the United States of America,
10/2010
All Rights Reserved
IBM, IBM logo, DB2, DS8000, Rational, Service Request Manager, System Storage, System x, System z,
System z10, Tivoli, WebSphere, and z/VM are trademarks or registered trademarks of the International
Business Machines Corporation.
Adobe, the Adobe logo, PostScript, and the PostScript logo are either registered trademarks or trademarks
of Adobe Systems Incorporated in the United States, and/or other countries.
Cell Broadband Engine is a trademark of Sony Computer Entertainment, Inc. in the United States, other
countries, or both and is used under license therefrom.
InfiniBand and InfiniBand Trade Association are registered trademarks of the InfiniBand Trade Association.
Java and all Java-based trademarks are trademarks of Sun Microsystems, Inc. in the United States, other
countries, or both.
Microsoft, Windows, Windows NT, and the Windows logo are trademarks of Microsoft Corporation in the
United States, other countries, or both.
Intel, Intel logo, Intel Inside, Intel Inside logo, Intel Centrino, Intel Centrino logo, Celeron, Intel Xeon, Intel
SpeedStep, Itanium, and Pentium are trademarks or registered trademarks of Intel Corporation or its
subsidiaries in the United States and other countries.
UNIX is a registered trademark of The Open Group in the United States and other countries.
Linux is a registered trademark of Linus Torvalds in the United States, other countries, or both.
ITIL is a registered trademark, and a registered community trademark of the Office of Government
Commerce, and is registered in the U.S. Patent and Trademark Office.
IT Infrastructure Library is a registered trademark of the Central Computer and Telecommunications Agency,
which is now part of the Office of Government Commerce.
All statements regarding IBM’s future direction and intent are subject to change or withdrawal without notice,
and represent goals and objectives only.
ZSW03168-USEN-00
1