Scaling IBM DB2 Database Application on Sun Fire X4470

I've recently been working on a performance study of running IBM DB2 database on the new Sun Fire X4470 server, which is based on the Intel Xeon CPU X7560. This blog entry is a case study of scaling DB2 on the Sun Fire X4470 by using Solaris Container technology. The performance on the X4470 was measured by running an OLTP workload that has been built in-house. It simulates a Global Order System that stresses lock management and connectivity.

Environment Setup:

The X4470 server as tested is a quad socket server with 32 cores/64 threads. DB2 v9.7.1 database was installed on the X4470 with Solaris 10 10/09 which was then connected to the Sun Storage 7410 system via a PCI-E 10GgbE network adapter.  The Sun Storage 7410 was configured with two Sun Storage J4400 arrays, containing 47 1TB SATA drives which were configured into a triple mirrored volume. The iSCSI LUNs were created to host the DB2 table space containers and log containers. A UFS file system was created on each LUN and mounted with directio option.

Deploying DB2 on Solaris Containers:

The X4470 is designed for scalable performance, flexible virtualization / software consolidation, and advanced reliability. In many cases, a single application instance may not fully utilize such a powerful system. We have found that the test workload application running in a single instance of DB2 doesn't scale well beyond 2 sockets on X4470. To overcome the scaling issue of the application, we may configure multiple DB2 instances running the same application on one system. Along with the use of the virtualization technologies such as Solaris Container, which can provide excellent application level isolation and resource isolation for CPU, memory and network. In this case study, four instances of DB2 were deployed in four Solaris Containers and they are all running the same OS level on the X4470, as shown in the following diagram.


DB2 binaries were installed under the /opt directory in the global zone. The binaries were exported to other four containers so that there is no need to install DB2 in each container. Each DB2 instance was bound to a resource pool of 16 virtual CPUs (1 socket) and running in Fixed Priority scheduling class. Binding DB2 processes to a resource pool also gives nice memory locality. Each DB2 instance had two dedicated file systems (the file systems created on the iSCSI LUNs) imported from the global zone. There are five workload drivers. The master driver is in the global zone which controlled the other four slave workload drivers in the four Containers. Each workload driver generated workload to the DB2 instance that resided in the same container to avoid overhead on the network.

Here are the commands to create one of the Solaris Container:

 # zonecfg -z zone1
zone1: No such zone configured
Use 'create' to begin configuring a new zone.
zonecfg:zone1> create
zonecfg:zone1> set zonepath=/zones/zone1
zonecfg:zone1> set autoboot=true
zonecfg:zone1> set pool=pool_zone1
zonecfg:zone1> add inherit-pkg-dir
zonecfg:zone1:inherit-pkg-dir> set dir=/opt
zonecfg:zone1:inherit-pkg-dir> end
zonecfg:zone1> add net
zonecfg:zone1:net> set address=
zonecfg:zone1:net> set physical=nxge0
zonecfg:zone1:net> end
zonecfg:zone1> add fs
zonecfg:zone1:fs> set dir=/data1
zonecfg:zone1:fs> set special=/data1
zonecfg:zone1:fs> set type=lofs
zonecfg:zone1:fs> add options [forcedirectio]
zonecfg:zone1:fs> end
zonecfg:zone1> add fs
zonecfg:zone1:fs> set dir=/log1
zonecfg:zone1:fs> set special=/log1
zonecfg:zone1:fs> set type=lofs
zonecfg:zone1:fs> add options [forcedirectio]
zonecfg:zone1:fs> end
zonecfg:zone1> verify
zonecfg:zone1> commit
zonecfg:zone11> exit

The resource pools were created using the following commands:

poolcfg -c 'create pset pset_zone1 (uint pset.min = 16; uint pset.max = 16)'
poolcfg -c 'create pool pool_zone1'
poolcfg -c 'associate pool pool_zone1 (pset pset_zone1)'
poolcfg -c 'create pset pset_zone2 (uint pset.min = 16; uint pset.max = 16)'
poolcfg -c 'create pool pool_zone2'
poolcfg -c 'associate pool pool_zone2 (pset pset_zone2)'
poolcfg -c 'create pset pset_zone3 (uint pset.min = 16; uint pset.max = 16)'
poolcfg -c 'create pool pool_zone3'
poolcfg -c 'associate pool pool_zone3 (pset pset_zone3)'

Container Scaling Results:

For this set of tests, four DB2 instances and containers were started one by one until all of them are running to achieve the maximum throughput on the system. The following figure illustrates these results graphically. The system was fully utilized when 4 containers are running. More than 95% of the whole system CPU capacity was used in peak throughput with 4 containers. As a baseline to compare, the out-of-box throughput result of running only 1 DB2 instance without using containers is also shown.


Without using containers and resource pools, the throughput is poor and workload can only drive 20% of the CPU resource. Without pinning the DB2 processes into a resource pool, the overhead of the context switches and memory latency further constraint the performance. Having the DB2 run in one container and bound to a resource pool, the throughput is improved by 22%. Running the workload in two DB2 instances in two containers, the throughput is increased by 2.51 times. In the three containers case, it is 2.96x speedup. And when there are 4 containers running 4 DB2 instances, we end up having 3.68x speedup in transaction throughput.


The case study demonstrates that we can take the advantage of the Solaris Container technology to scale or consolidate applications on a single system. With Solaris Container technology, we can have the flexibility to maximize DB2 performance and system utilization by running multiple DB2 instances on the Sun Fire X4470 server.


Post a Comment:
  • HTML Syntax: NOT allowed

This is a blog to talk about technical information regarding running IBM DB2 database on Solaris.


« July 2016