Regardless of what kind of CPU binding mechanism is used at the
Db2 level, the bindings will always be subject to actions by the
hypervisor. Furthermore, the benefits of CPU binding depend
largely upon the underlying hardware topology and the specific ways
in which you're exercising Db2.
Have you experienced performance problems in the past that were
improved by the use of resource binding? Or is this something
that you're just interested in trying out?
While DB2_CPU_BINDING is really intended for Db2 pureScale with
co-located members and CFs, it can be used in a DPF scenario.
However, you cannot use the NUM_CORES option since the logic for
this registry variable does not handle multiple co-located
members. (It will end up assigning the same set of resources
to each member.)
Instead, you can use the PROCESSOR_LIST option so that you can
specify the CPUs.
db2set -i dbi2nst1 0 DB2_CPU_BINDING="PROCESSOR_LIST=13"
db2set -i dbi2nst1 1 DB2_CPU_BINDING="PROCESSOR_LIST=1,2,3,4"
db2set -i dbi2nst1 2 DB2_CPU_BINDING="PROCESSOR_LIST=5,6,7,8"
db2set -i dbi2nst1 3
You will see entries like this in your db2diag.log files:
DIAG0000/db2diag.log:CPU binding: num cores:0.500 processor list:
DIAG0001/db2diag.log:CPU binding: num cores:2.000 processor list: 1
2 3 4
DIAG0002/db2diag.log:CPU binding: num cores:2.000 processor list: 5
6 7 8
DIAG0003/db2diag.log:CPU binding: num cores:2.000 processor list: 9
10 11 12
You will also need to manually interrogate each instance-level
registry when listing the current db2set values, as 'db2set -all'
won't show them.
$ db2set -i db2inst1 0 -all
$ db2set -i db2inst1 1 -all
$ db2set -i db2inst1 2 -all
$ db2set -i db2inst1 3 -all