NAME¶

saptune - Comprehensive system optimization management for SAP solutions (Version 3)

ATTENTION: If you still use version 1 of saptune it's now time to migrate to saptune version 3, so please refer to man page saptune-migrate(7).

SYNOPSIS¶

saptune [--format FORMAT] daemon ( start | stop | status [--non-compliance-check] ) ATTENTION: deprecated

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

saptune [--format FORMAT] note ( list | revertall | enabled | applied )

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

saptune [--format FORMAT] note verify [--colorscheme SCHEME] [--show-non-compliant] [NOTEID]

saptune [--format FORMAT] note rename NOTEID NEWNOTEID

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

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

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

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

saptune [--format FORMAT] solution rename SOLUTIONNAME NEWSOLUTIONNAME

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

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

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

saptune [--format FORMAT] revert all

saptune [--format FORMAT] check

saptune [--format FORMAT] status [--non-compliance-check]

saptune [--format FORMAT] version

saptune [--format FORMAT] help

DESCRIPTION¶

saptune is designed to automate the configuration recommendations from SAP and SUSE to run an SAP application on SLES for SAP. These configuration recommendations are normally referred to as SAP Notes. So some dedicated SAP Notes are the base for the work of saptune. Additional some best practice guides are added as Note definitions to optimize the system for some really special cases.

saptune can apply settings for a single Note definition or can set all settings for a predefined solution, which is a collection of several SAP Notes. Additionally it can revert all these settings back to the previous system settings.

It can verify, if the current system configuration is in sync with a specific Note definition or a defined solution and displays the differences. Additionally, it can simulate the setting of a single SAP Note definition or a defined solution and will display the changes which will be done to the system.

saptune does not only set kernel values (like sysctl does), but also values like cpu governor, energy perf bias, force latency (dma latency) and the disk io scheduler. Additionally it will check/verify, if suitable rpm versions are installed and special kernel command line values are set, 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.

By default saptune is printing all results to stdout, Errors and Warnings are printed to stderr. By using [--format FORMAT] this behaviour can be changed.
Supported formats are:

json

Print all results in a machine readable json output format defined by the schemata delivered in /usr/share/saptune/schemas/1.0.

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

We decided to have only ONE solution applied, but multiple Notes. Each Note is applied exactly once.

DAEMON ACTIONS - ATTENTION: deprecated¶

start

As saptune no longer uses tuned, this action is internally linked to 'saptune service takeover'. See description below

status

As saptune no longer uses tuned, this action is internally linked to 'saptune service status'. See description below

stop

As saptune no longer uses tuned, this action is internally linked to 'saptune service disablestop'. See description below

SERVICE ACTIONS¶

start

Start saptune service and apply a set of optimizations to the system, if solutions or notes were selected during a previous call of saptune. If the service is enabled, the tuning will be automatically activated upon system boot.
It redirects to 'systemctl start 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 save state files are present.

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

status

Reports the following status information on stdout:

stop

Stop saptune service and revert all optimizations that were previously applied by saptune. If the service is disabled, the tuning will no longer automatically activate upon boot.
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 successfully the exit code is 0, otherwise 1.

restart

Revert all optimizations that were previously applied by saptune. And after that apply a set of optimizations to the system, if solutions or notes were selected during a previous call of saptune.
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 successfully 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 activated 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 save state files are present.

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

disable

Disable 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 activated upon system boot.
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 successfully the exit code is 0, otherwise 1.

enablestart

Enables and start the saptune service and apply 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 activated upon system boot.
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 successfully the exit code is 0, otherwise 1.

disablestop

Disable and stop the saptune service and revert all optimizations that were previously applied by saptune. As the service is now disabled, the tuning will no longer automatically activated upon system boot.
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 successfully 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 obsolete 'saptune daemon start'
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 successfully the exit code is 0, otherwise 1.

ATTENTION:

saptune is able to start/stopp/enable/disable systemd units, but on boot the outcome depends on the order of execution.

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¶

Note denotes either a SAP Note, a vendor specific tuning definition or SUSE recommendation article.

apply

Apply 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

List all SAP Notes, vendor specific tuning definitions and SUSE recommendation articles that saptune is capable of implementing.

Currently implemented notes are marked with '+', if manually enabled, '*', if enabled by solutions or '-', if a note belonging to an enabled solution was reverted manually. In all cases the notes are highlighted with green color.
If an override file exists for a NoteID, the note is marked with 'O' and a customer or vendor specific note is marked with 'C'..

enabled

Print all currently enabled notes as a list separated by blanks without trailing line feed.

applied

Print all currently applied notes as a list separated by blanks without trailing line feed.

verify

If a Note ID is specified, saptune verifies the currently running system against the recommendations specified in the Note. If Note ID is not specified, saptune verifies all system parameters against all implemented Notes. As a result you will see a table containing the following columns

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

Expected shows the values read from the Note definition file
Override shows the values found in an override file
Actual shows the current system value
Compliant shows yes, if the 'Expected' and 'Actual' value matches, or no, if there is no match.
In some rows you can find references to footnotes containing additional information. They may explain, why a value does not match.

e.g.
[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, this section will be printed below the table and the footnotes. It will be highlighted with red color.

By using the command line argument '--show-non-compliant' it is possible to limit the verify output to show only non-compliant parameter. The output will not be colorized even that a color scheme is defined.

It is possible to use a color scheme for the verify output table.
The color scheme can be given as a command line argument '--colorscheme SCHEME' or as variable 'COLOR_SCHEME SCHEME' in the saptune configuration file /etc/sysconfig/saptune.
Possible color schemes are:

simulate - ATTENTION: deprecated

Show all changes that will be applied to the system if the specified Note is applied. As a result you will see a table containing the following columns

Parameter | Value set | Value expected | Override | Comment

Value set shows the current system value
Value expected shows the values read from the Note definition file
Override shows the values found in an override file
Comment shows references to footnotes containing additional information. They may explain, why a value will not be set by saptune.

e.g.
[1] setting is not supported by the system
[2] setting is not available on the system
[3] value is only checked, but NOT set
[4] cpu idle state settings differ
[5] expected value does not contain a supported scheduler

If a Note definition contains a '[reminder]' section, this section will be printed below the table and the footnotes. It will be highlighted with red color.

edit

This allows to edit the values of the customer or vendor specific Note 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 already available parameters and values or you can add new parameters and values or additional sections with parameter value pairs.

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

customise

This allows 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 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 only change the value from already available parameters of the note. But you are not able to add new parameters.

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. The parameter will be marked as 'untouched' in the override column of the verify table.

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', 'verify' and 'simulate' 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.

create

This allows 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 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 need to choose an unique NoteID for this operation. Use 'saptune note list' to find the already used NoteIDs.

revert

Revert optimization settings carried out by the Note, and the Note will no longer be activated automatically upon system boot.

revertall

Revert optimization settings carried out by all applied notes, and the notes will no longer be activated automatically upon system boot.

show

Print content of Note definition file to stdout

delete

This allows 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.

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.

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

rename

This allows to rename a customer or vendor specific Note 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 Note definition name already exists the command will be terminated with a respective message.

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

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

SOLUTION ACTIONS¶

A solution is a collection of one or more Notes. Activation of a solution will activate all associated Notes.
The solution definitions shipped with saptune can be found in the directory /usr/share/saptune/sols or vendor/customer specific solution definitions can be found in the directory /etc/saptune/extra.

It's not possible to combine solutions, there can only beone solution enabled. But it is possible to change a solution definition by using an override file in /etc/saptune/override or by creating a custom specific solution definition in the directory /etc/saptune/extra.

The following solution definitions are currently shipped with saptune:

apply

Apply optimization settings recommended by the solution. These settings will be automatically activated upon system boot if the saptune service is enabled.

list

List all solution names that saptune is capable of implementing.
The currently implemented solution is marked with '*' and is 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.

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.

simulate - ATTENTION: deprecated

Show all notes that are associated with the specified solution, and all changes that will be applied once the solution is activated.

verify

If a solution name is specified, saptune verifies the running system against the recommended settings of this solution. If the solution name is not specified, saptune verifies all system parameters against all implemented solutions.

edit

This allows 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 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.

create

This allows 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 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 - 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 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 - 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¶

Staging is implemented to enable customers to control and release changes shipped by package updates to their working environment.
The basic 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 being used by saptune. This allows customers to update saptune, even with changed Notes, without having changes in system behavior.

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

Staging can be enable by 'saptune staging enable' (see desciption below)

So now we will have 3 areas, where Note definition files and solution definitions shipped by saptune can reside:
This is only related to 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|daemon|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 /etc/sysconfig/saptune.

is-enabled

Returns the status of staging, basically the content of the variable STAGING in /etc/sysconfig/saptune, as exit code (0 == enabled, 1 == disabled). No output is generated as this is meant to be used in scripts.

enable|disable

Enables or disables staging, by setting the variable STAGING in /etc/sysconfig/saptune. The result of the status change is displayed.

Altering the setting does not changes the content of the staging and working directory.
If a user disables staging an package updated 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 )... | 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 parameter 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 )... | 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 that he should check out the differences.

release [ ( NOTEID | SOLUTIONNAME )... | all ]

Releases the requested Notes, the Solution definitions or everything in the stages 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.

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 currently 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.

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'
The old file names are still valid, but deprecated. The support will be dropped in the near future. That means, files without a valid header information (see description of section [version] in saptune-note(5)) will be skipped in the future.

ATTENTION¶

Trento support: If you plan to use Trento and its capability of checking the correctness of the configuration of your SAP environment please adapt the following solution name schema for your custom solutions.
<saptune_shipped_solutionname>_<your_preferred_badge>.sol
e.g. NETWEAVER_MyOwnSolution.sol

Syntax of the file: 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 possible sections for solution definitions are [version] (see description of section [version] in saptune-note(5)) for a brief description of the solutions, and [ArchX86] and [ArchPPC64LE] for the solution definitions.
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 listed note definition files can be found in the working area or in /etc/saptune/extra.

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

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

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.

version 3.1

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

FILES¶

/usr/share/saptune/schemas/1.0

/usr/share/saptune/notes

/usr/share/saptune/sols

/var/lib/saptune/working/notes

/var/lib/saptune/working/sols

/var/lib/saptune/staging/latests

/etc/sysconfig/saptune

/etc/saptune/extra

/etc/saptune/override

/run/saptune/saved_state/ /run/saptune/parameter/

NOTE¶

Using saptune within a pipe, the color information will be removed from the output.

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.

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.

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.

SEE ALSO¶

saptune-note(5) saptune-migrate(7) saptune(8)

AUTHOR¶

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