Showing posts with label HyperThreading. Show all posts
Showing posts with label HyperThreading. Show all posts

Saturday, September 19, 2020

// // Leave a Comment

EPM 11.2 servers and HyperThreading

A few days ago, we had a discussion with our server build team for acquiring new hardware for EPM 11.2 installation & configuration. To put it in context, one of our clients has EPM 11.1.2.4 on-premise setup consisting of multiple Hyperion instances running across IBM AIX 7.1 (Oracle Database), RedHat Linux 6.10 x86_64 (Essbase app), and Windows Server 2012 R2 64-bit (all other apps like HFM, FDMEE, DRM, HPCM, etc.) in a distributed environment.

Recently, the client wished to move the complete setup to the latest EPM 11.2.x release having Windows Servers 2019 and Linux 7 (why EPM 11.2 and not EPM Cloud for this setup? Well its a matter we will discuss some other time.)

In the current 11.1.2.4 setup, we have both kinds of servers -Physical Servers + VM Servers. To be precise, only HFM and Essbase apps are hosted on Physical machines in both PROD and TEST environments rest all are on VM servers.

All Physical servers (HFM + Essbase App servers) have HyperThreading** ENABLED while there is no HyperThreading on VM machines. 

**HyperThreading: HyperThreading is Intel’s term for simultaneous multithreading (SMT). This is a process where a CPU splits each of its physical cores into virtual cores, which are known as threads. For example, most of Intel's CPUs with two cores use hyper-threading to provide four threads, and Intel CPUs with four cores use hyper-threading to provide eight threads. Therefore, when HyperThreading is enabled, every CPU core has two CPU threads instead of one. A server with 8 cores would appear to have 16 CPU threads. If one thread is idle or stalls on a cache miss, the other thread can continue to execute. This is a potential throughput advantage, especially for multithreaded workloads that frequently have cache misses. HyperThreading (HT) permits the CPU to continue useful processing by running the other thread. On the other hand, both threads compete for the core’s resources, and each thread may run slower than if it owned an entire core. Each thread potentially displaces the other thread’s level 1 cache contents, causing both threads to run slower. This is especially visible for compute-intensive workloads that might normally fit in the cache without HT. The result is that it's reasonable to enable HyperThreading by default, but it can be valuable to test performance to see whether it adds performance for a specific application or not.

The current EPM 11.1.2.4 setup is working perfectly fine for past many years having an optimum performance for all the apps.

Now, while we have decided to upgrade it to EPM 11.2, it was quite apparent for us to get the answers of the following queries:

  • Is there any recommendation for HyperThreading in EPM 11.2 version (Windows server 2019, Linux 7)?
  • Can we continue with having the existing 11.1.2.4 HyperThreading CPU configuration even in EPM 11.2?
  • Is there any known issue or performance improvement if we continue to run Essbase and HFM on HyperThreading enabled servers even in EPM 11.2?

Let's try to find out.......

Oracle and HyperThreading:

Oracle will work just fine on any OS that is running and recognizes a HyperThreading enabled system and will take advantage of the logical CPUs to their fullest extent (assuming the OS reports that it recognizes that hyper-threading is enabled). All Oracle versions can take advantage of hyper-threading and is considered a supported configuration since no support code has been added for it on the Oracle end to take advantage of HyperThreading; all the changes were in the OS, the bios, and the hardware. When Oracle asks the OS how many CPUs are in the system, the OS just reports the total number of logical CPUs.

Oracle Hyperion and HyperThreading:

I googled and read some blogs and what I found is that the experience of Oracle EPM apps with HyperThreading is quite mixed. For some, it worked well while others didn’t. I will leave it up to you to google and read those observations.

I remember there used to be a line in the Essbase 11.1.2.1 dbag document -"Enabling hyperthreading on the computer on which Essbase Server runs is not recommended." But now this line is no more there in Essbase dbag Release 11.1.2.4, implying the statement is no more valid.

My current EPM 11.1.2.4 configuration was done much before I joined this project so not sure about the exact reason to have HyperThreading enabled physical servers for Essbase and HFM apps and not for other apps which were installed on VM machines (please let me know if you know any technical correlation). But I am sure there must have been some idea behind opting the current 11.1.2.4 servers' CPU configuration (on Windows Server 2012 R2 and Linux 6).

However seeing the good performance of the current 11.1.2.4 PROD environment (Essbase, HFM, FDMEE, DRM, and HPCM) over the past many years and in the absence of any conclusive stats about HyperThreading impact in EPM servers, I was tempted to take the current PROD 11.1.2.4 HyperThreading setup as a reference for the EPM 11.2 hardware configuration too.

But, notably, EPM 11.2 version will be running on Windows servers 2019 compared to currently used Windows servers 2012 R2, so I thought better to consult Oracle to make a final recommendation on HyperThreading for EPM 11.2 Servers' CPU configuration.

And below is what Oracle said:

There are no specific Recommendations on HyperThreading for EPM 11.2 version (Windows server 2019) and we didn't see any issues reported by other customers as well. However, you can enable HyperThreading in your 11.2 setup and let us know if you face any issues post the implementation.

So it’s clear that there is no clear-cut YES/NO from the Oracle side as far as Enabling/Disabling HyperThreading in EPM 11.2 servers are concerned. Oracle leaves it to the discretion of your Hyperion technical team and Servers build team to decide whether you want to have servers built with HyperThreading enabled or disabled. Of course, it will vary with different Hyperion environments, OS, applications and most importantly it should be guided by the time-tested performance of your Hyperion applications for example in terms of HFM consolidation, Essbase calculation, aggregation, data load, and report script run, FDMEE data load run time, etc.

But yes! Oracle will come to your rescue if you face any issues post EPM 11.2 implementation (irrespective of what you chose for your CPU configuration).

And for those who are interested to know how we have decided to go for HyperThreading in EPM 11.2 servers. Well, it’s still under discussion (as of Sep 2020)....(but its almost certain that our EPM 11.2 servers will be having the same Hardware configuration what we have in our existing 11.1.2.4 setup being a time-tested reference for our current set of Essbase, HFM, HPCM, FDMEE, DRM, etc. applications).

Do leave a comment to let me know how you have built your EPM 11.2 servers (with/without HyperThreading).

That's all for this post.

I hope this article has helped you. 
Your suggestions/feedback are most welcome.
Keep learning and Have a great day!!!
Read More