The case scenario
In the following hypothetical situation, we have a database administrator who wants to add a new DB2 pureScale member,
host5, to a DB2 pureScale instance running on a single IBM Power System™ 770 test system,
barcelona00-SN103EA7P, such that the instance configuration looks like this:
Listing 1. The DB administrator wants to add host05 to the instance to have its db2nodes.cfg file look like this
0 host3 0 192.168.0.4 - MEMBER 1 host4 0 192.168.0.5 - MEMBER 2 host5 0 192.168.0.6 - MEMBER 128 host1 0 192.168.0.2 - CF 129 host2 0 192.168.0.3 - CF
After the successful DB2 member addition, the database administrator finds that the transaction throughput performance looks like the following example in Figure 2:
Because DB2 members are generally identical, (for example, same database, OS and LPAR configurations), optimization techniques within the OS and DB layers of
host5 have little effect. Rather, the area with the greatest optimization potential would be the virtualization layer, where physical resources are mapped to virtual devices. For an LPAR's processor and memory, the AIX command,
lssrad –av, lists the Scheduler Resource Allocation Domains (SRADs). Understanding the SRAD layout helps us visualize the physical-virtual mapping for the host in question. A difference in the lssrad output, as shown in Table 1, would suggest a possible source of the transaction throughput discrepancy.
Table 1. Notice the increased spread of the resources across several SRADs for host05, with resources distributed over four MCMs from two processor “books” compared with host03/04, where resources are taken from two MCMs on a single book.
From this sample output, the administrator can deduce that the performance characteristics on LPAR
host05 can be improved if its distribution of processor and memory resources is more compact, similar to
host03/04. The most effective way to implement the redistribution is to clear the hardware resource assignments.