HANA News Blog
Performance issues with THP on multi-NUMA node systems
THP issues with kernels before February 2026
We have multiple customers running systems on hardware with multiple sockets (4+) and with SLES as OS. With the latest change of SAP HANA 2.0 SPS08 to support THP this can cause some trouble with the usage of SLES 15 SP5 and higher.
The SUSE SUSE KBA 22286 describes this problem in detail.
Who is affected?
- Customers running HANA 2.0 SPS08
- Customer running hardware with more or equal than 4 sockets
- SLES 15 SP5 / SLES for SAP 15 SP5 < kernel-default-5.14.21-150500.55.136.1 (Feb-12-2026: kernel-default-5.14.21-150500.55.136.default)
- SLES 15 SP5 / SLES for SAP 15 SP6 < kernel-default-6.4.0-150600.23.87.1 (Feb-12-2026: kernel-default-6.4.0-150600.23.87.default)
- SLES 15 SP5 / SLES for SAP 15 SP7 < kernel-default-6.4.0-150700.53.31.1 (Feb-11-2026: kernel-default-6.4.0-150700.53.31.default)
- Customer running a lower version of saptune 3.2.2
Customers which are regularly patching there systems are fine. The new kernel versions released in February 2026 are including the fix. But please keep in mind even if you are patching you systems and still running saptune 3.2.2 you have to manually revert the workaround. This version of saptune is just implementing the workaround independent of the used kernel version. Beginning with saptune 3.2.3 (not yet released, status of 30-03-2026) it will include an automatic check.
After installing the fixed kernel and rebooting, defrag should remain ON (madvise) as per the SAP-recommended settings in SAP Note 2131662:
/sys/kernel/mm/transparent_hugepage/defrag => madvise
/sys/kernel/mm/transparent_hugepage/enabled => madvise
/sys/kernel/mm/transparent_hugepage/khugepaged/defrag => 1
How you can check if you are affected? You observe performance issues, memory imbalance and with it memory pressure for selective nodes. As result THP allocations can trigger unexpected direct reclaim and compaction/memory defragmentation, even though other NUMA nodes may have plenty of free memory.
# cat /sys/devices/system/node/node*/meminfo | grep MemFree
This imbalance where one node is low on memory while others have plenty of free memory is what triggers the problematic direct reclaim behavior.
This issue became prominent starting with SLES 15 SP5 and HANA 2 SPS08, when SAP Note 2131662 changed the recommendation to enable THP with "madvise". Prior to SLES 15 SP5, SAP HANA systems had THP disabled entirely. If your system shows [never] for THP, no action is needed:
Temporary workaround for systems not yet updated to the fixed kernel:
If the system cannot be updated to the fixed kernel yet and the symptoms described above are observed, disable THP defragmentation while preserving opportunistic THP usage. This can be done manually or via saptune.
Manual (applied live, no reboot, no HA cluster or HANA restart required):
# echo "never" > /sys/kernel/mm/transparent_hugepage/defrag
# echo 0 > /sys/kernel/mm/transparent_hugepage/khugepaged/defrag
Saptune 3.2.2+ ships Note HotFix000022286 as part of the Solutions HANA, NETWEAVER+HANA, S4HANA-APP+DB and S4HANA-DBSERVER. To apply:
# saptune note apply HotFix000022286
# saptune verify applied
Why NUMA node 0 is often affected first:
NUMA node 0 often experiences a disproportionate impact because PCI devices, such as those for LAN or DISK, are frequently configured to point to it, and user-space applications often default their installation to this same node. Consequently, all requests for LAN or DISK from other NUMA nodes will be routed through NUMA node 0 if that's where the necessary drivers are configured.
To review your driver configuration:
Kernel versions
Sources:
SUSE KBA 22286: SAP HANA swap and system hangs with THP on multi-NUMA node systems
saptune 3.2.2: Github
SAP Note 2131662 - Transparent Huge Pages (THP) on SAP HANA Servers
SAP Note 2578899 - SUSE Linux Enterprise Server 15: Installation Note
SAP Note 2684254 - SAP HANA DB: Recommended OS settings for SLES 15 / SLES for SAP Applications 15
SAP HANA News by XLC
