X

Everything you want and need to know about Oracle SPARC systems performance

Simultaneous OLTP & In-memory Analytics: SPARC S7-2 Advantage Per Core Under Load Compared to 2-Chip x86 E5-2699 v3

Brian Whitney
Principal Software Engineer

A goal of the modern business is real-time enterprise where analytics are run simultaneously with transaction processing on the same system to provide the most effective decision making. Oracle Database 12c Enterprise Edition utilizing the Oracle In-Memory option is designed for the same database to be able to perform transactions at the highest performance and to perform analytical calculations that once took days or hours to complete orders of magnitude faster.

Oracle's SPARC S7 processor has deep innovations to take the real-time enterprise to the next level of performance. In this test both OLTP transactions and analytical queries were run in a single database instance using all of the same features of Oracle Database 12c Enterprise Edition including the Oracle In-Memory option in order to compare the advantages of the SPARC S7 processor to the Intel Xeon Processor E5-2699 v3.

The SPARC S7 processor uses the Data Analytics Accelerator (DAX). DAX is not a SIMD instruction, but rather an actual co-processor that offloads in-memory queries which frees the cores up for other processing.  The DAX has direct access to the memory bus and can execute scans at near full memory bandwidth. Oracle makes the DAX API available to other applications, so this kind of acceleration is not just available to Oracle Database.

  • Oracle's SPARC S7-2 server ran the in-memory analytics RCDB based queries 2.3x faster per chip under load than a two-chip x86 Intel Xeon Processor E5-2699 v3 server on the 24 stream test. Furthermore, the SPARC S7-2 server ran the in-memory analytics RCDB based queries 5.1x faster per core under load than the same x86 server.

  • The SPARC S7-2 server and the two-chip Intel Xeon Processor E5-2699 v3 server both ran OLTP transactions and the in-memory analytics on the same database instance using Oracle Database 12c Enterprise Edition utilizing the Oracle In-Memory option.

Performance Landscape

The table below compares the SPARC S7-2 server and 2-chip x86 Intel Xeon Processor E5-2699 v3 server while running OLTP and in-memory analytics against tables in the same database instance. The same set of transactions and queries were executed on each system.  All of the following results were run as part of this benchmark effort.

 
Real-Time Enterprise Performance Chart
24 RCDB DSS Streams, 112 OLTP users
Simultaneous Mixed
Workload
SPARC S7-2 2-Chip
x86 E5 v3
SPARC Per Chip
Advantage
SPARC Per Core
Advantage
OLTP Transactions
(Transactions per Second)
195,790 216,302 0.9x 2.0x
Analytic Queries
(Queries per Minute)
107 47 2.3x 5.1x

Configuration Summary

SPARC Server:

1 X SPARC S7-2 server
2 X SPARC S7 processor
512 GB Memory
Oracle Solaris 11.3
Oracle Database 12c Enterprise Edition Release 12.1.0.2.0

x86 Server:

1 X Oracle Server X5-2L
2 X Intel Xeon Processor E5-2699 v3
256 GB Memory
Oracle Linux 6.5 (3.8.13-16.2.1.el6uek.x86_64)
Oracle Database 12c Enterprise Edition Release 12.1.0.2.0

Benchmark Description

The Real-Time Enterprise benchmark simulates the demands of customers who simultaneously run both their OLTP database and the related historical warehouse DSS data that would be based on that OLTP data. It answers the question of how a system will perform when doing data analysis, while at the same time executing real-time on-line transactions.

The OLTP workload simulates an Order Inventory System that exercises both reads and writes with a potentially large number of users that stresses the lock management and connectivity, as well as, database access.

The number of customers, orders and users is fully parametrized.  This benchmark is base on 100 GB dataset, 15 million customers, 600 million orders and up to 580 users.  The workload consists of a number of transaction types including show-expenses, part-cost, supplier-phone, low-inv, high-inv, update-price, update-phone, update-cost, and new-order.

The real cardinality database (RCDB) schema was created to showcase the potential speedup one may see moving from on disk, row format data warehouse/star schema, to utilizing Oracle Database 12c's In-Memory feature for analytical queries.

The DSS workload consists of, as many as, 2,304 unique queries asking questions such as "In 2014, what was the total revenue of single item orders?" or "In August 2013, how many orders exceeded a total price of $50?" Questions like these can help a company see where to focus for further revenue growth or identify weaknesses in their offerings.

RCDB scale factor 1050 represents a 1.05 TB data warehouse. It is transformed into a star schema of 1.0 TB, and then becomes 110 GB in size when loaded in memory. It consists of 1 fact table, and 4 dimension tables with over 10.5 billion rows. There are 56 columns with most cardinalities varying between 5 and 2,000, a primary key being an example of something outside this range.

The results were obtained running a set of OLTP transactions and analytic queries simultaneously against two schema: a real time online orders system and a related historical orders schema configured as a real cardinality database (RCDB) star schema. The in-memory analytics RCDB queries are executed using the Oracle Database 12c In-Memory columnar feature.

Two reports are generated: one for the OLTP-Perf workload and one for the RCDB DSS workload. For the analytical DSS workload, queries per minute and average query elapsed times are reported. For the OLTP-Perf workload, both transactions-per-second in thousands and OLTP average response times in milliseconds are reported.

Key Points and Best Practices

  • This benchmark utilized the SPARC S7 processor's co-processor DAX for query acceleration.
  • All SPARC S7-2 server results were run with out-of-the-box tuning for Oracle Solaris.

  • All Oracle Server X5-2L system results were run with out-of-the-box tunings for Oracle Linux except for the setting in /etc/sysctl.conf to get large pages for the Oracle Database:

    • vm.nr_hugepages=98304
  • To create an in memory area, the following was added to the init.ora:

    • inmemory_size = 120g
  • An example of how to set a table to be in memory is below:

    • ALTER TABLE CUSTOMER INMEMORY MEMCOMPRESS FOR QUERY HIGH

     

See Also

Disclosure Statement

Copyright 2016, Oracle and/or its affiliates. All rights reserved. Oracle and Java are registered trademarks of Oracle and/or its affiliates. Other names may be trademarks of their respective owners. Results as of June 29, 2016.

The previous information is intended to outline our general product direction. It is intended for information purposes only, and may not be incorporated into any contract. It is not a commitment to deliver any material, code, or functionality, and should not be relied upon in making purchasing decisions. The development, release, and timing of any features or functionality described for Oracle's products remains at the sole discretion of Oracle.

Be the first to comment

Comments ( 0 )
Please enter your name.Please provide a valid email address.Please enter a comment.CAPTCHA challenge response provided was incorrect. Please try again.Captcha