Analyzing Oracle SPARC T7-2 Server Performance
One of the most important Oracle news in 2015 was the release of the new SPARC M7 processor and a line of servers based on it. This line includes T-series servers (T7-1, T7-2, T7-4) and M-series servers (M7-8, M7-16).
In addition to the unique physical characteristics (frequency 4.13 GHz, 32 cores, up to 256 threads), the M7 processor claims the possibility of transferring part of the SQL logic of the Oracle database to special DAX (Data Analytics Accelerator) coprocessors. This technology is called “SQL in Silicon” - with it the new M7 processor is positioned as the first processor in the history of IT, including optimized for Oracle Database tasks.
At the beginning of 2016, it became possible to test T-series servers, and we were one of the first in Russia to simultaneously test two T7-2 test servers at once (two M7 processors each).
Testing was organized in several stages:
The purpose of this post is to share with the community the results obtained in the first and third stages.
There is a wide range of synthetic tests on the market using Oracle Database. Moreover, no matter how ironic it sounds, the choice of synthetics can largely determine the result. As in testing the previous generation SPARC (servers of the T5 line), we set out to find out what maximum performance can be squeezed out of the server - to determine the moment when it “boils” under the load of Oracle Database.
For such an investigation, classical SwingBench-type GUI synthetics are not suitable - the test software must have open source code in order to minimize the impact on the test results of both the input-output system and the internal database mechanisms (in this case, Oracle Database). In the course of solving this problem, we have selected and significantly improved open source software SLOB (Silly Little Oracle Benchmark, author Kevin Closson). In the process of research, we fixed the maximum values of the Logical Reads Per Second indicator (logical reading or reading from memory) of an Oracle instance with a fully heated cache and parallel work of SLOB sessions with almost no competition for instance resources. The intensity of logical readings from memory is an important feature of the new processor,
Fig. 1. Results in 32 core domains (T5 vs T7)
The figure shows the comparative results obtained on the servers T5-4 (previous generation of SPARC processors) and T7-2 (new SPARC M7 processors). The results are recorded in the same processor power domains (32 cores) with the same versions of Oracle Database and instance settings. The x-axis represents the number of parallel sessions of the modified SLOB, the y-axis represents the maximum number of logical reads per second according to AWR statistics.
It can be seen from the graph that saturation (when the server “boils”) occurs when the number of SLOB sessions is compared with the number of domain threads (32 cores of eight threads - 256). It is also seen that with the same number of cores, the T7 server domain turned out to be 1.15–1.2 times more productive than the T5 server domain. This means that the new M7 processor (which has twice as many cores) is 2.3–2.4 times more productive than the previous generation processors from Oracle. Note that this result is recorded on the T7 server both in the control (control) and in the guest (guest) domain. At the same time, on a large number of sessions (192 or more) in the guest domain of the T7 server, the influence of virtualization is noticeable: the performance is 3-5% lower than in the control domain under the same conditions.
The maximum value of the Logical Reads Per Second indicator under the SLOB load was recorded on 512 threads - when all 64 cores were given to the control domain. This value amounted to 93–95 million logical reads per second - for the entire time testing servers of various architectures under Oracle Database load, we got such numbers for the first time!
Fig. 2. Comparative results in the domains of 16 cores (T5 / T7 / P8 / x86)
In parallel with testing the T7-2 server using the same technique, the current IBM Power and x86 architecture servers were tested. The figure shows the comparative SLOB test results obtained in domains with the same number of cores (16). At the same time, we note that an x86 server has 2 threads per core, while Power and SPARC each have 8 threads. In a large number of SLOB sessions, the result of the T7-2 server (about 24 million logical reads per second) turned out to be the best - despite the fact that in small numbers of sessions, the x86 architecture proved to be the most productive.
The results of synthetic SLOB tests allow us to conclude that even without the special SQL in Silicon features, the T7-2 server shows very high performance on Oracle Database tasks and can be safely recommended, at least as an Oracle Database consolidation platform. These are the brief results of the first stage of our study of the M7 processor.
As for DAX (or “SQL in Silicon”), you can explore it in various ways. Firstly, the DAX API is open and can be directly used in the application. Such an approach is described in our article Hardware acceleration of corporate computing - with the help of DAX it was possible to speed up operations with mathematical sets 5-6 times.
Secondly, you can test how the SQL in Silicon technology speeds up database queries. Today, this is only possible with Oracle Database 12c and only with the In-Memory option. Therefore, it will be correct to recall what this option is.
Most Database use Row Database storage both on disks and in memory. At the same time, there are and are actively developing Database on the market that implement Columnar Database. It is generally accepted that the Row Database is optimal for transactional systems of the OLTP class, and in DWH class repositories, certain analytical queries can work much faster with the Columnar Database.
The Database In-Memory option introduced in Oracle Database 12c implements column data storage in memory in addition to the traditional string. Such storage is possible due to an additional memory area (In-Memory cache), in which the Oracle Database administrator can cache data of entire tables, as well as individual columns or partitions in column format. Such an additional column storage of data in memory is transparent to the application, while the Oracle optimizer has the opportunity to select the necessary data from memory in both the row and column representations. We can say that using In-Memory, Oracle implements a unique combination of row and column data storage.
We repeatedly acquainted the community with the results obtained in our tests of In-Memory, in particular, we developed a technique that emulates the operation of DWH class systems. Randomly-generated data on Europeans and their salaries (persons table, about 20 million records) were piled into an Oracle database table, all European countries were piled into a separate reference table (countries table):
The role of the analytical query was played by the SQL calculation of the sum of all the salaries of residents of countries starting with R (these are Russia and Romania):
When working with In-Memory in the In-Memory cache, two columns of the persons table “country_id” and “salary” “rose”:
When using the traditional buffer cache (after warming up), this request was processed on the T7-2 server in 1.9 seconds (note that the In-Memory mechanism was disabled by the hint). When using the In-Memory cache on the same server - in 0.39 seconds or 4.8 times faster. Monitoring DAX by the busstat utility showed that during the execution of the request the counters were not zero - i.e. DAX worked:
Thus, this analytical query was partially executed on DAX coprocessors and we recorded an almost 5-fold acceleration of its operation due to the integrated In-Memory + DAX technology compared to the operation of Oracle Database using the traditional buffer cache. Note that we did not specifically select the query or the size of the persons table - we implemented a technique on T7-2, with which we studied the operation of the In-Memory option earlier. Fivefold acceleration in this case is more than a worthy result, all the more so since it is in good agreement with the conclusions we made earlier when testing DAX through the API (see Hardware acceleration of enterprise computing ).
Upd. Colleagues, at placement mixed up places of the image, the error is eliminated.
In addition to the unique physical characteristics (frequency 4.13 GHz, 32 cores, up to 256 threads), the M7 processor claims the possibility of transferring part of the SQL logic of the Oracle database to special DAX (Data Analytics Accelerator) coprocessors. This technology is called “SQL in Silicon” - with it the new M7 processor is positioned as the first processor in the history of IT, including optimized for Oracle Database tasks.
At the beginning of 2016, it became possible to test T-series servers, and we were one of the first in Russia to simultaneously test two T7-2 test servers at once (two M7 processors each).
Testing was organized in several stages:
- performance analysis of the new SPARC server using synthetic tests using Oracle Database,
- Exploring new T7-2 server virtualization capabilities (see Virtualization on Oracle SPARC T7-2 - our test results)
- study of technology "SQL in Silicon".
The purpose of this post is to share with the community the results obtained in the first and third stages.
There is a wide range of synthetic tests on the market using Oracle Database. Moreover, no matter how ironic it sounds, the choice of synthetics can largely determine the result. As in testing the previous generation SPARC (servers of the T5 line), we set out to find out what maximum performance can be squeezed out of the server - to determine the moment when it “boils” under the load of Oracle Database.
For such an investigation, classical SwingBench-type GUI synthetics are not suitable - the test software must have open source code in order to minimize the impact on the test results of both the input-output system and the internal database mechanisms (in this case, Oracle Database). In the course of solving this problem, we have selected and significantly improved open source software SLOB (Silly Little Oracle Benchmark, author Kevin Closson). In the process of research, we fixed the maximum values of the Logical Reads Per Second indicator (logical reading or reading from memory) of an Oracle instance with a fully heated cache and parallel work of SLOB sessions with almost no competition for instance resources. The intensity of logical readings from memory is an important feature of the new processor,
Fig. 1. Results in 32 core domains (T5 vs T7)
The figure shows the comparative results obtained on the servers T5-4 (previous generation of SPARC processors) and T7-2 (new SPARC M7 processors). The results are recorded in the same processor power domains (32 cores) with the same versions of Oracle Database and instance settings. The x-axis represents the number of parallel sessions of the modified SLOB, the y-axis represents the maximum number of logical reads per second according to AWR statistics.
It can be seen from the graph that saturation (when the server “boils”) occurs when the number of SLOB sessions is compared with the number of domain threads (32 cores of eight threads - 256). It is also seen that with the same number of cores, the T7 server domain turned out to be 1.15–1.2 times more productive than the T5 server domain. This means that the new M7 processor (which has twice as many cores) is 2.3–2.4 times more productive than the previous generation processors from Oracle. Note that this result is recorded on the T7 server both in the control (control) and in the guest (guest) domain. At the same time, on a large number of sessions (192 or more) in the guest domain of the T7 server, the influence of virtualization is noticeable: the performance is 3-5% lower than in the control domain under the same conditions.
The maximum value of the Logical Reads Per Second indicator under the SLOB load was recorded on 512 threads - when all 64 cores were given to the control domain. This value amounted to 93–95 million logical reads per second - for the entire time testing servers of various architectures under Oracle Database load, we got such numbers for the first time!
Fig. 2. Comparative results in the domains of 16 cores (T5 / T7 / P8 / x86)
In parallel with testing the T7-2 server using the same technique, the current IBM Power and x86 architecture servers were tested. The figure shows the comparative SLOB test results obtained in domains with the same number of cores (16). At the same time, we note that an x86 server has 2 threads per core, while Power and SPARC each have 8 threads. In a large number of SLOB sessions, the result of the T7-2 server (about 24 million logical reads per second) turned out to be the best - despite the fact that in small numbers of sessions, the x86 architecture proved to be the most productive.
The results of synthetic SLOB tests allow us to conclude that even without the special SQL in Silicon features, the T7-2 server shows very high performance on Oracle Database tasks and can be safely recommended, at least as an Oracle Database consolidation platform. These are the brief results of the first stage of our study of the M7 processor.
As for DAX (or “SQL in Silicon”), you can explore it in various ways. Firstly, the DAX API is open and can be directly used in the application. Such an approach is described in our article Hardware acceleration of corporate computing - with the help of DAX it was possible to speed up operations with mathematical sets 5-6 times.
Secondly, you can test how the SQL in Silicon technology speeds up database queries. Today, this is only possible with Oracle Database 12c and only with the In-Memory option. Therefore, it will be correct to recall what this option is.
Most Database use Row Database storage both on disks and in memory. At the same time, there are and are actively developing Database on the market that implement Columnar Database. It is generally accepted that the Row Database is optimal for transactional systems of the OLTP class, and in DWH class repositories, certain analytical queries can work much faster with the Columnar Database.
The Database In-Memory option introduced in Oracle Database 12c implements column data storage in memory in addition to the traditional string. Such storage is possible due to an additional memory area (In-Memory cache), in which the Oracle Database administrator can cache data of entire tables, as well as individual columns or partitions in column format. Such an additional column storage of data in memory is transparent to the application, while the Oracle optimizer has the opportunity to select the necessary data from memory in both the row and column representations. We can say that using In-Memory, Oracle implements a unique combination of row and column data storage.
We repeatedly acquainted the community with the results obtained in our tests of In-Memory, in particular, we developed a technique that emulates the operation of DWH class systems. Randomly-generated data on Europeans and their salaries (persons table, about 20 million records) were piled into an Oracle database table, all European countries were piled into a separate reference table (countries table):
create table persons (
id not null number(38),
country_id number(38),
name varchar2(50),
salary number(36)
);
create table countries (
id not null number(38),
name varchar2(20)
);
The role of the analytical query was played by the SQL calculation of the sum of all the salaries of residents of countries starting with R (these are Russia and Romania):
select sum(salary) from persons where country_id in (select id from countries where name like 'R%');When working with In-Memory in the In-Memory cache, two columns of the persons table “country_id” and “salary” “rose”:
alter table persons inmemory no inmemory (id, name) inmemory memcompress for query high (country_id, salary);When using the traditional buffer cache (after warming up), this request was processed on the T7-2 server in 1.9 seconds (note that the In-Memory mechanism was disabled by the hint). When using the In-Memory cache on the same server - in 0.39 seconds or 4.8 times faster. Monitoring DAX by the busstat utility showed that during the execution of the request the counters were not zero - i.e. DAX worked:
5 dax0 DAX_SCH_query_cmd_sched 80 DAX_QRYO_input_valid 694586 DAX_QRYO_output_valid 1530256
5 dax1 DAX_SCH_query_cmd_sched 80 DAX_QRYO_input_valid 754450 DAX_QRYO_output_valid 2017088
5 dax2 DAX_SCH_query_cmd_sched 79 DAX_QRYO_input_valid 522635 DAX_QRYO_output_valid 758496
5 dax3 DAX_SCH_query_cmd_sched 79 DAX_QRYO_input_valid 672683 DAX_QRYO_output_valid 1529568
5 dax4 DAX_SCH_query_cmd_sched 79 DAX_QRYO_input_valid 589392 DAX_QRYO_output_valid 1073248
5 dax5 DAX_SCH_query_cmd_sched 79 DAX_QRYO_input_valid 635264 DAX_QRYO_output_valid 1502832
5 dax6 DAX_SCH_query_cmd_sched 79 DAX_QRYO_input_valid 615433 DAX_QRYO_output_valid 1080257
5 dax7 DAX_SCH_query_cmd_sched 80 DAX_QRYO_input_valid 810452 DAX_QRYO_output_valid 2295872
Thus, this analytical query was partially executed on DAX coprocessors and we recorded an almost 5-fold acceleration of its operation due to the integrated In-Memory + DAX technology compared to the operation of Oracle Database using the traditional buffer cache. Note that we did not specifically select the query or the size of the persons table - we implemented a technique on T7-2, with which we studied the operation of the In-Memory option earlier. Fivefold acceleration in this case is more than a worthy result, all the more so since it is in good agreement with the conclusions we made earlier when testing DAX through the API (see Hardware acceleration of enterprise computing ).
Upd. Colleagues, at placement mixed up places of the image, the error is eliminated.
