Skip to main content

By clicking Submit, you agree to the developerWorks terms of use.

The first time you sign into developerWorks, a profile is created for you. Select information in your profile (name, country/region, and company) is displayed to the public and will accompany any content you post. You may update your IBM account at any time.

All information submitted is secure.

  • Close [x]

The first time you sign in to developerWorks, a profile is created for you, so you need to choose a display name. Your display name accompanies the content you post on developerworks.

Please choose a display name between 3-31 characters. Your display name must be unique in the developerWorks community and should not be your email address for privacy reasons.

By clicking Submit, you agree to the developerWorks terms of use.

All information submitted is secure.

  • Close [x]

developerWorks Community:

  • Close [x]

Optimizing IBM DB2 pureScale transaction throughput in virtualized IBM Power Systems

Danny Leung (, Systems Optimization & Performance Analyst, IBM Canada Ltd.
Danny Leung
Danny has been with IBM for five years and is a member of the Systems Optimization Competency Center (SOCC) team based in Toronto. His main area of focus is on the POWER7 architecture running OLTP DB2 pureScale database workloads.
Mala Anand (, PowerVM Performance Lead, IBM Corp.
Photo ofMala Anand
Mala is a Senior Technical Staff Member at IBM Systems and Technology Group System Performance. She leads the Power Virtualization performance testing, focusing on processor and memory virtualization and IBM PowerVM competitive performance. She previously led network and enterprise workload performance efforts on x86 Linux at the IBM Linux Technology Center.

Summary:  Today, hardware virtualization is prevalent throughout the IT industry. Having a single server perform the same amount of work previously done by several, is a great a value proposition for companies of any size. Although there are volumes of documentation available — both online and printed — the vastness of the resources make it difficult to navigate them. This article begins to address that challenge by providing a list of high-level, planning-and-deployment best practices, followed by a series of lower-level optimization steps using a sample database environment running an IBM DB2® pureScale® installation for IBM POWER7® servers.

Date:  12 Jun 2012
Level:  Intermediate PDF:  A4 and Letter (701 KB | 11 pages)Get Adobe® Reader®

Activity:  12358 views

Best practices

As physical servers provision additional resources for additional VMs, the need to optimize hardware usage becomes greater in order to maximize server performance. The following set of best-practice suggestions should help you with ensuring that the optimal configuration is achieved and maintained.

1. Understand and document the intentions, purposes and goals of the server

Documenting the server's goals not only helps system architects and administrators focus their planning on a finite list, but provides a document that can be referenced for new teams or members using this server in the future. Even if the usage patterns are not constant, maintaining a living document provides value by maintaining the team's agreement of how the server is being used. Using the IBM System Planning Tool (SPT) should make this step fairly trivial. Further SPT details can be found in the Miscellaneous section under References at the end of this document.

2. Ensure that the system firmware is up to date

To get the best-performing hypervisor, have the system installed with the latest release of the firmware for the machine being used. If a Hardware Management Console (HMC) is set up, you can use its maintenance functionality to perform the updates for you.

Figure 1. After you have selected the server, expand the “Updates” task to see the “Upgrade Licensed Internal Code to a new release” option.

Further details for firmware updates can be found in the Firmware Update Procedure section under References at the end of this document.

If the HMC is not being used to update the server, an alternate method would be to manually download the patches through the IBM support site, which also provides patches and updates for other components like the HMC or SPT.

3. Determine the proper hardware resource topologies (processor, memory, disk etc.) for the LPARs

After understanding what the server will be used for, the planned hosts need to be resourced appropriately to carry out that purpose in the most effective way. This does not just refer to the quantity of the resources (for example, 32 compared to 16 processors, 256 GB compared to 128 GB RAM), but also to the manner in which they are to be virtualized: shared processing, dedicated processing, dedicated-donate processing, active memory sharing, active memory deduplication, Virtual I/O Server (VIOS) deployments etc.

Further documentation for virtualization best practices can be found online. Refer to the Virtualization section under References.

4. Power on the most important LPARs first

The processor-memory and processor-processor affinities are important factors for system performance. The fewer the Multi-Chip Modules (MCMs) and Central Electronic Complex (CEC) enclosures the LPAR resources are spread across, the better it will perform. The hypervisor computes the best, most-aligned, resource assignments to a starting LPAR based on the current resource pool that exists. It also remembers the resource allocations it computes for an LPAR from its first startup. Therefore, it is vital that the processor and memory resource pool is made as large as possible to produce the best affinities. After, it is equally vital that the most processor- and memory-critical LPARs are activated first, to ensure they get the best chance for being assigned the most optimal resource alignments.

In the strictest sense, this is only needed when the hypervisor has no allocation for the server LPARs. That is, the startup order of a server is important only if there are LPARs that have never been activated or started, or LPARs whose resource allocations were cleared (for example, using chhwres). For example, if a system administrator is shutting down the running LPARs, power cycling the server, and starting those same LPARs, the startup order does not matter: the hypervisor has the information that it needs to optimize the LPAR resource allocations during server startup time. However, it might be easier to start the LPARs in order of importance anyway, so that one does not need to track chhwres or LPAR creation events.

The minor tradeoff to this practice is a somewhat unintuitive startup order, where the VIOS instances are powered on last. This implies that while the most important LPARs are started first, they will not actually be operational — spinning with the platform firmware code, AA060011 — until the VIOS is up and running.

2 of 6 | Previous | Next


Zone=AIX and UNIX
TutorialTitle=Optimizing IBM DB2 pureScale transaction throughput in virtualized IBM Power Systems