This is a guest blog post written by Michael Bradburn*, a Lead Senior Technical Solutions Architect with Cisco. However, as Michael states at the end of this article, the opinions expressed in this article are his own, and do not necessarily reflect the opinion of the company he works for today, or may work for tomorrow. The article originally appeared on LinkedIn.
*UPDATE – Intel will be selling CLX and CLXR processors side by side until Ice Lake, thus making the scenario below more of a “what-if” scenario at the moment. Ice Lake details will not be available for a bit of time, so for now I am hoping this helps in the decision making at Intel to keep building on the Frequency Optimized processors that CLX has today.
The next generation of the Cascade Lake processor, known simply as Cascade Lake Refresh (“R”), is going to do a number on Oracle customers who pay per core for Oracle licenses on industry standard hardware. Several years ago Intel® acknowledged the fact that workloads like Oracle actually perform very well with higher speed, lower core processors. It was a trade-off to the ever escalating core counts that were getting introduced. Instead of breaking the processor up into many 2 GHz processors, they could put fewer cores at 3 GHz or higher to help with licensing with software like Oracle that is licensed per core. It also helped with the amount of cache shared between the corers, giving some processors more cache per core, further helping Oracle workloads. They called this line of processors Frequency Optimized Processors.
SPEC Integer Throughput numbers showed that you could use significantly fewer of the Frequency Optimized Processors to do the same work as more of the lower GHz models in the Intel® mainstream line. More work per core related to fewer cores needed, which in turn related to fewer Oracle licenses needed. For the first round of Cascade Lake, we actually saw an increase in the number for part numbers that fell under this Frequency Optimized Processor umbrella. Here are the Cascade Lake processors that loosely fall under this umbrella:
- Intel® Xeon® Gold 5222, 4 cores, 3.8 GHz, 16.5 MB Cache, 2933 MHz, 105W
- Intel® Xeon® Gold 6234, 8 cores, 3.3 GHZ, 24.75 MB Cache, 2933 MHz, 130W
- Intel® Xeon® Gold 6244, 8 cores, 3.6 GHz, 24.75 MB Cache, 2933 MHz, 150W
- Intel® Xeon® Gold 6246, 12 cores, 3.3 GHz, 24.75 MB Cache, 2933 MHz, 165W
- Intel® Xeon® Gold 6254, 18 cores, 3.1 GHz, 24.75 MB Cache, 2933 MHz, 200W
The processors that I usually recommend the most when sizing Oracle are the 5222, 6234 and the 6244. The higher amounts (3-4MB) of cache per core can really benefit the Oracle processes and the higher GHz speeds allow more work to be done at the core level. All of the processors listed will run at the max bus speed provided by an x86_64 bus available today and are Turbo enabled.
In contrast, the Intel® Cascade Lake Refresh replacement for the Cascade Lake processors has a lot to be desired for Oracle workloads. The processors that Intel® is offering that may traditionally fall under the Frequency Optimized Processor line are as follows:
- Intel® Xeon® Silver 4215R, 8 cores, 3.2 GHZ, 11 MB Cache, 2400 MHz, 130W
- Intel® Xeon® Gold 6246R, 16 cores, 3.4 GHz, 35.75 MB Cache, 2933 MHz, 205W
- Intel® Xeon® Gold 6242R, 20 cores, 3.1 GHz, 35.75 MB Cache, 2933 MHz, 205W
- Intel® Xeon® Gold 6248R, 24 cores, 3.0 GHz, 35.75 MB Cache, 2933 MHz, 205W
Skylake and Cascade Lake started to really “stretch” the definition of Frequency Optimized Processor. Starting with Skylake, Intel® added 12 and 18 core options at 3.0 GHz or higher (compared to Broadwell and before). Now with the “R” processors, we see the the whole thing shift to the right, losing the total benefits that the Frequency Optimized line of processors was originally designed to help with. We lost the 6 core offering with Cascade Lake and we have now lost the 4 core option with “R”. You could argue with the 4215R option for an 8 core offering, but I will tell you I will never recommend a processor with less cache and slower bus speed than its presumed predecessors (6234/6244). The 6246R is 16 cores instead of 12 (6246), which automatically makes it more expensive to license than its predecessor. I very seldom size with processors greater than 16, so while there is the 6248R, I will find it hard to use and still offer a solution that is affordable to license.
And an example, if a sizing for a customer said they need 8 cores to run as particular Oracle workload, I would put two 5222 processors in a two socket box, add another for N+1 and license the whole solution for Oracle and have a solid HA solution. Now, I am forced to use the 6242R, quadrupling the number of cores, thus quadrupling the number of Oracle licenses, which will cost significantly more money than the hardware I would have normally proposed. We could disable cores at the firmware level, use a hypervisor and use anti-affinity rules, etc., but this just makes things a bit more messy than was necessary in the past. It also wakes up the momma bear in Oracle LMS, which is an issue for some customers, though more and more are fighting back with the options that are available today by third party SI’s. Once again, it is just unnecessarily messy now.
My advice here is for those Oracle customers who can benefit from Frequency Optimized 4, 8 and 12 core processors for their Oracle environments, buy now. You will undoubtedly lose that ability in the very near future.
*Opinions written in this article are of my own and do not necessarily reflect the opinion of the company I work for today or tomorrow.
