Skip to main content

Run SAP HANA in Shared Processor Pool LPARs

IBMer Olaf Rutz explains how shared processor pools and SAP HANA are compatible.

Ask the Expert in white on a green background

Q: Can SAP HANA run in Shared Processor Pool LPARs?

SAP HANA is an in-memory database highly optimized for performance. HANA achieves this performance through many implementation details like advanced compression capabilities, strong focus on a columnar design, massive internal parallelization and effective use of the knowledge of the underlying hardware architecture. 

In this sense, HANA optimizes data structures internally, for example, according to cache line sizes. It also manages data placement and work scheduling according to the underlying NUMA architecture of the system. Therefore, HANA requires detailed information about the association of CPU and memory to specific NUMA nodes (in most cases identical to a socket) to achieve best performance.

On the other side, shared processor pools in PowerVM* are intended to abstract physical CPUs from the Virtual Processors PowerVM sees as CPUs in a guest LPAR. The goal is to achieve best system utilization by scheduling the physical CPU resources to all guest LPARs in the system according to the application needs, including the possibility of CPU overcommitment. From this perspective, PowerVM is hiding relevant system details with respect to CPUs from the guest LPARs.

Based on these descriptions, one could assume SAP HANA and shared processor pools are incompatible software technologies.

A Closer Look at Shared Processor Pools

Shared processor pools define virtual CPUs as the entity where the hypervisor can schedule a physical processor. Entitlement is a setting that defines how many cycles of a physical CPU are guaranteed to be made available to a virtual processor by the hypervisor. For example, an entitlement of 0.5 guarantees that a virtual CPU is getting scheduled to a physical CPU at least 50% within a given time window. As long as not all CPUs in the shared pool are used, the virtual processor may even get 100% of a given time window scheduled to a physical CPU.

The total amount of configured entitlements can never exceed the physical CPUs available in a system. This allows the hypervisor to assign physical CPUs to the virtual processors for the configured entitlement always on the same NUMA nodes. Those NUMA nodes are also known as the home nodes of a Virtual CPU. For assignments of physical CPUs above the entitlement, the hypervisor tries to schedule to the home nodes as well, but this can’t be guaranteed.

Newer versions of Linux* are reporting the home nodes of virtual CPUs in Shared Processor Pools and HANA is able to use this information for its internal performance optimization. A user can check with the command “numactl –hardware” the NUMA topology based on the home nodes. If all CPUs are listed only on NUMA node 0 whereas multiple NUMA nodes are available, it’s likely to have an older Linux kernel running, which shouldn’t be used for SAP HANA in a shared processor pool.

If a client is running shared processor pools with a proper sizing of the entitlement for SAP HANA, the database can make use of the internal NUMA optimizations. In most cases, performance is at least identical to a comparable setup with dedicated CPUs. Performance could be even better if more virtual CPUs are configured than in the dedicated case and overall system utilization isn’t too high (see Figure 1, below). Throughput performance in the shared pool with SAP HANA matches the performance expectation (red line) based on the entitlement—and often exceeds it. 

The definition of more virtual CPUs in the shared LPAR compared to the dedicated LPAR allows it to make use of unused capacity in the shared pool for improved performance.

A proper sizing of the entitlement should ensure that the average workload of the client system is sufficiently covered. When estimating the average workload, make sure that the monitoring tool used is reporting the CPU utilization on a granular level (the default setting of nmon isn’t sufficient). This is necessary because the SAP HANA workload can be very spikey. In order to achieve best performance, queries can be highly parallelized to execute in a short period of time. If the monitoring interval isn’t granular enough, the entitlement might be set too low. If overall system utilization is too high, some queries might be negatively impacted.

Proper Configuration Is Key

With a proper configuration of the entitlement, SAP HANA can run in shared processor pools while HANA can make use of its internal optimizations for NUMA. If correctly configured, HANA will run with performance behavior very similar to that of a dedicated environment. At the same time, the client can make better use of overall system resources through sharing. 

The client also has the option to run test systems, for example, with lower entitlement accepting some performance hits but at the same time using those CPU resources for production systems in high load phases. With shared processor pools, a client has a rich and fine granular tool set in hand to optimize SAP HANA performance and system utilization to exactly his needs and by that, make the best use of available resources.

More Information

SAP Note 2055470: bit.ly/36LF8ne

POWER processor-specific HANA documentation

Keep in mind that additional scenarios are added over time in the support statement and this documentation will be updated accordingly.

IBM Systems Webinar Icon

View upcoming and on-demand (IBM Z, IBM i, AIX, Power Systems) webinars.
Register now →