In OLTP with heavy network benchmarks conducted with DB2 on Solaris 10, it was found that often there is a need of putting DB2 on their own pool of processors specially seperating them from processors that are also servicing the network and also by exploiting the FX scheduler for DB2 without making it the default for the system.
Here is a quick guide on how to use DB2 in Solaris 10 resource pools.
Considering you have followed the setup very similar to my previous blog entry. Here are the additional steps to configure pools for DB2. (This entry assumes that you have not enable pools before on your system)
Enable pools on your system using the following command
# pooladm -e
Now initialize the pools based on your existing environment as a starting point
# pooladm -s
Now view the existing pool configuration using the following command
You will see that it has a default pool called pool_default and a default processor set called pset_default. We now carve out a processor set and pool for DB2 from it. Assume that the current pset_default has about 16 processors in it and the system has two active devices on it. Then we can allocate DB2 with about 14 processors as follows:
Create a text file called pool.host with the following contents
modify pset pset_default (uint pset.min=2; uint pset.max=2)
create pset db2pset (uint pset.min=14; uint pset.max=14)
create pool db2pool (string pool.schedule="FX")
associate pool db2pool (pset db2pset)
Then modify the existing pool configuration as follows
# poolcfg -f pool.host
Activate the modified pool configuration
# pooladm -c
Verify the changes using the following command:
Also we get more bang for the buck by turning off interrupts on these dedicated pool for DB2. This can be achieved by observing the cpu ids assigned to db2pset and turning them off as follows:
# psradm -i 0-14
Where CPU IDs 0 to 14 are assigned to db2pset. (Your CPU IDs may vary)
Now you have pools setup for DB2. To make DB2 use its own pool we again use the projects database to setup the default pool for the DB2 Instance owner to use the new pool (assuming you have already defined project user.db2inst1)
# projmod -a -K "project.pool=db2pool" user.db2inst1
Now for a single partitioned database instance, when you login using a fresh shell and issue db2start it will start the database in db2pool. If you are using DPF then you have to use db2nodes.cfg to set the pool name as the 5th column of the logical node entries.
If for some reason you want to revert to default setup then it can be done as follows
# pooladm -x
And also if you want to disable the pool facilities then you use
# pooladm -d
Now the real benefit for customers by seperating the CPUs for network and system resoures and DB2 is License fees. You can now use sub-capacity licensing here only for the size of the pool used for DB2 and donot pay the DB2 License for the CPUs which are only doing network, disk and other system activities. This way you get the maximum saving and returns on the investment in DB2 on Solaris 10.