In order to get more bang for your buck, you really need to have a look at DB2 Symmetric Multiprocessing.
In the last couple of years, I've been turning on more POWER processor cores in order to compensate for an increased workload for our IBM i partitions. At the moment, I have 2.5 cores assigned to my primary partition and 0.5 cores assigned to a guest partition. Only a few years ago, we were using a fraction of a single POWER7 core's potential.
The workloads we've been adding are heavy on the SQL side of the database coin. Databases are DDL-based instead of DDS-based. We're going to be hitting our databases with standard SQL queries from Business Intelligence (BI) tools on a very regular basis rather than launching RPG programs attached to printer files to spool output. To say we're becoming more SQL- and database-conscious is an understatement.
Since I'm now working in a multi-core world, I can choose to use my iron a little differently to make sure I'm getting the most value out of the cores that I turn on. That's where DB2 Symmetric Multiprocessing comes into play.
DB2 Symmetric Multiprocessing is an optional installable feature for IBM i (5770-SS1, option 26). It's a chargeable feature based on the processor tier.
How does it work?
All IBM i jobs compete for time on a processor core. As processors have gotten faster over time, they've now topped out around the 5 GHz mark for speed. A processor arguably can only go so fast. With the topping out of speed, processors are getting more powerful by the amount of cores available per processor. The current POWER8 chips are down to a 22 nanometer process compared to 32 on POWER7+ and 45 on POWER7, with up to 12 cores per chip compared to 8 on the POWER7.
When you buy an instance of the IBM i operating system, you're entitled to use it on one core. If you want to turn on additional cores, you need to buy another instance of IBM i. That means you can use two full cores on the one IBM i partition, or two cores divided amongst a number of IBM i partitions. For example, you can have 1.0 core on partition A, 0.4 core for partition B, and 0.6 core for partition C.
If you have a partition with a single instance of IBM i and subsequently one core activated, all jobs are competing for processing time on that single core. Jobs can stack up, especially if the workload exceeds the processing capability of the core. Now, if you have multiple cores, partition jobs can be sent to either one of those cores for processing. The more cores you assign to the partition, the higher the throughput. Makes sense, right?
Now this is where DB2 Symmetric Multiprocessing comes into play.
Let's say you have a big job that's very processor-intensive. A single core will chew away at that job until it's done. The other cores are sitting there idling or taking care of other jobs coming along. DB2 Symmetric Multiprocessing allows the logical division of a big job into smaller jobs so that they can be tackled equally by all processor cores within that partition at the same time. This is called parallelism, or symmetric multiprocessing (SMP).
The degree of parallelism is defined a couple of different ways.
The easiest is the QQRYDEGREE system value. The options for this are:
- *NONE—This means that a job will use only one processor core, no matter how many are assigned to the partition.
- *IO—Any number of tasks may be used when the database query optimizer chooses to use I/O parallel processing for queries. Parallel processing is not used.
- *OPTIMIZE—This is the least intrusive option for parallel processing. This means that a job will take a reasonable share of processing and memory resources for symmetric multiprocessing or choose I/O processing instead, depending on available resources.
- *MAX—A job will attempt to use all processing power across all cores and system memory to complete. I wouldn't recommend this for "middle of the day" processing.
You can also turn it on for a specific job by using the Change Query Attributes (CHGQRYA) command or the SET CURRENT DEGREE SQL statement. This is a great way to test out parallelism on big jobs without affecting the entire system.
Personally, I was comfortable turning the QQRYDEGREE system value to *OPTIMIZE at 9:00 PM on a Saturday night and letting it do its thing to weekend jobs. I saw about a 20% increase in job completion time for those jobs, so I didn't turn it off. Overall, the processor utilization on my system was hovering around 45-55% with spikes to 70% for overnight jobs before I made the change to use DB2 Symmetric Multiprocessing. After I made the change, the utilization now hovers around 20-25% throughout the day and jumps to 50% briefly for overnight jobs. I'm assuming this is because I have multiple cores properly sharing the load of some individual jobs, causing far less contention.
Figure 1: This is the processor utilization before SMP.
Figure 2: This is the processor utilization after SMP.
Of course, your mileage may vary. These results are on the Wednesday before and the Wednesday after the SMP change. The results for other days of the week before and after the change support the highlighted results. I have a much more processor-efficient partition now.
In the spirit of full disclosure, I'm running POWER8 with solid-state drives (SSDs) in the system ASP and SSDs)in an IASP. The system was blazing fast to begin with, but before I made the SMP change I was really curious why the processors were running so hot. Response time wasn't an issue, but Performance Data Investigator (where I took those screen shots inside IBM Navigator for i) was stating I had a high amount of CPU contention. For my partition, it was the way the workload was getting spread across the cores. That's what led me down the path to investigate DB2 Symmetric Multiprocessing and get more value out of those cores.
The great thing about DB2 Symmetric Multiprocessing is that, other than setting the degree, IBM i takes care of the precise and complex task of splitting a single job among processor cores. I couldn't imagine the engineering that happened to create this feature. Luckily, the customer just turns the feature on and lets the system handle it.
Some of you might be thinking, "Hey, Steve, this feature has been around since 1995. This isn't really new software. Why should I care?"
Very true! It's not new at all. This feature was introduced back in V3R1, when the average customer didn't run n-way machines. It wouldn't make sense on a 1-way AS/400 250 with about as much horsepower as a My Little Pony toy. Nowadays, the smallest POWER8 box you can buy has four cores. With more customers turning on more cores in order to provide additional processing power for increased workloads, knowing about DB2 Symmetric Multiprocessing could be a real win for your shop because you're actually using those cores to their fullest ability.