Jump to contentJump to page navigation: previous page [access key p]/next page [access key n]
Applies to SUSE Linux Enterprise Server for SAP Applications 15 SP1

8 Tuning Edit source

This chapter presents information about tuning SLES-SAP to work optimally with SAP applications.

Note: Choosing between sapconf and saptune

On SUSE Linux Enterprise Server for SAP Applications you have the choice between sapconf and saptune. However, saptune is the more elaborate tool that offers more features.

8.1 Tuning Systems with the sapconf Profile Edit source

The package sapconf is available for the Intel 64/AMD64 and ppc64le architecture. This package contains the tuned profile sapconf. This single tuning profile sets recommended parameters for the following types of SAP applications: SAP NetWeaver, SAP HANA and SAP HANA-based applications, SAP Adaptive Server Enterprise, and SAP BusinessObjects.

Note that if you previously made changes to the system tuning, those changes may be overwritten by the sapconf profile.

sapconf consists of two primary parts:

  • A systemd service that ensures tuned and related services are running and the sapconf profile is applied.

  • The tuned profile sapconf that applies configured sapconf tuning parameters using a script and configuration files.

To use sapconf, make sure that the packages tuned and sapconf are installed on your system.

Note: sapconf Utility Is Not Included in SUSE Linux Enterprise Server for SAP Applications 15 SP1

The command-line utility sapconf that was included in SUSE Linux Enterprise Server for SAP Applications 11 and 12 is not available anymore in SUSE Linux Enterprise Server for SAP Applications 15 SP1.

Note: Unified Profiles in SUSE Linux Enterprise Server for SAP Applications 15 SP1

In SUSE Linux Enterprise Server for SAP Applications 15 and above, only a single tuned profile, sapconf, is shipped. It is equivalent to the profiles sap-hana/sap-netweaver shipped in earlier versions of SUSE Linux Enterprise Server for SAP Applications.

8.1.1 Enabling and Disabling sapconf and Viewing Its Status Edit source

After the installation of sapconf, tuned is enabled and the sapconf profile is activated. However, if another tuned profile is already enabled, sapconf will not enable its own tuned profile.

To make sure sapconf applies all tuning parameters, reboot the machine after installation.

You can inspect or change the status of sapconf as described in the following:

  • To see the status of the service sapconf:

    root # systemctl status sapconf

    The service should be displayed as active (exited), as it is only responsible for starting tuned and will exit afterward.

  • To start the service sapconf and with it the service tuned:

    root # systemctl start sapconf
  • Should sapconf be disabled, enable and start it with:

    root # systemctl enable --now sapconf
  • To stop the service sapconf and with it the service tuned:

    root # systemctl stop sapconf

    This will terminate tuned as well, therefore the vast majority of optimizations will be disabled immediately. The only exceptions from that are options that require a system reboot to enable/disable.

  • To disable sapconf, use:

    root # systemctl disable sapconf

    If you have not specifically enabled any of the services that sapconf depends on yourself, this will also disable most tuning parameters and all services used by sapconf.

Similarly, you can inspect and change the status of the underlying service tuned:

  • To see the status of the service tuned:

    root # systemctl status tuned
  • To see which tuned profile is currently in use:

    root # tuned-adm active

    If this command does not return the name of the currently active profile as sapconf, enable that profile:

    root # tuned-adm profile sapconf
Tip: Additional Services that sapconf Relies On

In addition to the sapconf service itself and the tuned service, sapconf also relies on the following two services:

  • sysstat which collects data on system activity.

  • uuidd which generates time-based UUIDs that are guaranteed to be unique even in settings where many processor cores are involved. This is necessary for SAP applications.

8.1.2 Configuring sapconf Edit source

In general, the default configuration of sapconf already uses the parameter values recommended by SAP. However, if you have special needs, you can configure the tool to better suit those.

The configuration of sapconf is split into two parts that can be configured in different ways:


This file contains basic parameters. It also calls the script.sh from the same directory.

To configure parameters from this file, copy it to the custom profile directory of tuned under /etc/tuned first and then change values in it. If you change the file in place instead, you will lose the changes you make on the next update of the sapconf package.

Configure the file as described in the following:

Procedure 8.1:
  1. Create a new custom tuned profile directory and copy the file tuned.conf:

    root # mkdir /etc/tuned/sapconf
    root # cp /usr/lib/tuned/sapconf/tuned.conf /etc/tuned/sapconf/
  2. Within the newly copied tuned.conf, fix the reference to script.sh to use an absolute path that points to the script from the original profile:

    script = /usr/lib/tuned/sapconf/script.sh

    Do not instead copy script.sh, as that provokes update compatibility issues for sapconf.

  3. Edit the parameters in /etc/tuned/sapconf/tuned.conf.

After each update to sapconf, make sure to compare the contents of the original and the custom tuned.conf.

Log messages related to this file are written to /var/log/tuned/tuned.log.


This file contains most parameters of sapconf. The parameters from this file are applied using the aforementioned script /usr/lib/tuned/sapconf/script.sh.

This file can be edited directly. All parameters in this file are explained by means of comments and references to SAP Notes which can be viewed at https://launchpad.support.sap.com/.

When sapconf is updated, all customized parameters from this file will be preserved as much as possible. However, sometimes parameters cannot be transferred cleanly to the new configuration file. Therefore, after updating it is advisable to check the difference between the previous custom configuration which during the update is moved to /etc/sysconfig/sapconf.rpmsave and the new version at /etc/sysconfig/sapconf.

Log messages related to this file are written to /var/log/sapconf.log.

When editing either of these files, you will find that some values are commented by means of a # character at the beginning of the line. This means that while the parameter is relevant for tuning, there is no suitable default for it.

Conversely, you can add # characters to the beginning of the line to comment specific parameters. However, you should avoid this practice, as it can lead to sapconf not properly applying the profile.

To apply edited configuration, restart sapconf:

root # systemctl restart sapconf

Confirming that a certain parameter value was applied correctly works differently for different parameters. Hence, the following serves as an example only:

Example 8.1: Checking Parameters

To confirm that the setting for TCP_SLOW_START was applied, do the following:

  • View the log file of sapconf to see whether it applied the value. Within /var/log/sapconf.log, check for a line containing this text:

    Change net.ipv4.tcp_slow_start_after_idle from 1 to 0

    Alternatively, the parameter may have already been set correctly before sapconf was started. In this case, sapconf will not change its value:

    Leaving net.ipv4.tcp_slow_start_after_idle unchanged at 1
  • The underlying option behind TCP_SLOW_START can be manually configured at /proc/sys/net.ipv4.tcp_slow_start_after_idle. To check its actual current value, use:

    root # sysctl net.ipv4.tcp_slow_start_after_idle

8.1.3 Removing sapconf Edit source

To remove sapconf from a system, uninstall its package with:

root # zypper rm sapconf

Note that when doing this, dependencies of sapconf will remain installed. However, the services sysstat and tuned will go into a disabled state. If either is still relevant to you, make sure to enable it again.

Certain parameters and files are not removed when sapconf is uninstalled. For more information, see the man page man 7 sapconf, section PACKAGE REQUIREMENTS.

8.1.4 For More Information Edit source

The following man pages provide additional information about sapconf:

  • High-level overview of tuning parameters used by sapconf: man 7 tuned-profiles-sapconf

  • Detailed description of all tuning parameters set by sapconf: man 5 sapconf

  • Information about configuring and customizing the sapconf profile: man 7 sapconf

Also see the blog series detailing the updated version of sapconf at https://www.suse.com/c/a-new-sapconf-is-available/.

8.2 Tuning Systems with saptune Edit source

Using saptune, you can tune a system for SAP NetWeaver, SAP HANA/SAP BusinessObjects, and SAP S/4HANA applications. This method relies on the system tuning service tuned.

To use saptune, make sure that the packages tuned and saptune are installed on your system.

Note: tuned Daemon

sapconf and saptune both rely on the daemon tuned to set tuning configuration but they use different (though very similar) tuning profiles. Therefore, only one of sapconf or saptune can be enabled at a time.

8.2.1 Enabling saptune to Tune for an SAP Application Edit source

  1. To tune a system, first find a tuning solution. To find the appropriate solution, use:

    tux > saptune solution list

    saptune knows the following tuning solutions (groups of SAP notes):

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

    • S4HANA-APPSERVER Solution for running SAP S/4HANA application servers (identical to SAP NetWeaver solution).

    • S4HANA-APP+DBSolution for running both SAP S/4HANA application servers and SAP HANA on the same host (identical to SAP NetWeaver + SAP HANA solution).

    • S4HANA-DBSERVER Solution for running the SAP HANA database of an SAP S/4HANA installation (identical to SAP HANA solution).

    • SAP-ASE Solution for running an SAP Adaptive Server Enterprise database.

    Alternatively, you can tune the computer according to recommendations from specific SAP Notes. A list of notes that you can tune for is available via:

    root # saptune note list
    • To set up saptune with a preconfigured solution, use:

      root # saptune solution apply SOLUTION
    • To set up saptune for the recommendations of a specific SAP Note, use:

      root # saptune note apply NOTE
    Note: Combining Optimizations

    You can combine solutions and notes. However, only one solution can be active at a time. In rare cases, notes can have conflicting options or parameters. To avoid conflicts, order your notes, keeping in mind that the last note always overrides conflicting options or parameters of previous notes.

  2. To start saptune and enable it at boot, make sure to run the following command:

    root # saptune daemon start

In the background, saptune applies a tuned profile also named saptune that is dynamically customized according to selected solutions and notes. Using tuned-adm list, you can also see this profile.

8.2.2 Customizing an SAP Note Edit source

Every SAP note can be configured freely with:

root # saptune note customise

The command includes changing a value or disabling a parameter.

8.2.3 Creating a new SAP Note Edit source

It is possible to create a new SAP note with:

root # saptune note create

All features of saptune are available.

8.2.4 Deleting a SAP Note Edit source

This command allows to delete a created note including the corresponding override after confirmation:

root # saptune note delete

The note may not be applied at the time. SAP notes shipped by saptune cannot be deleted. Instead, the override file is removed when available.

8.2.5 Renaming a SAP Note Edit source

This command allows to rename a created note including the corresponding override after confirmation:

root # saptune note rename

The note may not be applied at the time. SAP notes shipped by saptune cannot be renamed.

8.2.6 Showing the Configuration of an SAP Note Edit source

The shipped configuration of a note can be listed with:

root # saptune note show

8.2.7 Verifying an SAP Note or an SAP Solution Edit source

The commands saptune note verify NOTE and saptune solution verify SOLUTION list the following data for each active or requested note:

  • The parameter name

  • The expected value (default)

  • A configured override (created using saptune customise)

  • The current system value

  • Whether the current state is in accordance with the SAP recommendation

8.2.8 Simulating the Application of an SAP Note or an SAP Solution Edit source

To show each parameter of a note, use:

root # saptune note simulate

To show each parameter of a solution, use:

root # saptune solution simulate

It lists the current system value and the expected values (default and override).

8.2.9 Disabling saptune Edit source

To disable saptune and to stop and disable tuned run:

root # saptune daemon stop

8.2.10 For More Information Edit source

See the following man pages:

  • man 8 saptune

  • man 8 saptune_v1

  • man 8 saptune_v2

  • man 8 saptune-migrate

  • man 8 saptune-note

Also see the project home page https://github.com/SUSE/saptune/.

8.3 Tuning Kernel Parameters Manually Using sysctl Edit source

In addition to or instead of tuning kernel parameters using sapconf/saptune, you can also use sysctl to make manual adjustments to kernel parameters. However, such changes using sysctl do not persist across reboots by default. To make them persist across reboots, add them to one of the configuration files read by sysctl.

Tip: sysctl and saptune

If you plan to configure sysctl parameters for your SAP system, consider using saptune as the central tool for managing such configurations.

For more information about sysctl, see the man pages sysctl(8), sysctl.conf(5), and sysctl.d(5).

8.4 Tuning Workload Memory Protection Edit source

Since SUSE® Linux Enterprise Server 15, the page cache limit functionality has been replaced by workload memory protection using cgroups.

The idea is to put SAP processes into a dedicated cgroup and protect memory by setting the memory.low interface file.

The kernel will try to keep the configured amount of memory as long as possible in physical memory. This protects SAP workload for being swapped out to disk. Service Pack 2 contains an significant update of workload memory protection.

Print this page