< Back to Blog

saptune 3.2 has been released!

Last Updated On: November 10, 2025 | By: Sören Schmidt

Share
Share
Last Friday saptune 3.2 appeared in the repositories of:
  • SUSE Linux Enterprise Server for SAP applications 12 SP5
  • SUSE Linux Enterprise Server for SAP applications 15 SP3
  • SUSE Linux Enterprise Server for SAP applications 15 SP4
  • SUSE Linux Enterprise Server for SAP applications 15 SP5
  • SUSE Linux Enterprise Server for SAP applications 15 SP6
  • SUSE Linux Enterprise Server for SAP applications 15 SP7
Time to talk about what’s in it!

 

New Things

Verify

We learned, that there is some confusion about how to verify Notes and Solutions. Therefore we introduce new commands to make it more obvious:

saptune note verify applied
saptune solution verify applied

and as short version for saptune note verify applied:

saptune verify applied

What are the differences between the new and old commands?

saptune noteAll enabled Notes (regardless if applied or not) are verified.All applied Notes are verified.

verify verify applied
saptune note All enabled Notes (regardless if applied or not) are verified. All applied Notes are verified.
saptune solution Only for an enabled Solution all enabled Notes of that Solution gets verified. Only for an applied Solution all applied Notes of that Solution gets verified.

Usually enabled Notes are also applied except you have rebooted your system with a disabled saptune.service, but enabled Notes.

 

Configure

The next change is about the configuration file /etc/sysconfig/saptune.

Most certainly, you have never touched that file. It contains internal states, but some rarely used options can be configured only by editing that file.
With 3.2 this file should not be edited anymore directly. With SLES 16 we go a step further and move it away from /etc.

This requires a new set of configuration commands to allow to make changes, when it makes sense.
These commands have safeguards to prevent ending up with an unworkable configuration.

saptune configure OPTION VALUE – sets OPTION to VALUE after sanity check

saptune configure show – shows the content of the saptune configuration file

saptune configure reset – resets the configuration to the installation default (after confirmation)

Check out the man page man 8 saptune for the supported options.

Refresh

To reapply a tuning – after changing an Override, Note or Solution – you have to revert and re-apply the entire tuning. This introduces a short tuning gap. We have been asked several times in the past, if we get rid of it.
This endeavor proved more difficult then expected due to the complexity of the features saptune already has, so we have to deliver this feature stepwise. The first implementation of

saptune note refresh

comes with 3.2, but is still marked as experimental and you have to manually confirm the action!
It can only refresh changes in Notes (and their Overrides) and only a few sections. The man page saptune(8) contains an overview.

New Options

--force-color

Colored output can now be forced with --force-color
Normally the terminal detection disables coloring on output redirect. This new option enforces it.

--fun

Work life can sometimes be dull, so we introduce some fun to brighten the day.
In the tradition of the good ol’ easter eggs, some hidden features will try to put a smile on your face.
To not interrupt workflows and causing the exact opposite, the new option --fun must be used to bring them to light.
The first one are some appropriate smileys for the compliance status in verify:

 

Others will follow in future versions. 😉

 

JSON support for saptune check

Primarily to enhance the integration into Trento, the saptune_check script now supports the option --json, what also means, that –-format json is now supported for saptune check.

New Tags

We also introduced two new tags:
  • virt
    Virtualization type as reported by /usr/bin/systemd-detect-virt or an abstract virtualization class defined as vm, chroot, container or bare-metal.
  • pmu_name
    CPU platform (must match the content of /sys/devices/cpu/caps/pmu_name).
Immediately we made use of virt in SAP Note “2205917 – SAP HANA DB: Recommended OS settings for SLES 12 / SLES for SAP Applications 12” and “2684254 – SAP HANA DB: Recommended OS settings for SLES 15 / SLES for SAP Applications 15”:

 

The CPU tuning now will only be part on x86_64 bare metal systems. This addresses a recent request to not show CPU tuning on virtual machines on verify. Until now saptune has internally detected the impossibility of tuning CPUs under certain circumstances and explained it by warnings and footnotes. Some customers were worried even though.
Limiting the tuning to bare-metal went a bit to far ignoring the fact, that on AWS and GCP some instance types do allow CPU tuning. This was rectified with 3.2.1 (see “saptune 3.2.1 – cloudy, cloudy“)
This also means, that on virtual machines or on IBM Power systems, CPU tuning is not shown on verify including their GRUB counterparts:

 

The screenshot also shows a second improvement. As you know, some tunings can be done by different ways, namely:
  • C-state settings: force_latency versus grub:intel_idle.max_cstate/grub:processor.max_cstate
  • NUMA balancing: kernel.numa_balancing versus grub:numa_balancing
  • Transparent Huge Pages: THP versus grub:transparent_hugepage
Before 3.2 missing GRUB entries have been listed as non-compliant (theoretically correct), but the overall compliance was met, if the alternatives have tuned the system. This caused confusion. Now the GRUB entries are marked with `-` if the counterpart is tuning the setting.

Man Page Additions

Two man pages have been added:

  • saptune-solution(5)
  • saptune(7)

With the feature set for Solutions growing, it was time for a dedicated man page.

In saptune(7) we will collect general information about saptune. For now it only contains an outlook to the behavior on the upcoming SLE 16.

Time To Say Good Bye!

When new things come, old ones have to go.

Some are finally gone now and some others are marked as deprecated.

Now is the time to check and update workflows and scripts!

saptune daemon

Ok, that is not a new one. For some version (== years) the commands saptune daemon start|stop|status are marked as deprecated and internally are redirected to their saptune service replacements. Now it gets serious.
In 3.2 for the upcoming SLE 16 the commands are removed and will not work anymore!

saptune note|solution simulate

The simulate commands are not really necessary and were rarely used.
They are marked as deprecated now and in 3.2 for the upcoming SLE 16 they are removed and will not work anymore!

saptune v1 file format

This should harm nobody. saptune warns for quite some time if the old deprecated format is found, but kept working.
In 3.2 for the upcoming SLE 16 support is removed and v1 custom Notes are ignored!
For your own custom Notes, the fix is quite simple: Just add a `[VERSION]` section.

ASE Solution, SAP Notes 1680803 and 1805750

After removing almost any OS tuning in their guides, we talked to the responsible SAP department and came to the conclusion, that the OS defaults on SLES are more than sufficient by now and additional tuning is not required anymore. With 3.2 we deprecate:

  • “1680803 – SYB: SAP Adaptive Server Enterprise – Best Practice for SAP Business Suite and SAP BW”,
  • “1805750 – SYB: Usage of HugePages on Linux Systems with SAP Sybase ASE” and the
  • “ASE” Solution

In 3.2 for the upcoming SLE 16 all are removed and will not available anymore!

SAP Note 1771258

Another SAP Note that falls victim to progress. Setting limits via limits.conf only works for SAP instances started by SysV init scripts. For instances started by systemd, the limits must be set via a drop-in for the service unit and the nofile limit mentioned in the SAP Note is already set to the recommended value in the shipped one.
Therefore we have deprecated the SAP Note “1771258 – Linux: User and system resource limits” and the `LIMIT` feature itself.
In 3.2 for the upcoming SLE 16 it is removed and not available anymore! SLE 16 has no SysV support anyway and SAP systems must be started by systemd.

For SLES 12 and 15 it will not be removed as long SysV-based SAP software is supported.

Security

To make saptune more secure, we started to tighten saptune.service as the first step. The [Service] section now contains some security settings of systemd:
ProtectSystem=full
ReadWritePaths=/etc/systemd/system/
ProtectHome=true
PrivateDevices=true
ProtectHostname=true
ProtectClock=true
ProtectKernelTunables=false
ProtectKernelModules=true
ProtectKernelLogs=true
ProtectControlGroups=false
MountAPIVFS=no
RestrictRealtime=true
This should not impact the functionality of saptune at all!

Documentation Rework

The saptune chapter in the SLES for SAP application Guide has been complemented with the changes in 3.2. Additionally some chapters got enhancements due to customer feedback too.
The update Guide will be available very early in September.

 

These are most of the changes. A complete list can be found – as always – in the RPM changelog.
As we do with ever no release, all shipped SAP Notes have been updated with their latest versions.
Above several times changes in SLE 16 are mentioned. Closer to its release, a separate blog post will introduce the changes in regards to saptune and sapconf!

 

Enjoy!
Share
(Visited 2 times, 1 visits today)

Related Articles

Jul 24th, 2024

CrowdStrike Outage Exposes the Need for Linux in Critical Systems

Mar 19th, 2024

SUSE Releases Edge 3.0: Highly Validated Edge Optimized Stack

Oct 30th, 2025

Private Offers on Google Cloud Marketplace: A Real-World Case to Solve Cloud Pricing Conflicts

Dec 04th, 2023

Announcing a new usage-based Rancher Prime listing on the AWS Marketplace

Avatar photo
1,067 views
Sören Schmidt