If you work with mission critical databases you won’t have missed the launch of the Intel® Xeon® Processor E7 v2 Family with up to double performance over the previous generation. Benchmarks can be useful in comparing and contrasting systems and these show that E7 v2 has Up to 80% higher performance than IBM POWER7+ at up to 80% lower cost . Nevertheless working directly with customers evaluating database performance I often find that published benchmarks provide some but not all of the answers that database professionals are looking for including single and multi-threaded performance, power efficiency, platform cost, software cost, reliability and operating system and virtualization software choice.
As a consequence especially with a noticeable long term decline in the frequency of published benchmarks more and more customers have an engineering team to get ‘hands-on’ with evaluating systems for themselves. It is therefore great to see a white paper from Principled Technologies that shows the approach to do just that illustrating how a system built on the Intel Xeon processor E7-4890 v2 is a much better value proposition than POWER7+ for running the Oracle database. The white paper shows that the Xeon E7 v2 system has 69% lower hardware purchase costs, up to 42% lower power consumption under load and 40% under idle and 16% higher performance at equivalent load with twice the headroom to grow. All of this contributes to 5.7x performance/watt advantage for Xeon E7 v2.
More importantly for anyone taking the approach of ‘hands on’ evaluation the white paper includes all the details required for any database engineer to run their own equivalent in-house evaluation and not forgetting SPARC you can run equivalent tests against any system that runs Oracle or other databases. No-one should have to accept benchmark data prepared by competitive analysts and published without full details of system and database configuration.
I have to admit that as the author of HammerDB (Intel enabled engineers to develop open source projects long before it was fashionable) the load testing tool used in the white paper I especially like the open methodology as it aligns with the intentions for developing such a tool. Firstly being open source all of the code right down to the proprietary database drivers is published empowering the user. If you don’t like the workload you are free to change it – you can even write a whole new workload if you wish (HammerDB’s conversion of Oracle trace files makes this easy) and then contribute that workload back to the database testing community.
With this approach you may see from previous blog posts that typically the first test run I run is a PL/SQL CPU routine (or T-SQL on SQL Server) to test single-threaded performance and verify the system BIOS and operating system settings. Running this on an E7-4890 v2 gives me the following result:
Res = 873729.72
PL/SQL procedure successfully completed.
And comparing this with previous results shows good incremental gains and if you look at the other results for Intel Core then there are indications of further gains from future Xeon products from Intel’s Tick-Tock model. It would be great if you could fully test a database system in under 10 seconds however such a single-threaded test is only a first indicator, a small piece of the puzzle in evaluating database performance. Of course such as test tells us nothing of the platform scalability running multiple threads however the historical results show that the single-threaded performance is improving in step with the Tick-Tock model and you would expect better single-threaded performance from a processor that completes this test in a shorter time.
This is where HammerDB comes in. You can either run your own workload or one based on the specifications of industry standard benchmarks. The advantage of these specifications is that they are relatively straightforward to implement but more importantly they are designed to scale and have proven over time that they do scale so as long as the database software and system scales, then you have a workload that scales as well. Importantly it is not the absolute performance but the relative performance that is important and your aim should be to generate a Performance Profile. What this means is that you should test your system at ever increasing increments of load until it is fully saturated. HammerDB includes a CPU monitor and at the top of your performance curve with a scalable workload and sufficient I/O your CPU utilisation should look as follows:
With this reference data you then have the background information to measure and test a median load that you would expect from a typical production database and this is the approach that the Principled Technologies white paper takes.
As the white paper shows another important metric is the power consumed by the server for a relative level of performance. At data centre scale power consumed is one of the most important metrics for server density. Starting with the processor the power related metric is called TDP (Thermal Design Power) and indicates the power dissipated at the operating temperature called Tcase, further information is available here. So although TDP will not give you all the information on peak CPU power requirements it remains the most useful processor metric for comparison. If you want to know the max TDP for the E7 v2 family they are all published here showing a Max TDP ranging from 105W to 155W. Unfortunately for doing an evaluation the same data is not published for the IBM Power family, for SPARC it is published on the datasheet for the SPARC T-4 at 240W however is omitted from the equivalent datasheet for the SPARC T-5. Consequently the Principled Technologies approach is ideal measuring the entire server power both idle and under load – a 5.7x performance/watt advantage translates into a significant advantage for server density for a data centre running E7 v2 compared to Power7+.
Hardware and Software Cost and Choice
After having measured both performance and power you can then evaluate cost. This takes the form of evaluating both the hardware acquisition cost as well as the software cost both comprising the TCO (Total Cost of Ownership). As the white paper shows there is a 3.2X advantage for the E7 v2 system compared to the IBM system in hardware acquisition cost however a significant component of the TCO is the software license cost. Given that the Oracle Database license is calculated per core and the IBM Power system has 32 cores compared to the 60 on the Intel E7 v2 system it is important to reference the Oracle Processor Core Factor Table, this shows that the Power 7+ attracts a core factor of 1.0 compared to the 0.5 factor for the E7 v2 – this means that as well as offering higher performance the E7 v2 system also has a lower Oracle software license cost. Additionally for the core based cost sensitive with the E7 v2 there are further options up to the E7-8893V2, with 6 cores running at higher frequencies under the same TDP allows choice in managing core factor based software acquisition cost. Furthermore, choosing E7 v2 means that the same industry standard platform is available from multiple vendors supporting multiple operating systems such as Linux, Windows and VMware, relational databases such as SQL Server, PostgreSQL and MySQL and Big Data technologies such as Hadoop, giving unparalleled technology choice all helping to drive down acquisition cost and improve manageability by standardising systems and system administrator skills.
Of course some attributes by their nature are more difficult to measure than others. RAS (Reliability, Availability and Serviceability) by definition is harder to quantify as it is harder to measure something that is expected not to happen (like a service outage) rather than something that does. Therefore evaluating RAS for E7 v2 requires looking at the features of Intel® Run Sure Technology and the longer term uptime data proving out reliability in the animation.
In this post we’ve looked at how the white paper from Principled Technologies illustrates a methodology for bringing platform evaluation in-house for comparing database performance. We’ve seen how database benchmarks published along with full configuration information can provide useful indicators however the declining frequency of these publications and the availability of free and open source tools is giving rise to the increased popularity of this in-house testing to determine the ‘best-fit’ database platform freeing information and enabling better data centre technology choices than ever before.