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:
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.
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).
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).
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.