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.

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.

All information submitted is secure.

My developerWorks:

My notifications:

Sign out

Select a language:

Optimizing IBM DB2 pureScale transaction throughput in virtualized IBM Power Systems

Danny Leung (danleung@ca.ibm.com), Systems Optimization & Performance Analyst, IBM Canada Ltd.

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 (manand@us.ibm.com), PowerVM Performance Lead, IBM Corp.

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: 10681 views
Comments:

The optimization steps

There are actually several sets of steps that can be employed to realize performance gains on POWER7 servers. Each set is associated with its own series of pros and cons, allowing a client to select the one most appropriate for their situation. There is a solution that is quick and simple but provides limited performance increases; another solution that is more involved but allows for greater performance benefit; and a third solution with the heaviest of requirements but providing the greatest performance gains.

The simplest, and least-intrusive solution, is merely an update to the LPAR profile, (for example, increase maximum memory by 1 GB) while the LPAR is powered off. Upon a subsequent startup, you run an "in-place" re-allocation of resources.

The next option is to power down a finite number of non-critical LPARs, running chhwres on the deactivated LPARs (see step 3 below for chhwres details), and starting them up in the proper order (of importance; see step 4 below for startup order details). The resource domain with this option is the size of multiple LPARs, compared to the single LPAR domain size allowed with the previous solution, which is why this option contains greater optimization potential.

Similarly, the last option requires the most inconvenience, while creating the largest resource domain for the hypervisor to work with, thereby providing the best chance for the best allocation. The steps for this last solution set are as follows:

1.Power down all LPARs on the server, including the VIOS instances

The rest of these steps have the greatest efficacy if all hardware resources participate in the re-assignment. With a larger resource pool to work with, the optimization during LPAR startup (Step 4) tends to be greater. Thus, even though the problem was observed on the DB2 member, we can enlarge our resource pool by shutting down the other LPARs running on the system, such as the DB2 pureScale Cluster Cache Facility (CF) or the VIOS, or both.

2.Power cycle the server

Now that the hosts are safely shut down, power down the server, and then start it back up. This clears the hypervisor of any previous LPAR resource assignments, lending itself to a more optimized allocation of LPAR resources upon subsequent host startups (Step 4).

3.(Alternative to Step 2) Log in to the HMC and run chhwres for all LPARs on the server

There are situations where power cycling a server might not be feasible, despite all the LPARs being shut down. For example, perhaps the downtime of the LPARs is very short, such that the extra time needed for a power cycle is not available. As an alternative, you can clear the resource assignment information within the server hypervisor and the HMC by running the chhwres command from the HMC command line.

Listing 2. -r is to specify the resource type (‘mem’ is for memory), -m is to specify the managed system, -o is the operation (‘r’ is to remove the resource), -q is the quantity of the resource we want to operate on (in megabytes), and --id is the LPAR host ID that we are targeting.

                    chhwres –r mem -m "barcelona00-SN103EA7P" -o r -q 2048 --id 1
                    chhwres -r mem -m "barcelona00-SN103EA7P" -o r -q 2048 --id 2
                    chhwres -r mem -m "barcelona00-SN103EA7P" -o r -q 65536 --id 3
                    chhwres -r mem -m "barcelona00-SN103EA7P" -o r -q 65536 --id 4
                    chhwres -r mem -m "barcelona00-SN103EA7P" -o r -q 65536 --id 5
                    chhwres -r mem -m "barcelona00-SN103EA7P" -o r -q 65536 --id 6
                    chhwres -r mem -m "barcelona00-SN103EA7P" -o r -q 65536 --id 7
                    chhwres -r mem -m "barcelona00-SN103EA7P" -o r -q 65536 --id 8
                    chhwres -r mem -m "barcelona00-SN103EA7P" -o r -q 65536 --id 9

Figure 3 outlines the source of where some of the option values can be found.

Figure 3. Values needed for the chhwres command are found in several places of the HMC (v7) server view. Server name can be found near the top (see orange box on the top), LPAR IDs are under the "ID" column (green box on the left) and the amount of memory that needs to be cleared is found under the Memory column (red box on the right).

4.Activate LPARs in descending order of importance, that is, most-important LPARs first

Now that the hardware resources are completely free, it is time to re-optimize the resource associations. The hypervisor does a great job at calculating the optimal allocations, especially when there is an adequate resource pool to work with.

After these four steps, we see balanced performance across all three DB2 members. If the lssrad –av command was invoked again, all three LPARs would have similar, or even identical, resource allocations.

Figure 4. After re-aligning the resources, the imbalance is addressed and our newly added DB2 member is now performing to original expectations