HANA News Blog

HANA systems: Linux swappiness

Jens Gleichmann • März 24, 2024

Page Priority

################################

German version (scroll down for English)

################################

Seit SLES15 SP4 und RHEL8 (auch bei anderen Linux Distributionen) hat sich das Verhalten beim Reclaim geändert (Details)

Vorher: vm.swappiness Default 60 [Range: 0 - 100]

Nachher: vm.swappiness Default 60 [Range: 0 - 200]


2 Arten von Pages:

  • anonymous page: dynamische Laufzeitdaten wie stack und heap
  • FS (Filesystem) page: Payload wie Applikationsdaten, shared libs etc.


Mit einem Wert von 100 wären damit anonymous pages und FS pages gleichgewichtet. Mit 0 - wie bisher auch - wird das swap Verhalten deaktiviert. Je höher also der Wert gesetzt wird, desto höher gewichtet man die anonymous pages. Es wird immer "kalte" Pages geben, welche einmalig in den Speicher geladen wurden und bei denen es Sinn macht sie früher auszulagern bevor der Speicher tatsächlich mal knapp wird.


Details

Früher (vor SLES11 SP3) wurden die anonymous pages nicht in das Verhalten miteinbezogen. Seit dem hatten man eine 1:1 Gewichtung der Kosten (file-cached pages : anonymous pages) eingeführt. Es wurde immer davon ausgegangen die file pages häufiger zu scannen und auszulagern als die anonymous pages, da es als recht teuer und damit als störend empfunden wurde. Es wurde also über Zeit erkannt, dass es in manchen Situationen doch Sinn macht dieses Verhalten zu ändern, daher hat man den Mechanismus granularer gestaltet.


Summary

Am Ende des Tages, wer hätte das gedacht, ist der neue Algorithmus effektiver und sinnvoller, sorgt aber dafür dass es zu höherem Paging Verhalten führt. Das macht aber nichts, da die Pages die ausgelagert werden tatsächlich mehr als "kalt" sind. Es muss sich also keiner Sorgen machen der bei gleichem Workload und Sizing nun erhöhtes Swapaufkommen bemerkt. Dazu gibt es auch neue metriken in vmstat mit denen sich das Verhalten monitoren lässt.


Empfehlung

Wenn es also viel I/O im System anliegt und der Anteil von FS pages gering ist, kann eine Erhöhung des vm.swappiness Parameters die Performance positiv beeinflussen. Daher empfehle ich den Parameter bei SLES15 SP4+ _nicht_ auf 0 oder 1 zu setzen. Tests haben gezeigt, dass sich mit dem Wert von 10 am besten mit HANA und dem damit verbunden Workload arbeiten lässt, allerdings kann auch ein höherer Wert dienlich sein (10 - 45 aus meinen Tests), da es darauf ankommt welche Third-Party Tools auf dem System zusätzlich laufen (AV, backup, monitoring etc.). Dies kann nur mit Tests und längeren Analysen beantwortet werden.


Fazit

Bleibt aber die Frage nach dem richtigen Monitoring offen. Früher hat man alarmiert sobald swap space genutzt wurde, da man davon aus ging, dass ein Speicherengpass vorliegt. Diese Frage muss sich nun jeder selbst stellen und für sich beantworten. Welche Metriken wurden dafür benutzt? Ab welchen Schwellwert alarmiere ich anhand der neuen Metriken? Kann mein Monitoring Tool diese neuen Metriken auslesen? Muss ich mir eine custom Lösung bauen? All das ist abhängig von der aktuellen Monitoringlösung.





################################

English version

################################

Since SLES15 SP4 and RHEL8(also in other Linux distributions) the behavior of reclaim has changed (details)

Before: vm.swappiness Default 60 [Range: 0 - 100]

After: vm.swappiness Default 60 [Range: 0 - 200]


2 types of pages:

  • anonymous page: dynamic runtime data such as stack and heap
  • FS (Filesystem) page: Payload such as application data, shared libs etc.



With a value of 100, anonymous pages and FS pages would be weighted equally. With 0 - as before - the swap behavior is deactivated. The higher the value is set, the higher the anonymous pages are weighted. There will always be "cold" pages that have been loaded into memory once and for which it makes sense to swap them out earlier before the memory actually runs out.


Details


Previously (before SLES11 SP3) anonymous pages were not included in the behavior. Since then, a 1:1 cost weighting (file-cached pages: anonymous pages) has been introduced. It was always assumed that the file pages would be scanned and outsourced more frequently than the anonymous pages, as it was perceived as quite expensive and therefore annoying. Over time it was recognized that in some situations it makes sense to change this behavior, so the mechanism was made more granular.


Summary


At the end of the day, who would have thought, the new algorithm is more effective and sensible, but ensures that it leads to higher paging behavior. But that doesn't matter because the pages that are being swapped out are actually more than "cold". So no one has to worry about noticing increased swap volumes with the same workload and sizing. There are also new metrics in vmstat that can be used to monitor behavior.


Recommendation


So if there is a lot of I/O in the system and the proportion of FS pages is low, increasing the vm.swappiness parameter can have a positive effect on performance. I therefore recommend not setting the parameter to 0 or 1 for SLES15 SP4+. Tests have shown that a value of 10 is best for working with HANA and the associated workload, although a higher value can also be useful (10 - 45 from my tests), as it depends on which third-party tools are used also run on the system (AV, backup, monitoring, etc.). This can only be answered with tests and longer analyses.


Conclusion


However, the question of the correct monitoring remains open. In the past, an alarm was raised as soon as swap space was used because it was assumed that there was a memory bottleneck. Everyone has to ask themselves this question and answer it for themselves. What metrics were used for this? At what threshold do I alert based on the new metrics? Can my monitoring tool read these new metrics? Do I have to build a custom solution? All of this depends on the current monitoring solution.


SAP HANA News by XLC

Performance degradation after upgrade to SPS07

Ongoing HEX performance issues with SPS07

von Jens Gleichmann • 05 Nov., 2024
With SPS06 and even stronger in SPS07 the HEX engine was pushed to be used more often. This results on the one hand side in easy scenario to perfect results with lower memory and CPU consumption ending up in faster response times. But in scenarios with FAE (for all entries) together with FDA (fast data access), it can result in bad performance. After some customers upgraded their first systems to SPS07 I recommended to wait for Rev. 73/74. But some started early with Rev. 71/72 and we had to troubleshoot many statement. If you have similar performance issues after the upgrade to SPS07 feel free to contact us! Our current recommendation is to use Rev. 74 with some workarounds. The performance degradation is extreme in systems like EWM and BW with high analytical workload.
HANA OS maintenance

HANA OS maintenance

von Jens Gleichmann • 29 Okt., 2024
Please notice that when you want to run HANA 2.0 SPS07, you need defined OS levels. As you can see RHEL7 and SLES12 are not certified for SPS07. The SPS07 release of HANA is the basis for the S/4HANA release 2023 which is my recommended go-to release for the next years. Keep in mind that you have to go to SPS07 when you are running SPS06 because it will run out of maintenance end of 2023.
HANA Roadmap

End of maintenance for HANA 2.0 SPS05 in 2025

von Jens Gleichmann • 24 Okt., 2024
End of maintenance for HANA 2.0 SPS05 in 2025 - plan your upgrade path
News for the hyperscaler AWS, GCP and MS Azure

SAP HANA Hyperscaler news 09/2024

von Jens Gleichmann • 20 Sept., 2024
news instances with SAPS, memory and CPU values in comparison
Unforeseen cloud cost increases

Beware of cloud costs

von Jens Gleichmann • 13 Sept., 2024
Unforeseen cloud cost increases - RedHat announced back in January this year that the costs for cloud partners will be changed effective April 1, 2024. They called it scalable pricing.
HANA 2.0 SPS08 Roadmap

SAP HANA 2.0 SPS08 Roadmap

von Jens Gleichmann • 13 Sept., 2024
SAP HANA 2.0 SPS08 Roadmap Q4 2024
SUSE maintenance

SUSE - Lifecycle

von Jens Gleichmann • 16 Aug., 2024
How to interpret the SUSE Lifecycle
RISE with SAP: Roles & Responsibilities

RISE with SAP: Roles & Responsibilities

von Jens Gleichmann • 24 Mai, 2024
For every possible RISE with SAP customer it is essential to know the difference of the status quo system construct (on-prem self managed / hosted or managed by a MSP) and the RISE offering with a lot of excluded tasks or tasks with additional costs. If you don't need this tasks, it might be a perfect solution, but our experience is that most customers need some of the services with extra costs.
vm.swappiness settings

HANA systems: Linux swappiness

von Jens Gleichmann • 24 März, 2024
The details of swapping in the context of SAP HANA
SUM tooling with target HANA

SUM tooling with target HANA

von Jens Gleichmann • 18 März, 2024
Numerous IT projects such as S/4HANA projects or HANA migrations will go live over the Easter weekend. Mostly this tasks will be controlled by the SAP provided SUM tool. The SUM is responsible for the techn. migration/conversion part of the data. Over the past years it become very stable and as long as you face no new issues nearly every technical oriented employee at SAP basis team can successfully migrate also bigger systems. In former times you needed a migrateur with certification which is no longer required. As long as all data could be migrated and the system is up and running the project was successful. But what does the result look like? Is it configured according to the best recommendation and experience? Is it running optimized and tuned?No, this is where the problem begins for most companies. The definition of the project milestone is not orienting on KPIs. It is simply based on the last dialog of the SUM tool, which states that the downtime has ended and all tasks have been executed successfully.
more
Share by: