saptune(8)

🌸 saptune(8) — like, the whole vibe 🌸

okay bestie, buckle up 💅 this is saptune(8), and it is the manual page for saptune — Comprehensive system optimization management for SAP solutions (Version 3). yes, capital C, capital S, capital O — it's giving main character energy and honestly? deserved 👑

⚠️ ATTENTION: if you're still on version 1 of saptune, it's literally time to migrate to saptune version 3. please go read saptune-migrate(7). not a suggestion, a lifestyle change 🫶

✨ SYNOPSIS ✨

every single invocation shape, served fresh, no cap:

saptune [--format FORMAT] [--force-color] [--fun] service ( start | stop | restart | takeover | enable | disable | enablestart | disablestop | status [--non-compliance-check] )

saptune [--format FORMAT] [--force-color] [--fun] note ( list | verify | revertall | enabled | applied )

saptune [--format FORMAT] [--force-color] [--fun] note ( apply | customise | create | edit | revert | show | delete ) NOTEID

saptune [--format FORMAT] [--force-color] [--fun] note refresh [NOTEID|applied] ATTENTION: experimental

saptune [--format FORMAT] [--force-color] [--fun] note verify [--colorscheme SCHEME] [--show-non-compliant] [NOTEID|applied]

saptune [--format FORMAT] [--force-color] [--fun] note rename NOTEID NEWNOTEID

saptune [--format FORMAT] [--force-color] [--fun] solution ( list | verify | enabled | applied )

saptune [--format FORMAT] [--force-color] [--fun] solution ( apply | customise | create | edit | revert | show | delete ) SOLUTIONNAME

saptune [--format FORMAT] [--force-color] [--fun] solution change [--force] SOLUTIONNAME

saptune [--format FORMAT] [--force-color] [--fun] solution verify [--colorscheme SCHEME] [--show-non-compliant] [SOLUTIONNAME]

saptune [--format FORMAT] [--force-color] [--fun] solution rename SOLUTIONNAME NEWSOLUTIONNAME

saptune [--format FORMAT] [--force-color] [--fun] staging ( status | enable | disable | is-enabled | list )

saptune [--format FORMAT] [--force-color] [--fun] staging ( analysis | diff ) [ ( NOTEID | SOLUTIONNAME.sol )... | all ]

saptune [--format FORMAT] [--force-color] [--fun] staging release [--force|--dry-run] [ ( NOTEID | SOLUTIONNAME.sol )... | all ]

saptune [--format FORMAT] [--force-color] [--fun] configure ( COLOR_SCHEME | SKIP_SYSCTL_FILES | IGNORE_RELOAD | DEBUG | TrentoASDP ) Value

saptune [--format FORMAT] [--force-color] [--fun] configure ( reset | show )

saptune [--format FORMAT] [--force-color] [--fun] verify applied

saptune [--format FORMAT] [--force-color] [--fun] refresh applied ATTENTION: experimental

saptune [--format FORMAT] [--force-color] [--fun] revert all

saptune [--format FORMAT] [--force-color] [--fun] check

saptune [--format FORMAT] [--force-color] [--fun] status [--non-compliance-check]

saptune [--format FORMAT] [--force-color] [--fun] version

saptune [--format FORMAT] [--force-color] [--fun] help

💖 DESCRIPTION 💖

so, what is saptune? it's the girlboss that automates all the configuration recommendations from SAP and SUSE so you can actually run an SAP application on SLES for SAP 🎀 those configuration recommendations are normally called SAP Notes — yes that's the whole thing, some dedicated SAP Notes are literally the foundation of saptune's work. on top of that, some best practice guides got added as Note definitions too, so the system can be optimized for some really special cases ✨

saptune can apply settings for a single Note definition, or it can set all the settings for a predefined solution — which is just a collection of several SAP Notes, like a little squad 👯‍♀️ and yes, it can also revert all these settings back to the previous system settings. undoing is self-care, periodt.

it can verify whether the current system configuration is in sync with a specific Note definition or a defined solution, and it shows you the differences — the way it does that is honestly iconic. saptune doesn't only set kernel values (like sysctl does), it also handles things like cpu governor, energy perf bias, force latency (dma latency) and the disk io scheduler. plus it checks/verifies that suitable rpm versions are installed and that special kernel command line values are set, all according to the relevant SAP Notes 🔍

so saptune checks and applies values in various locations during runtime, like:

/proc/sys/, /proc/sys/vm/, /proc/sys/kernel, /proc/sys/fs
/sys/block/*/queue/scheduler and /sys/block/*/queue/nr_requests
/sys/devices/system/cpu/*/cpufreq/scaling_governor
/sys/devices/system/cpu/*/cpuidle/state*/latency
/sys/devices/system/cpu/*/cpuidle/state*/disable
/dev/shm
/etc/security/limits.d/
/etc/systemd/logind.conf.d/
and some others 👀

to do most of these settings, saptune needs to run with root privilege. so like, please keep in mind: users who run saptune are considered privileged users with administrative rights. that's a lot of power, bestie — use it responsibly 🔥

by default saptune prints all results to stdout, and Errors and Warnings go to stderr 📢 but! by using --format FORMAT this behaviour can be changed. supported formats are:

🦋 json

prints all results in a machine readable json output format defined by the schemata delivered in /usr/share/saptune/schemas/1.1 💻

and some important lore you need to know: saptune does no longer use tuned(8) to restart after a system reboot. it's using its own systemd service named "saptune.service" 👑

starting with version 3.2 and operating system version 15SP4 we ship the saptune.service with enhanced security-related features like systemd hardening 🛡️ but please keep in mind that all security measures only apply if saptune is invoked by its systemd unit! so like, invoking it by hand doesn't get you that armor, iykyk 😭

we decided to have only ONE solution applied, but multiple Notes. Each Note is applied exactly once. no doubling up. we don't do that here 💅

🛠️ SERVICE ACTIONS 🛠️

✨ `start`

Okay bestie, so start boots up the saptune service and applies a whole set of optimizations to your system — but only if you picked solutions or notes during an earlier call of saptune. And if the service is enabled? The tuning just auto-activates on system boot like it's got main character energy. 🌅

It literally redirects to systemctl start saptune.service.

Success gets reported on stdout, and errors — including systemd error messages — go to stderr. The action gets logged, no cap.

Heads up: it will fail in case sapconf.service is running or has exited, or if save state files are present. 💀

If the action was successful the exit code is 0, otherwise 1.

🩺 `status`

Reports the following status info on stdout — it's giving full diagnostic glow-up:

status of saptune.service (enabled/disabled, active/inactive/failed/...the other possible unit states...)
saptune package version
configured saptune major version (from the central saptune configuration file)
enabled Solution The entry 'enabled Solution' shows the Solution, which was manually applied by saptune solution apply <solution name> and its related Notes.
applied Solution The entry 'applied Solution' shows the Solution, which is currently applied and its related and applied Notes.
additional enabled Notes, sorted lexicographically The entry 'additional enabled Notes' shows all Notes, which were additionally applied manually by saptune note apply <note name>. They are one part of the list of notes in the entry 'applied Notes' and 'enabled Notes'.
all selected Notes in applied order The list of 'enabled Notes' includes all Notes from 'additional enabled Notes' and additional all the Notes related to the 'enabled Solution' too. The list shows the order in which these Notes were applied and will be re-applied after a system reboot, if the saptune.service is enabled.
all currently applied Notes in applied order The list of 'applied Notes' includes the manually applied Notes. Additional it includes all the Notes related to the 'configured Solution' too. These Notes get applied when using saptune solution apply. The solutions and their related notes can be listed by saptune solution list. And additional 'applied Notes' shows if the system is 'actively' tuned at the moment. If the list is empty, the system is not tuned. If the list is not empty, the system is tuned.
A list of orphaned Overrides These are override files existing in /etc/saptune/override, but with no related Note definition file found in the working area /var/lib/saptune/working/ or in the custom/vendor directory /etc/saptune/extra.
state of staging
staged Notes
staged Solutions
status of sapconf.service (enabled/disabled, active/inactive/failed/...the other possible unit states...)
status of tuned (enabled/disabled, active/inactive/failed/...the other possible unit states..., profile)
the overall systemd 'system' status, read from systemctl is-system-running (running, degraded, ....)
the tuning state of the system, gathered by saptune note verify:
- "unknown (checking disabled)", if the flage --non-compliance-check is used.
- "not tuned", if no Solution or Note is applied.
- "not-present", if 'verify' hit an error.
- "not compliant", if one or more parameter values differ from the related SAP Note. For detailed information please use saptune note verify.
- "compliant", if all parameter values comply with the values from the related SAP Notes.

This information is not logged, but only printed to stdout. 🫧

Exit code tea ☕: if saptune.service is not 'active' the exit code is 1. If the system is 'not tuned' — which means no Note or Solution is enabled — the exit code is 3. If the system is tuned, but the tuning is not compliant the exit code is 4. Otherwise the exit code is 0.

🛑 `stop`

Stops the saptune service and reverts all optimizations that were previously applied by saptune. If the service is disabled, the tuning will no longer automatically activate upon boot — it's giving "we're so done" energy. 🙅‍♀️

It redirects to systemctl stop saptune.service.

Success is reported on stdout, errors including systemd error messages are printed on stderr. The action gets logged.

If the action was successful the exit code is 0, otherwise 1.

🔁 `restart`

Reverts all optimizations that were previously applied by saptune. And after that applies a set of optimizations to the system, if solutions or notes were selected during a previous call of saptune. Glow-down then glow-up, iconic. ✨

It redirects to systemctl restart saptune.service.

Success is reported on stdout, errors including systemd error messages are printed on stderr. The action gets logged.

If the action was successful the exit code is 0, otherwise 1.

If IGNORE_RELOAD is set to yes in the saptune configuration file the action 'restart' will do nothing. The reason will be logged. See the 'NOTE' section at the end of the man page for more information.

✅ `enable`

Enables the saptune service. To activate the tuning, the saptune service needs to be started. But as the service is now enabled, the tuning will automatically activate upon system boot. 🎀

It redirects to systemctl enable saptune.service.

Success is reported on stdout, errors including systemd error messages are printed on stderr. The action gets logged.

It will fail in case sapconf.service is running or has exited, or if save state files are present. 💀

If the action was successful the exit code is 0, otherwise 1.

🚫 `disable`

Disables the saptune service. To revert all optimizations that were previously applied by saptune, the saptune service needs to be stopped. But as the service is now disabled, the tuning will no longer automatically activate upon system boot. Bye bestie 👋

It redirects to systemctl disable saptune.service.

Success is reported on stdout, errors including systemd error messages are printed on stderr. The action gets logged.

If the action was successful the exit code is 0, otherwise 1.

🌟 `enablestart`

Enables and starts the saptune service, then applies a set of optimizations to the system, if solutions or notes were selected during a previous call of saptune. As the service is now enabled, the tuning will automatically activate upon system boot. Two-for-one slay 💅

Calls systemctl enable saptune.service and systemctl start saptune.service in this order.

Success is reported on stdout, errors including systemd error messages are printed on stderr. The action gets logged.

If the action was successful the exit code is 0, otherwise 1.

🌙 `disablestop`

Disables and stops the saptune service, and reverts all optimizations that were previously applied by saptune. As the service is now disabled, the tuning will no longer automatically activate upon system boot. Closing time 🕯️

Calls systemctl disable saptune.service and systemctl stop saptune.service in this order.

Success is reported on stdout, errors including systemd error messages are printed on stderr. The action gets logged.

If the action was successful the exit code is 0, otherwise 1.

👑 `takeover`

This action is meant to start and enable saptune service where competing services like sapconf and/or tuned get stopped and disabled. This is the modern replacement for the removed saptune daemon start — it's giving succession arc. 🫶

Calls systemctl enablestart saptune.service after stopping and disabling sapconf.service and tuned.service.

Success is reported on stdout, errors including systemd error messages are printed on stderr. The action gets logged.

If the action was successful the exit code is 0, otherwise 1.

⚠️ ATTENTION

saptune is able to start/stop/enable/disable systemd units, but on boot the outcome depends on the order of execution. Order matters, bestie — it's literally the whole plot. 😭

If saptune is starting (or stopping) a systemd service ([service] section) it might happen, that the action gets reverted later by systemd because that service is disabled (or enabled) and executed after saptune.service.

Similar a service enabled (or disabled) by saptune might already be stopped (or started) by systemd, because it came before saptune.service.

If the execution order cannot be assured by service dependencies, it is recommended to set both (start,enable or stop,disable) in a Note definition or an Override.

📝 NOTE ACTIONS 📝

So, "Note" here denotes either a SAP Note, a vendor specific tuning definition or a SUSE recommendation article. All three, same vibe check. 🌸

🧚 `apply`

Applies optimization settings specified in the Note. The Note will be automatically activated upon system boot if the saptune service is enabled.

If a Note definition contains a [reminder] section, this section will be printed after the note has applied successfully. It will be highlighted with red color. 🚨

A Note can only be applied once.

⚠️ ATTENTION: Please be in mind: If a Note definition to be applied contains parameter settings which are likewise set before by an already applied Note these settings get be overwritten. The last comes, the last wins, it's all about 'order'.

So be careful when applying solutions or notes or when reverting notes, especially if these notes are part of an already applied solution. You can re-apply such a note, but the order — and may be the resulting parameter settings — will be unlike before. Special attention is needed, if customer or vendor specific notes from /etc/saptune/extra are used. 👀

📋 `list`

Lists all SAP Notes, vendor specific tuning definitions and SUSE recommendation articles that saptune is capable of implementing. The whole roster, fr fr. ⭐

Currently implemented notes get a lil marker next to them: + if you enabled it yourself by hand, * if a solution turned it on, or - if a note that belongs to an enabled solution got reverted manually. Whichever one it is, these notes are highlighted in green. ✨

If an override file exists for a NoteID, the note gets marked with O, and a customer- or vendor-specific note gets marked with C.

If we sniff out a conflict between notes, the related entry in the list gets a leading ! and the whole line lights up yellow. Go peek at the log file for the deets — that's where the warning messages about the problem live. Right now we report a conflict when a customer or vendor specific note has the same name as a shipped note. In that case, the shipped note wins and takes precedence over the custom one. (no cap, that's just how it goes 💅)

enabled

Prints all currently enabled notes as a list separated by blanks, with no trailing line feed. Clean and simple. 🎀

applied

Prints all currently applied notes as a list separated by blanks, with no trailing line feed. Same energy, different list. 💖

verify

If you pass it a Note ID, saptune verifies the currently running system against the recommendations specified in that Note. It's giving "vibe check but for your kernel settings". 🔥

The output table looks like this:

SAPNote, Version | Parameter | Expected | Override | Actual | Compliant

Expected — the values read from the Note definition file
Override — the values found in an override file
Actual — the current system value
Compliant — yes if the Expected and Actual values match, or no if there's no match

Some rows have little footnote references with extra info, and they'll explain why a value doesn't match. Here's the whole legend, bestie 🧚:

[1] setting is not supported by the system This may result in a - in column Compliant, but the system will nevertheless be reported as fully conforms to the specified note.
[2] setting is not available on the system In case of grub settings, this may result in a no in column Compliant, but the system will nevertheless be reported as fully conforms to the specified note, because most grub settings mentioned in the SAP Notes are covered by other, alternative settings.
[3] value is only checked, but NOT set In case of grub settings, this may result in a no in column Compliant, but the system will nevertheless be reported as fully conforms to the specified note, because most grub settings mentioned in the SAP Notes are covered by other, alternative settings.
[4] cpu idle state settings differ
[5] expected value does not contain a supported scheduler
[6] grub settings are mostly covered by other settings. See man page saptune-note(5) for details
[7] parameter value is untouched by default If the parameter value in the Note definition file is left empty, the current system value of the parameter will not be changed.
[8] cannot set Perf Bias because SecureBoot is enabled" If SecureBoot is enabled some system settings are read only and can not be changed.
[9] expected value limited to max_hw_sectors_kb" The possible value for parameter MAX_SECTORS_KB (/sys/block/*/queue/max_sectors_kb) is limited by the value of /sys/block/*/queue/max_hw_sectors_kb.

If a Note definition contains a [reminder] section, that section gets printed below the table and the footnotes, and it'll be highlighted in red. 🚨

Oh and — by using the command line argument --show-non-compliant you can limit the verify output to show only non-compliant parameters. Heads up though: the output will not be colorized even if a color scheme is defined. 🙈

Okay so you can use a color scheme for the verify output table, and it's lowkey adorable. The color scheme can be given as a command line argument --colorscheme SCHEME or as a parameter–value pair COLOR_SCHEME SCHEME in the saptune command saptune configure COLOR_SCHEME <SCHEME>.

To reset the color scheme, use the command saptune configure COLOR_SCHEME ''

Possible color schemes are:

full-green-zebra — whole line is colored green (compliant) or red (not compliant)
full-blue-zebra — whole line is colored blue (compliant) or yellow (not compliant)
cmpl-green-zebra — only the content in the Compliant column is colored green (compliant) or red (not compliant)
cmpl-blue-zebra — only the content in the Compliant column is colored blue (compliant) or yellow (not compliant)
full-red-noncmpl — only the whole line of the not compliant parameter is colored red
full-yellow-noncmpl — only the whole line of the not compliant parameter is colored yellow
red-noncmpl — only the content in the Compliant column of the not compliant parameter is colored red
yellow-noncmpl — only the content in the Compliant column of the not compliant parameter is colored yellow

The default, if no color scheme is given, is full-red-noncmpl. And if an unknown color scheme is given in the command line or in the config file, you get non-colorized, simple black text printed. Humble. 🖤

The "final lines" with the overall result of the verify operation are colored green (compliant) or red (not compliant) independent from the chosen color scheme. Those ones always show up dripped out, periodt. 👑

edit

This one lets you edit the values of the customer or vendor specific Note definitions in /etc/saptune/extra. An editor gets launched so you can change the Note definitions — the editor is defined by the EDITOR environment variable, and if that's not set the editor defaults to /usr/bin/vim.

You can change already available parameters and values, or you can add new parameters and values, or add additional sections with parameter value pairs. Go off, customize your heart out. 💅

If the Note is currently applied and/or an override file exists, saptune will remind you to take care of this situation. Considerate queen behavior tbh. 🫶

customise

This allows you to customize the values of the saptune Note definitions. The Note definition file will be copied from /usr/share/saptune/notes or /etc/saptune/extra to the override location at /etc/saptune/override, if the file does not exist already. After that an editor will be launched so you can change the Note definitions. The editor is defined by the EDITOR environment variable — if it's not set, editor defaults to /usr/bin/vim.

K important boundary: you can only change the value from already available parameters of the note. You are not able to add new parameters. That's the whole line between customise and edit, iykyk. 🌸

If you want to use new parameters to tune the system, please create your own custom Note definition file in /etc/saptune/extra.

You can prevent a parameter from being changed by leaving the parameter value in the override file empty. That parameter will be marked as untouched in the override column of the verify table. Iconic little safe space for your settings. ✨

The values from the override files will take precedence over the values from /usr/share/saptune/notes or /etc/saptune/extra. In such case you will not lose your customized Notes between saptune or vendor updates. The saptune options list and verify will mark the existence of an override file and the contained values.

ATTENTION: Creating or changing an override file just changes the configuration inside this Note definition file, but does not change the running configuration of the system. That means: when creating or changing an override file for an already applied Note definition, please do a saptune note revert <NoteID> and then apply this Note again, to get the changes take effect. Do not skip this step bestie, it will not work otherwise 😭

create

This allows you to create own Note definition files in /etc/saptune/extra. The Note definition file will be created from a template file into the location /etc/saptune/extra, if the file does not exist already. After that an editor will be launched so you can change the Note definitions. The editor is defined by the EDITOR environment variable — if it's not set, editor defaults to /usr/bin/vim. You need to choose a unique NoteID for this operation, so use saptune note list to find the already used NoteIDs. No duplicate names, we're not doing that. 🚫

refresh

ATTENTION: experimental

Identifies and activates changed parameter settings of a Note definition. The changes get active without first reverting the old settings, so the tuning of the system gets not interrupted. Seamless glow-up energy. ✨

ATTENTION: This action is currently in the state experimental!

Currently only parameter of section [sysctl], [sys] and [vm] are supported by the refresh action.

Parameter of section [version], [rpm], [grub], [fs] and [reminder] are only checked by saptune, but not applied. So there is nothing to do during refresh of a note and these sections are skipped without notice. 🙈

Parameter of all other sections are currently not supported by the refresh action and not evaluated. If such parameter are available in the to be refreshed Note, an info is logged per affected parameter. At least it tells you, fr fr. 💀

revert

Revert optimization settings carried out by the Note, and the Note will no longer be activated automatically upon system boot. Clean slate, we love to see it. 🦋

revertall

Revert optimization settings carried out by all applied notes, and the notes will no longer be activated automatically upon system boot. All of them. Every single one. Group revert, iconic. 🌈

show

Print content of Note definition file to stdout. Simple as that, no notes. 🎀

delete

This allows you to delete a customer or vendor specific Note definition file including the corresponding override file if available. A confirmation is needed to finish the action — we're not letting you nuke things by accident. 💅

ATTENTION: Note definition files shipped by the saptune package — so called internal saptune Note definition files — must not be deleted. There will be an appropriate error message. If a corresponding override file is available, there will be the possibility to delete this file instead.

rename — okay bestie, this one renames a customer or vendor specific Note definition file to a shiny new name. If there’s a corresponding override file, that gets renamed too. A confirmation is needed to finish the action. If the new Note definition name already exists, the command stops with a message about it.

⚠️ ATTENTION: Note definition files shipped by the saptune package — the so-called internal saptune Note definition files — and their corresponding override files, if available, must not be renamed. You’ll get an appropriate error message.

⚠️ ATTENTION: If the Note is already applied, the command stops and tells you that the Note first needs to be reverted before it can be renamed.

🌈 SOLUTION ACTIONS 🌈

A solution is literally a collection of one or more Notes, and activating a solution activates all the associated Notes. It’s giving “one playlist, many bangers” 💅

The solution definitions shipped with saptune live in /usr/share/saptune/sols, and vendor/customer specific solution definitions live in /etc/saptune/extra.

You cannot combine solutions — there can only be one solution enabled. But you can change a solution definition by using an override file in /etc/saptune/override, or by creating a custom specific solution definition in /etc/saptune/extra. Iconic flexibility, no cap ✨

The following solution definitions are currently shipped with saptune:

BOBJ — Solution for running SAP BusinessObjects.
HANA — Solution for running an SAP HANA database.
MAXDB — Solution for running an SAP MaxDB database.
NETWEAVER — Solution for running SAP NetWeaver application servers.
NETWEAVER+HANA — Solution for running both SAP application servers and SAP HANA on the same host.
NETWEAVER+MAXDB — Solution for running both SAP application servers and SAP MaxDB on the same host.
S4HANA-APPSERVER — Solution for running SAP S/4HANA application servers
S4HANA-APP+DB — Solution for running both SAP S/4HANA application servers and SAP HANA on the same host
S4HANA-DBSERVER — Solution for running the SAP HANA database of an SAP S/4HANA installation
SAP-ASE — Solution for running an SAP Adaptive Server Enterprise database.

Syntax of the solution definition file names:

<solutionName>.sol
e.g. V4711.sol

apply — Apply optimization settings recommended by the solution. These settings are automatically activated upon system boot if the saptune service is enabled. Set it and forget it, bestie 🫶
list — List all solution names that saptune is capable of implementing. The currently implemented solution is marked with * and highlighted with green color. A deprecated solution is marked with D. If an override file exists for a solution, the solution is marked with O. A custom specific solution is marked with C. If a note belonging to an enabled solution is reverted manually, the note is highlighted with red color (instead of green) and is crossed out. If we detect a conflict with solutions, the related entry in the list is marked with a leading ! and the line is highlighted with yellow color. Look at the log file for details like warning messages addressing the problem. Currently we report a conflict if a customer or vendor specific solution has the same name as a shipped solution. In this case the shipped solution will take precedence over the custom solution. Drama, but make it functional 💀
enabled — Print the currently enabled solution.
applied — Print the currently applied solution. If one or more notes of the solution are reverted — which is indicated by a - in the output of saptune note list — the string (partial) is added to the solution name.
verify — If a Solution name is specified, saptune verifies the running system against all Notes of that Solution regardless of their state.
edit — This allows you to edit the note list of the customer or vendor specific solution definitions in /etc/saptune/extra. An editor will be launched to allow changing the Note definitions. The editor is defined by the EDITOR environment variable. If not set, editor defaults to /usr/bin/vim. You can change, add or delete noteIDs in the list of notes defining the solution. If the solution is currently applied and/or an override file exists, saptune will remind you to take care of this situation.
customise — This allows you to customize the note list of the saptune solution definitions. The solution definition file will be copied from /usr/share/saptune/sols or /etc/saptune/extra to the override location at /etc/saptune/override, if the file does not exist already. After that an editor will be launched to allow changing the solution definitions. The editor is defined by the EDITOR environment variable. If not set, editor defaults to /usr/bin/vim. You can change, add or delete noteIDs in the list of notes defining the solution. The values from the override files will take precedence over the values from /usr/share/saptune/sols or /etc/saptune/extra. In such case you will not lose your customized solutions between saptune or vendor updates. The saptune option list will mark the existence of an override file.

⚠️ ATTENTION: Creating or changing an override file just changes the configuration inside this solution definition file, but does not change the running configuration of the system. That means: when creating or changing an override file for an already applied solution definition, please do a saptune solution revert <solutionName> and then apply this solution again, to get the changes take effect. No shortcuts, bestie 😭

create — This allows you to create own solution definition files in /etc/saptune/extra. The solution definition file will be created from a template file into the location /etc/saptune/extra, if the file does not exist already. After that an editor will be launched to allow changing the solution definition. The editor is defined by the EDITOR environment variable. If not set, editor defaults to /usr/bin/vim. You need to choose an unique solution name for this operation. Use saptune solution list to find the already used solution names.
revert — Revert optimization settings recommended by the solution, and these settings will no longer be activated automatically upon system boot.
change — Switch to a new solution even that another solution was already applied.

⚠️ ATTENTION: Because of the revert of the old solution during the execution of the action change, the system will be not sufficient tuned for SAP workloads for a short period of time until the new solution is applied successfully. This may harm a running SAP system. So use this action carefully. And please be in mind: because of the revert and apply, the order of notes and therefore the active tuning may change, especially if additional notes were applied beside the old applied solution.

show — Print content of solution definition file to stdout.
delete — This allows you to delete a customer or vendor specific solution definition file including the corresponding override file if available. A confirmation is needed to finish the action.

⚠️ ATTENTION: Solution definition files shipped by the saptune package — the so-called internal saptune solution definition files — must not be deleted. There will be an appropriate error message. If a corresponding override file is available, there will be the possibility to delete this file instead.

⚠️ ATTENTION: If the Solution is already applied, the command will be terminated with the information that the Solution first needs to be reverted before it can be deleted.

rename — This allows you to rename a customer or vendor specific solution definition file to a new name. If a corresponding override file is available, this file will be renamed too. A confirmation is needed to finish the action. If the new solution definition name already exists, the command will be terminated with a respective message.

⚠️ ATTENTION: Solution definition files shipped by the saptune package — the so-called internal saptune solution definition files — and their corresponding override files, if available, must not be renamed. There will be an appropriate error message.

⚠️ ATTENTION: If the Solution is already applied, the command will be terminated with the information that the Solution first needs to be reverted before it can be renamed.

🎀 STAGING ACTIONS 🎀

okay so bestie, staging is the whole "don't just surprise me" feature 💅 — it exists so you (the customer) get to control and release changes that package updates ship into your working environment. Like, the whole idea is that Note definition files shipped by saptune in updates are not used by saptune for system tuning immediately. An administrator has to explicitly release the updates before saptune uses them. This means you can update saptune — even with changed Notes — without having changes in system behavior. no cap, that's the entire point ✨

Staging is disabled by default, because not every customer needs the feature, and having it enabled by default would break the previous behaviour. 🫶

You can enable staging with saptune staging enable (see the description below, it's right there 👇).

So now we've got 3 areas where Note definition files and solution definitions shipped by saptune can live:

heads up: this is only about Note definition files and solution definitions shipped by saptune. Custom definition files or override files are NOT affected. 🚫

📦 Package Area

Directory where the saptune package stores and maintains shipped Note definition files and solution definitions. This directory gets changed by RPM package operations solely.

Currently this is /usr/share/saptune/.

🌸 Working Area

Directory which contains configuration objects saptune note|solution|service will use. Only Notes and solutions from here can be applied.

Currently this is /var/lib/saptune/working/.

🦋 Staging Area

Directory where configuration objects are stored, which are present in the package area but differ from the objects in the working area.

Currently this is /var/lib/saptune/staging/.

At the moment only the Notes from the last update are kept in /var/lib/saptune/staging/latest.

status — Displays the status of staging, basically the content of the variable STAGING in the central saptune configuration file.
is-enabled — Returns the status of staging, basically the content of the variable STAGING in the central saptune configuration file, as an exit code (0 == enabled, 1 == disabled). No output is generated, because this one is meant to be used in scripts. 🤖
enable|disable — Enables or disables staging, by setting the variable STAGING in the central saptune configuration file. The result of the status change is displayed. ✨

Altering the setting does not change the content of the staging and working directory. If a user disables staging, a package update might clean the staging area and update the working area. 👀

list — Lists all Notes and the solution definition which can be released from the staging area, including name, description, version and release date. The solution definition is shown as a whole object — it is only possible to release the entire definition, but not single solutions. Lastly a hint is printed to remind the user that he has to release staged objects before he can use them, and that it is possible to view the changes. 🎀
diff [ ( NOTEID | SOLUTIONNAME.sol )... | all ] — Shows the differences between the Note (or all Notes) or the Solution definition in the staging area and the working area. For each Note in the staging area the output contains the values of all parameters which differ. This includes new or removed parameters as well as changes in the reminder section. For the Solution, all changed solutions are displayed with their differences. Lastly a hint is printed to remind the user that he has to release staged objects before he can use them. 🔍
analysis [ ( NOTEID | SOLUTIONNAME.sol )... | all ] — Does an analysis of the requested Notes, the Solution definitions or everything in the staging area to warn the user about possible issues or additional steps to perform. Lastly a hint is printed to remind the user that he has to release staged objects before he can use them, as well as that he should check out the differences. 🧐
release [ ( NOTEID | SOLUTIONNAME.sol )... | all ] — Releases the requested Notes, the Solution definitions or everything in the staging area. This means the Notes or the Solution definitions get moved from the staging area to the working area. In case of a deleted Note/Solution, it will be removed from the working area. First the command will show an analysis of the objects going to be released, to make the user aware of further needed actions or potential problems (for details see saptune staging dependencies).

⚠️ Because the release is irreversible, the user has to confirm the action. Like, fr fr, it asks first — read it before you smash that confirm, bestie. 😭

🌈 CONFIGURE ACTIONS 🌈

This replaces the direct editing of the saptune configuration file /etc/sysconfig/saptune in SLES for SAP 15 — which will be replaced by an intern configuration file in SLE 16 and won't be present in future versions. 👑

Not all of the former variables will be available as a configure option — only those which should be changeable by the user. iykyk.

COLOR_SCHEME SCHEME — Default color scheme. See saptune verify in this man page for available color schemes. To reset the color scheme use an empty value as SCHEME, like saptune configure COLOR_SCHEME ''
SKIP_SYSCTL_FILES FILE[,FILE...] — Comma-separated list of sysctl config files or directories which should be excluded when checking if parameters handled by saptune are handled by sysctl as well. Input is checked: if the given files are in a location which is searched by the sysctl command, and if not, the files will be skipped.
IGNORE_RELOAD yes||no — Controls behavior of systemctl reload saptune.service and the systemctl try-restart saptune.service during package installation.
DEBUG on||off — Turns on or off the DebugLog output.

🚨 ATTENTION: Active DebugLog will clutter the output of saptune commands and can render the output hard to read. Additionally it is flooding the log file with debug information. So use this setting with caution. Only turn it on if instructed by SUSE support to do so. 💀

TrentoASDP <period>||off — Sets the discovery period (saptune-discovery-period) of the Trento Agent in /etc/trento/agent.yaml for collecting saptune information from the system. The discovery period is the time in seconds between 2 saptune calls initiated by the Trento Agent — the tick interval for the saptune discovery loop. Adapting this value can prevent saptune currently in use, try later errors (exit code 11) from saptune. Trento will start with a default of 900s Possible values are "300", "600", "900", "1800" and "3600" seconds or "off" to disable the check during start of saptune

If the variable is set, saptune will check during start if the value of the variable found in the saptune configuration file is valid and still set in /etc/trento/agent.yaml. If not, a Warning will pop up. Setting TrentoASDP to "off" will disable the check during start of saptune. The setting of saptune-discovery-period in the Trento Agent config is not affected by this setting. 🧚

reset — Reverts the tuning and resets the content of the saptune configuration file to the installation default. Asks for confirmation. ✅
show — Shows the content of the saptune configuration file. 👀

⭐ VERIFY ACTIONS ⭐

verify applied — Verifies all system parameters against all applied Notes. Same as a saptune note verify

🔥 REFRESH ACTIONS 🔥

refresh applied — ATTENTION: experimental 🧪 Refreshes all applied Notes. Same as a saptune note refresh

🦋 REVERT ACTIONS 🦋

revert all — Revert all optimization settings recommended by the SAP solution and/or the Notes, and these settings will no longer be activated automatically upon system boot. 💜

🎀 CHECK ACTIONS 🎀

check — Will simply call the external script /usr/sbin/saptune_check.

🌸 STATUS ACTIONS 🌸

status — Will display the current saptune status. This will be short for saptune service status.

👑 VERSION ACTIONS 👑

version — Will display the currently active saptune version.

✨ HELP ACTIONS ✨

help — Will display the syntax of saptune

💖 VENDOR SUPPORT 💖

To support vendor or customer specific tuning values, saptune supports 'drop-in' files residing in /etc/saptune/extra. All files found in /etc/saptune/extra are listed when running saptune note list. All note options are available for these files. slay. 🫶

We simplified the file name syntax for these vendor files. Related to this we add 'header' support (see description of section [version] in saptune-note(5)) for the vendor files as already available for the Note definition files in /usr/share/saptune/notes to get a proper description during saptune option list.

Syntax of the file names:

<NoteID>.conf

e.g. V4711.conf

Syntax of the file:

The content of the 'drop-in' file should be written in an INI file style with sections headed by [section_name] keywords. See saptune-note(5) to find the supported sections and their available options.

🚨 ATTENTION: If renaming or removing an active (aka 'already applied') note definition file from the file system, the old name of this note still remains in the configuration of saptune. This may lead to unexpected messages. So please always revert the note before renaming or removing it from the file system. Even if editing an active vendor or customer specific note definition file on the file system level, please do a revert of that note and then apply the Note again, to get the changes take effect. 😭 seriously, do the revert first.

🧚 customer specific solution definitions

In addition to the vendor or customer specific note file definitions described previously, saptune now supports vendor or customer specific solution definitions by using 'drop-in' files in /etc/saptune/extra. All solutions found in /etc/saptune/extra are listed when running saptune solution list. All solution options are available for these solutions.

Syntax of the solution definition file names:

<solutionName>.sol

e.g. V4711.sol

⚠️ ATTENTION ⚠️

Trento support, bestie, listen up: if you're planning to use Trento and its whole "I check whether your SAP environment config is actually correct" superpower, you gotta adapt the following solution name schema for your custom solutions, okay?

<saptune_shipped_solutionname>_<your_preferred_badge>.sol

e.g. NETWEAVER_MyOwnSolution.sol — that's the vibe 💅

File syntax time ✨ The content of the custom specific solution files should be written in a INI file style with sections headed by [section_name] keywords. At the moment saptune supports two architectures — ArchX86 for the x86 platform and ArchPPC64LE for 64-bit PowerPC little endian platform for the solution definitions. So the possible sections for solution definitions are [version] (peep the description of section [version] in saptune-note(5)) for a brief description of the solutions, plus [ArchX86] and [ArchPPC64LE] for the solution definitions themselves. Iconic.

The solution itself is described as a list of note definition files separated by blanks. The solution name is defined by the filename without the .sol suffix. A solution is only valid and listed by saptune solution list if all the listed note definition files can be found in the working area or in /etc/saptune/extra. No notes, no listing, periodt.

e.g. filename is NEWSOL1.sol with content

[version]
VERSION=1
DATE=15.12.2020
DESCRIPTION=My custom specific solution definitions
REFERENCES=
[ArchX86]
1980196 CUSTOMNOTE1 CUSTOMNOTE2
[ArchPPC64LE]
1980196 CUSTOMNOTE1 CUSTOMNOTE2

🚪 EXIT CODES 🚪

All saptune commands share the following exit codes, and yes they're giving "we're all in this together" energy:

0 — the action was successfully 🎉
1 — the action failed 😭
128 — an error in the configuration file occurred e.g. missing variables) 💀

The following commands have individual exit codes additionally or alternatively (main character energy, they get their own rules):

`saptune service status`

1 — saptune.service is not started (regardless if configured or not)
2 — not used
3 — saptune.service has been started, but tuning (Note or Solution) is not configured
4 — saptune.service has been started, but tuning is not compliant.

`saptune staging analysis`

1 — actions are required by the user, but no solution might break
2 — a Solution might break 😬
5 — error during calculation

`saptune staging release`

2 — a Solution might break 😬
5 — error during calculation

`saptune check`

1 — some warnings occurred and saptune should work
2 — some errors occurred and saptune will not work
3 — wrong parameters has been given to the tool (should never happen, if called by saptune check!)
5 — unexpected errors in regards of JSON output occurred

🔥 HOTFIX 🔥

A HotFix is a new way to react fast to critical bugs, that can harm SAP installations. It's basically the emergency glow-up 🚑✨

It is meant to bridge the time with a temporary mitigation until the permanent fix is available. As soon as the fix is released, the next released saptune version will contain an update to the HotFix to be applied only when necessary. One year after the fix is available, we will remove the HotFix from saptune. Cleanup era, we love to see it.

We hope to provide an comfortable way to address such issues. 🫶

The HotFix will be added as individual Note with the name HotFix<TID_NUMBER> and can be part of a Solution. A HotFix release will contain only configuration changes and no new features. (No surprise features, just fixes, iykyk.)

To activate the HotFix you can simply apply the Note by

saptune note apply HotFix<TID_NUMBER>

which will not interrupt your current tuning but add the needed parameter settings. The change will take effect immediately and is reboot persistent. So chill, your tuning stays up 🌸

Or you restart the saptune.service, which will lead to a short gap in your tuning because of the 'revert'/'apply' workflow of the service restart. Your SAP workload should be stopped for this operation. Yeah, that one's a whole thing — plan for it.

Or you reboot your server.

As soon as the permanent fix is available and installed on the system, the Hotfix can be reverted with

saptune note revert HotFix<TID_NUMBER>

The next released saptune version will contain an update of the HotFix with a condition (tag) to apply this HotFix only under the condition the permanent fix is not installed on the systems. The HotFix will be removed from saptune one year after the permanent fix is available, giving customers enough time to update their systems. Considerate queens 👑

🦋 CHANGES 🦋

`changelog`

The changelog file of the saptune rpm package contains detailed information, what was changed between the various package versions. The command

rpm -q --changes saptune | more

will show the content of the file. Go read your history, bestie 📖

`version 3`

With the update to saptune version 3 saptune does no longer use tuned(8) to restart after a system reboot. It is using its own systemd service named "saptune.service".

So we now deprecated all "DAEMON ACTIONS" like saptune daemon start. These commands will still work as they are internally linked to the related "SERVICE ACTIONS" like saptune service takeover. Please refer to the related section descriptions at the top of this man page. Old habits but make it service-y 💅

`version 3.1`

With the update to saptune version 3.1 we deprecated the actions saptune note simulate and saptune solution simulate.

`version 3.2`

With the update to saptune version 3.2 on SLES for SAP 12 and 15 we deprecated the manual editing of the file /etc/sysconfig/saptune as the main configuration file will be (re)moved in future versions. So like... don't get attached to it bestie.

Additional the Solution SAP-ASE.sol and the related Notes 1680803 and 1805750 are deprecated on SLES for SAP 12 and 15 and removed in SLE 16.

SAP Note 1771258 not relevant/valid anymore on SLE 16, we deprecated the Note and the support for setting PAM limits in SLES for SAP 12 and 15 and removed both in SLE 16.

The already deprecated actions 'daemon', 'note simulate' and 'solution simulate' are removed in SLE16. Gone gone, not coming back 🙈

`version 3.2.3`

SAP Note 941735 not relevant/valid anymore, we deprecated the Note with the update to saptune version 3.2.3 on SLES for SAP 12, 15 and 16 and on plain SLES 16.

📁 FILES 📁

/usr/share/saptune/schemas/1.0 — schemata that define the json output format, available since saptune version 3.1. iconic little schema era ✨
/usr/share/saptune/schemas/1.1 — schemata that define the json output format, available since saptune version 3.2. upgraded schema, same slay 💅
/usr/share/saptune/notes — part of the Package Area. These are the saptune SAP Note definitions, shipped by the saptune RPM package. Bestie, please do not change the files here. You will lose all your changes during a saptune package update. 😭
/usr/share/saptune/sols — part of the Package Area. These are the saptune solution definitions, shipped by the saptune RPM package. Please do not change these either, because maintenance updates of package saptune will overwrite these files without preserving any custom changes. no cap, use override files instead 🫶
/var/lib/saptune/working/notes — part of the Working Area. These are the saptune SAP Note definitions that can be listed by saptune note list. The files are named with the number of their corresponding SAP Note (==NoteID). A description of the syntax and the available tuning options lives in saptune-note(5). Please do not change the files located here. You will lose all your changes during a saptune staging release command. Use override files to change parameter values if needed. 💖
/var/lib/saptune/working/sols — part of the Working Area. These are the saptune solution definitions that can be listed by saptune solution list. At the moment saptune supports two architectures — ArchX86 for the x86 platform and ArchPPC64LE for 64-bit PowerPC little endian platform — with different solution definitions. Please do not change the files located here, as the command saptune staging release may overwrite these files without preserving any custom changes. Use override files to change the note list of the solutions. 🦋
/var/lib/saptune/staging/latests — part of the Staging Area. These are the saptune SAP Note or solution definitions that are present in the Package Area but differ from the files in the Working Area. staging-era behavior, very main character energy 👑
/etc/sysconfig/saptune — the central saptune configuration file in SLES for SAP 12 and 15. It contains the information about the currently enabled notes and solutions, the order in which these notes are applied, and the version of saptune currently used. ATTENTION: the manual editing of this file will be deprecated on SLES for SAP 12 and 15 as the main configuration file will be (re)moved in SLE 16. Please use saptune configure command instead of editing the file directly. 🙈
/etc/saptune/extra — vendor or customer specific tuning or solution definitions. Please see VENDOR SUPPORT above for more information. You can use saptune note create NoteID or saptune solution create solutionName to create a new vendor or customer specific definition, or saptune note edit NoteID or saptune solution edit solutionName to modify an already existing vendor or customer specific definition. cute custom corner, fr fr 🎀
/etc/saptune/override — the saptune Note and solution definition override location. If you need to customize the Note or solution definitions found in /usr/share/saptune/notes or /usr/share/saptune/sols or in /etc/saptune/extra, you can copy them to /etc/saptune/override and modify them as you need. Please stay with the original name of the Note or solution definition (the NoteID or solution name) and do NOT rename it. Or use saptune note customize NoteID or saptune solution customize solutionName to do the job for you. override girlies rise 💅
/run/saptune/saved_state/ and /run/saptune/parameter/ — saptune was designed to preserve the state of the system before starting the SAP specific tuning, so that it will be possible to restore this previous state of the system if the SAP specific tuning is no longer needed or should be changed. This system state is saved during the apply operation of saptune in the saptune internal used files in /run/saptune/saved_state and /run/saptune/parameter. The content of these files highly depends on the previous state of the system. If the values are applied by saptune, no further monitoring of the system parameters are done, so changes of saptune relevant parameters will not be observed. If a SAP Note or a SAP solution should be reverted, then first the values read from the /run/saptune/saved_state and /run/saptune/parameter files will be applied to the system to restore the previous system state, and then the corresponding save_state file will be removed. Please do not change or remove files in this directory. The knowledge about the previous system state gets lost and the revert functionality of saptune will be destructed. So you will lose the capability to revert back the tunings saptune has done. 😭 protect the saved state, bestie 🫶

📝 NOTE 📝

Using saptune within a pipe, the color information will be removed from the output. It is possible to change this behavior by using the command line option --force-color. rainbow mode said “not today, pipe” 🌈

📝 NOTE 📝

When the values from the saptune Note definitions are applied to the system, no further monitoring of the system parameters are done. So changes of saptune relevant parameters by using the sysctl command or by editing configuration files will not be observed. If the values set by saptune should be reverted, these unrecognized changed settings will be overwritten by the previous saved system settings from saptune. lowkey important, highkey real 💀

📝 NOTE 📝

To prevent unintended reload/restart of saptune during package installation/update of saptune or normal work — which will result in a short time period where the system is not tuned for SAP workloads — it’s possible to set the parameter IGNORE_RELOAD in the central saptune configuration file /etc/sysconfig/saptune.

IGNORE_RELOAD is used to control the systemctl reload saptune.service behavior.

Default is IGNORE_RELOAD="no", which means that the reload is working as expected.

If set to yes, a systemctl reload saptune.service and a saptune service restart will do nothing. The reason will be logged.

Additional this parameter setting will prevent systemctl restart saptune.service (which is a ExecStop followed by ExecStart) called from macros used during the package installation/update of the saptune package from restarting the tuning.

ATTENTION: Outside the saptune package installation systemctl restart saptune.service can not be blocked. periodt, that’s just how it is 💅

🚨 ATTENTION 🚨

Higher or lower system values set by the system, the SAP installer or by the administrator using sysctl command or sysctl configuration files will be now overwritten by saptune, if they are part of the applied Note definitions.

saptune now sets the values read from the Note definition files irrespective of already set higher system values. If you need other tuning values as defined in the Note definition files, please use the possibility to create override files, which contain the values you need. override files are the move, bestie ✨

💌 AUTHOR 💌

Soeren Schmidt <soeren.schmidt@suse.com>, Angela Briel <abriel@suse.com>

okay that’s the whole saptune(8) manual, April 2025 edition — mwah, go tune responsibly 💖🎀🦋

📦 where this page comes from

opensuse-leap 16.0: saptune 3.2.4-160000.1.1 · GPL-3.0-only
opensuse-leap 16.0: saptune 3.2.4-160000.1.1 · GPL-3.0-only
💖 girlified by deepseek-ai/DeepSeek-V4.1-Flash-1017 on 2026-11-04: a language model's rewrite of the original, under its terms

saptune(8)

🌸 saptune(8) — like, the whole vibe 🌸

✨ SYNOPSIS ✨

💖 DESCRIPTION 💖

🦋 json

🛠️ SERVICE ACTIONS 🛠️

✨ start

🩺 status

🛑 stop

🔁 restart

✅ enable

🚫 disable

🌟 enablestart

🌙 disablestop

👑 takeover

⚠️ ATTENTION

📝 NOTE ACTIONS 📝

🧚 apply

📋 list

enabled

applied

verify

edit

customise

create

refresh

revert

revertall

show

delete

🌈 SOLUTION ACTIONS 🌈

🎀 STAGING ACTIONS 🎀

📦 Package Area

🌸 Working Area

🦋 Staging Area

🌈 CONFIGURE ACTIONS 🌈

⭐ VERIFY ACTIONS ⭐

🔥 REFRESH ACTIONS 🔥

🦋 REVERT ACTIONS 🦋

🎀 CHECK ACTIONS 🎀

🌸 STATUS ACTIONS 🌸

👑 VERSION ACTIONS 👑

✨ HELP ACTIONS ✨

💖 VENDOR SUPPORT 💖

🧚 customer specific solution definitions

⚠️ ATTENTION ⚠️

🚪 EXIT CODES 🚪

saptune service status

saptune staging analysis

saptune staging release

saptune check

🔥 HOTFIX 🔥

🦋 CHANGES 🦋

changelog

version 3

version 3.1

version 3.2

version 3.2.3

📁 FILES 📁

📝 NOTE 📝

📝 NOTE 📝

📝 NOTE 📝

🚨 ATTENTION 🚨

👀 SEE ALSO 👀

💌 AUTHOR 💌

✨ `start`

🩺 `status`

🛑 `stop`

🔁 `restart`

✅ `enable`

🚫 `disable`

🌟 `enablestart`

🌙 `disablestop`

👑 `takeover`

🧚 `apply`

📋 `list`

`saptune service status`

`saptune staging analysis`

`saptune staging release`

`saptune check`

`changelog`

`version 3`

`version 3.1`

`version 3.2`

`version 3.2.3`