SAP has announced at Sapphire that they are working towards revolutionizing their enterprise software by taking advantage of their in-memory technology, which will allow fast queries and real-time processing. Instead of waiting hours to compile reports or days to replicate data in business warehouses, business users will get immediate responses on real-time data.

However, one might ask what happens if all data is stored in memory and a memory cell fails. In view of this recent report memory errors might cause downtimes and recovery, which is unacceptable for mission-critical enterprise systems. If a hard memory error occurs, the only option for a server today was to stop operation. The Intel® Xeon® 7500 processor series (code-named Nehalem-EX) offers a wide range of reliability and high-availability features. As Andi Kleen explains in his presentation, how it is now possible that hard memory failures are caught by the operating system and exposed to applications. 

Together with my colleagues Otto and Roman, I am working with SAP to enable SAP’s in-memory database to handle memory failures. In fact, Otto is on his way to San Francisco to show you at the Intel Developer Forum (IDF) 2010 a proof-of-concept that SAP’s in-memory database can handle hard memory failures and continue operation in a lot of cases, a novelty in the industry. (Thanks go to Christoph for his support of the demo GUI).

So, I encourage you to swing by the SSG booth at IDF and let Otto show you how SAP’s in-memory database is handling memory error handling on Intel® Xeon® 7500 processor series.

Kind regards

Thomas

Up until recently, the most important question when buying a new server for enterprise software was what server could provide the required performance. The SAP Sales and Distribution (SD) Benchmark is the de-facto industry standard for measuring the performance of enterprise software on a server and its results are used by SAP in their sizing process. With increasing energy costs, the focus when buying hardware is slowly shifting towards the power requirements in your data center. SAP is supporting this trend and has joined forces with hardware and software partners to develop a “power benchmark”. On behalf of Intel, I was part of this workgroup and lived through the ups and downs of creating a new benchmark that is suited to determine the power efficiency of a server. There is even the vision that the results of the benchmark can, one day, be used to do something like “power sizing”, or at least to provide power estimates that are specific for hard- and software. However, this is a still a long way to go, and the definition of the benchmark is the first, but significant step towards this goal.

As there are already other power benchmarks available, most prominently SPEC power, one might ask, what the purpose of the SAP power benchmark is. What a lot of people don’t realize is the fact that different software performs different on hardware, performance- and power-wise. A fairly obvious example are the memory requirements for a workload--and the amount of memory has a measurable impact on the power consumption. A less obvious difference is the possibility of today’s processors that can turn off functional units like floating-point arithmetic if they are not needed by the software. These are just examples of current hardware. With an increasing number of power-saving features, the differences will become even bigger in future. Even the SPEC power committee didn’t think that they would create the one and only power benchmark. Instead, their goal was to create the framework for other power benchmarks to follow their approach.

It is therefore not surprising that the SAP power benchmark share some characteristics with SPEC power. One similarity are the different load levels. Servers are typically not used 100% all of the time. A certain headroom is needed for peak times and, especially if a server is used only in one geography, is might be mostly idle at night. In order to capture these different load levels, the SAP power benchmark runs through several phases, each using only a certain fraction of the maximal number of users. The power and throughput for this load level is the measured and the average of these ratios is used as the key performance indicator in Watts/kSAPS. Please note that this is different than simply measuring the throughput and power consumption at the average load level only. Similarly, you have a different fuel consumption when you drive 200 km/h for 30 minutes and wait 30 minutes or if you drive 60 minutes at 100 km/h.

The load levels follow a fixed pattern that includes ramping up and down the number of users. This way, power saving features must not only be able to power off certain parts of the server, but also to quickly resume to full operation. Furthermore, no manual interaction is permitted like manually shutting down servers in a three-tier setup during phases of low usage. The detailed description of the load levels and further restrictions can be found in the current draft of the benchmark specification on the SAP website.

What I have described so far covers only the SAP server power benchmark. However, there is also a benchmark in preparation that includes the complete system consisting of server and storage. Ultimately, you need both in order to run SAP software. For this reason, the workgroup is actively working to define such a holistic benchmark. Even though the benchmark itself will be different SAP server power benchmark, the power consumption of server and storage will still be measured separately, if this is technically possible. Nevertheless, the server-only benchmark has its own merits and was therefore implemented as stage 1 on the way to the complete benchmark. So, stay tuned for the first SAP server benchmark results and the full definition of the SAP system power benchmark in 2010.

The user interface is so easy to use that random people like me are able to handle it. (I am an application engineer, not a BI expert.) If you don't believe me, I strongly encourage you to try it out yourself with the public demo from SAP, where you can explore data from microfinance. Even if you have no experience with business intelligence systems, you will find that you can easily answer the questions of the quiz game about micro-financing.

What makes this demo outstanding is the fact that the displayed data is not pre-computed and stored as aggregates, but the data is aggregated on-the-fly. This approach results in great flexibility as the system does not need to know in advance, which sort of questions a user might ask. Technically, this has been realized by keeping all data in memory of a set of blade servers with Intel® Xeon® processors X5570 (code-named Nehalem-EP). The SAP in-memory technology compresses the data and distributes it for parallel processing by multiple cores and blades with a shared-nothing approach. Using the features of modern multi-core processors, this literally enables business intelligence at the speed of thought.

I am very excited that we are now able to show you the software that make this possible running on our next generation 4-socket servers, code-named Nehalem-EX: At the Intel Developer Forum in San Francisco, I will staff a booth featuring this software., which was set up by my dear colleague Roman Dementiev. Given the great scalability of the software, it can take full advantage of the new architecture and I will be happy to show it to you.

CU@IDF

Thomas

The first key note, given by Raghu Ramakrishnan, as well as a very entertaining panel discussion headed by Phil Bernstein addressed the recent trend especially for web-applications to use key-value stores for tasks that are traditionally solved by data bases. People are giving up transaction security, indexes, decent query languages, optimizers and all the other goodies that come with a data base, because of the steep learning curve. However, when the success and importance of an application grows, features like data consistency, availability, and partitioning become important and they are therefore now added to the key-value stores. As the data continues to grow exponentially, the panel concluded that this is actually a huge opportunity for the data base community, if it is addressed properly.

Of particular interest to me was the 10-year Best Paper Award together with the award key note on Database Architecture Optimized for the New Bottleneck: Memory Access. In the last 10 years, there is an increasing awareness in the data base community that the era of disk-related issues is over because, if performance really matters, you can keep the hot data in memory. As a result, you need to take the memory architecture and the CPU into account when trying to get maximum performance. My presentation on “SIMD-Scan: Ultra Fast in-Memory Table Scan using on-Chip Vector Processing Units” was therefore by far not the only one that was dealing with hardware features. There was a very nice presentation “MCC-DB: Minimizing Cache Conflicts in Multi-core Processors for Databases” explaining how you can run effectively process two queries with conflicting cache behaviour by partitioning a shared cache using page colouring. The effective usage of the processor cache was also the subject of “Sort vs. Hash Revisited: Fast Join Implementation on Modern Multi-Core CPUs”, re-evaluating and improving on the current cache-effective join implementations including a projection about their future behaviour. The presentation “Thread Cooperation in Multicore Architectures for frequency Counting over Multiple Data Streams” examined how thread contention can be avoided by deferring the work to be done to the thread that holds a blocking lock. “A Scalable, Predictable Join Operator for Highly Concurrent Data Warehouses” as well as “Predictable Performance for Unpredictable Workloads” both examined how the memory bandwidth can be reduced by combining the processing into a single scan for joins and queries, respectively. Last but not least there was a 3h tutorial on column-stores that leverage the system architecture by processing data column-wise instead of row-wise. The orientation by column implies that cache lines are fully utilized and is much more SIMD-friendly. Furthermore, column-stores allow for better and faster compression, which therefore become an effective mean to decrease bandwidth between memory and cache, and not only between disk and memory like it has been the case in the past.