One Simple Tip for Faster SAP HANA Performance
We at SUSE have discovered how you can be sure you have the fastest results from your SAP HANA systems. From the beginning, SUSE engineers have been hard at work with SAP HANA developers supporting their efforts to deliver real-time results for ERP and BPM applications. We’ve worked with them on tuning and performance optimization packages. We’ve come up with creative solutions to the problem of Linux kernel memory caching that can slow down data retrieval by SAP applications. But now we know the one simple thing that you should do for faster SAP HANA performance:
Choose SUSE Linux Enterprise Server for SAP Applications for SAP HANA
I’ll tell you why, but first a little background.
Over the last couple of years, I’ve been keeping track of the number of SAP HANA benchmarks published by server vendors on SUSE Linux Enterprise Server for SAP Applications as compared to the number on Red Hat’s various SAP platforms (there have been a few). When I first started counting, there were 27 published benchmarks run on SUSE Linux Enterprise Server and 0 on Red Hat Enterprise Linux. At the end of May this year that number had ballooned to 66 – 0. Remember that OS vendors don’t publish SAP HANA benchmark results. It’s up to the server vendors to choose the Linux distribution and hardware configuration to test. I can’t tell you why they’ve always chosen SUSE Linux Enterprise Server. My theory has been that they believed SLES gave them the best chance for a strong benchmark showing against their competitors. If that’s the case, they may be right.
Last week, HPE published a benchmark running the SAP HANA 1.0 database on RHEL 7.2 with the Version 2 benchmark and 1.3 billion records. If you look here, you’ll see that Fujitsu ran exactly the same test with SLES 12 SP2 just a few days earlier. Both servers had the same hardware configuration:
- 4 processors / 112 cores / 224 threads 2.5 GHz Intel Xeon Platinum 8180
- 64 KB L1 cache and 1024 KB L2 cache per core, 38.3 MB L3 cache per processor
- 1536 GB main memory
Here are the results. Pay particular attention to the number of Query Executions per hour, and the Total Runtime numbers.
If you do the math you’ll see that with the same test and hardware configuration, you get 10% better throughput (more queries executed per hour) and 70% shorter runtime with SUSE Linux Enterprise Server.
The primary reason that SAP developed the HANA database was to speed up analytics and transactional data access. Even if you currently run other Linux distributions today, to get the full benefit of SAP HANA you should seriously consider running your ERP systems on SUSE Linux Enterprise Server for SAP Applications.
Learn more about everything SUSE offers for SAP systems, visit the SUSE Linux Enterprise Server for SAP Applications product web page, and our solution page. And to see the great things our engineers have added in the new SUSE Linux Enterprise Server for SAP Applications 15 version, see my recent blog.
Follow me on Twitter at @MichaelDTabron.
Related Articles
Oct 31st, 2023
Confidential Cloud: Introduction to Confidential Computing
Comments
Never mind that I work for SUSE (and in the SAP arena). This is an excellent blog post. Thanks for the write-up, Michael.
My friend Michael I have one comment about the comparison.
It would be more accurate and fair if you do the performance comparison on the same type/brand hardware. Now you are comparing apples with Oranges (Fujitsu versus HPE) .
If in that case you achieve higher performance with SLES, then I will be confident with you.
Hope to see you soon. Your old friend Orhan
Hello Orhan, we will have to agree to disagree on that point. I was careful to compare benchmarks of servers running the same test configuration, with the same Intel processors and memory configurations. I don’t believe there is a significant difference in performance with one brand of server vs. another, but I am open to being proven wrong.
Hi Michael,
Thanks for sharing this simple tip and informative insights… 🙂
SUSE (SLES) tends to be the favored HANA OS. However, a true test would be done on the same hardware, with the same configuration.
Motherboard (chipset) and memory configuration with that chipset, as well as the memory channel configuration has huge impacts. For the queries there are huge implications for the IO being used. Not only that, HANA uses “lazy-loading” for their memory management which can also impact this. So, a test on the same hardware, with the same configuration, does matter.
=============
The SAP HANA database loads column-store tables into memory column by column only upon use. This is sometimes called “lazy loading”. This means that columns that are never used will not be loaded and memory waste is avoided.
=============
The lazy-loading may be impacted heavily by IO in these cases as well.
Thanks for your comment, Bill. You make some interesting points about the I/O and memory configuration beyond the processors.