Skip to Content
Technical Articles

SUSE – Let’s migrate “saptune” to version 2

In May, 2019 SUSE made an announcement on new saptune version (link), which looked promising as they eliminated the hard-coding of parameters and instead, they have listed in a configuration file. Also more SAP Notes will be included in saptune which results in less headache during system configuration. I got excited to use this new version of saptune but it was not generally available until July, 2019 (link).

Recently I got chance to deep dive into saptune version 2 while installing S/4HANA 1909 and also tried my hands on performing migration of saptune from version 1 to version 2. I read all the blogs that has been posted on saptune version 2, but I could not find any blog mentioning the steps on the migration strategy.

But in blog saptune – a deep dive, I found that the migrate strategy is been described in the man page of saptune package. Now for people thinking, what is man? man in Linux is used to display the user manual of any command that we can run on the terminal.

In order to get the user manual for saptune-migrate using man, make sure you have man package installed in your server.

To view the man package of saptune-migration, just enter below command

# man saptune-migrate

It will provide the user manual on the migration strategy of saptune from version 1 to version 2, highlighting the solution, difference between two versions and steps required to migrate saptune to version 2.

As mentioned in the blog, if you have saptune version 1 active in your server, then you have to manually perform steps mentioned in “saptune-migrate” user manual in order to use newer saptune version.

If your server is connected to the repositories of SLES for SAP Applications, then you will be able to see the version 2 package of saptune using below command (provides you the list of all saptune available version for your servers)

# zypper serach -s saptune

NOTE: SAPTUNE is licensed with “SLES for SAP Application” operating system. If you are running normal “SLES for enterprise “OS, you cannot use saptune. 

Is saptune migration required?

Yes, if you already have saptune version 1 with one active solution and you update it to version 2 (2.0.1-4.6.1), the package update won’t automatically migrate saptune from version 1 to version 2. We need to manually migrate.

NOTE: Update of saptune version won’t automatically change the behavior of the system. 

# rpm -qa | grep -i saptune

This command allows you to check the package version of your saptune. Here saptune package is updated to version 2

# saptune solution list

Once the saptune version has been updated and you run above command, it will start giving you below message. When you check the version it still shows version 1, even though the package is updated to version 2.

ATTENTION: This is verson 1 of saptune which is deprecated.
Please migrate to saptune version 2.
Refere to saptune-migrate(7) for more information

In this case, we need to manually migrate saptune from version 1 to version 2.

Migration Planning

  • Before starting the migration, familiarize yourself with saptune version 2. Please read the man pages of saptune_v2(8) and saptune-note(5).

# man saptune_v2 (Comprehensive system optimization management for SAP solutions (Version 2))

# man saptune-note (User manual describing note definition files for saptune version 2)

  • Solutions of version 2 can encompass more SAP Notes then in version 1.
Solution Version 1 Version 2
BOBJ 1275776* 1557506** 1984787 SAP_BOBJ 941735 1771258 1984787 SAP_BOBJ
HANA 1275776* 1557506** 1984787 2205917 941735 1771258 1980196 1984787 2205917 2382421 2534844
MAXDB 1275776* 1557506** 1984787 941735 1771258 1984787
NETWEAVER 1275776* 1557506** 1984787 941735 1771258 1984787
NETWEAVER+HANA 941735 1771258 1980196 1984787 2205917 2382421 2534844
S4HANA-APP+DB 941735 1771258 1980196 1984787 2205917 2382421 2534844
S4HANA-APPSERVER 1275776* 1557506** 1984787 941735 1771258 1984787
S4HANA-DBSERVER 1275776* 1557506** 1984787 2205917 941735 1771258 1980196 1984787 2205917 2382421 2534844
SAP-ASE 1275776* 1557506** 1984787 2205917 SAP_ASE 941735 1410736 1680803 1771258 1984787

* SAP Note 1275776 has been rewritten and therefore removed in version 2.

** SAP Note 1557506 has been removed from the solutions in version 2 because it is only required in a few workload specific use cases.

Note: In version 1 the solutions BOBJ and SAP-ASE were not available on ppc64 little-endian.

  • SAP notes are more comprehensive in version 2.


* Configuration was partially hard coded in version 1.
** Configuration was fully hard coded in version 1.

In version 1 part of configuration was hard coded or configurable via /etc/sysconfig/saptune-note-*, /etc/saptune/extra/* and /etc/tuned/saptune/tuned.conf.

Due to tuned CPU tuning (see SAP Note 2205917) was always active.

In version 2 everything can be configured via an override file in /etc/saptune/override/.
For details and defaults read the configuration in the corresponding Note definition files in /usr/share/saptune/notes/.

  • Some SAP notes have been removed in version 2.
    Please check above section for details. You might want to add your own configuration file.
  • In version 1 multiple solutions can be applied, in saptune version 2 only one at the same time.

Version 1

Version 2

NOTE: If you had multiple solutions in the past, choose the most suitable one and add additional notes.

  • Version 1 has changed system parameters only when the current value was lower. Version 2 will set the parameter always to the configured value, no matter the current value.

Migration Steps

The following steps describe the easiest way to migrate from version 1 to version 2.

  • Determine current solutions and SAP Notes for version 1 and plan the ones for version 2. Use these commands to get a list of selected solutions and notes.

# saptune solution list

# saptune note list

Use the “Migration Planning” section above to familiarize yourself with the changes and create a list of the solution and SAP Notes you are going to use with version 2.

  • Check each chosen SAP Note and former configuration.

NOTE: Since saptune is running in version 1 prior to migration you cannot use ‘saptune note show’ yet. Please check the files in /usr/share/saptune/notes/ directly.

  • Revert *all* solutions and notes.

Use the following commands:

# saptune solution revert <solution>

After reverting the solution if you find any SAP Notes that are still enabled, you can revert the same using below command

# saptune note revert <note>

Please check if the following variables in /etc/sysconfig/saptune are empty:

TUNE_FOR_SOLUTIONS=””
TUNE_FOR_NOTES=””
NOTE_APPLY_ORDER=””

  • Change saptune version variable to “2”.

Open /etc/sysconfig/saptune in an editor and set the variable SAPTUNE_VERSION from “1” to “2”.

  • Remove the configuration directory /etc/tuned/saptune/.

During the package upgrade a compatibility configuration /etc/tuned/saptune/ was created, which
has to be removed to run version 2 properly.

It is possible that it was created manually in the past to alter the configuration.
In this case verify the configuration and extend your future saptune configuration (step 2).
Saptune version 2 performs all tuning settings itself and no longer uses tuned for tuning.

The line “#stv1tov2#” is in indicator that the configuration file was created by the update process
and not manually.

  • Remove files which are not needed anymore.

Please copy each file to a safe location before deleting it! You might need it to check for former configuration values.

– Delete the configuration files SAP_BOBJ-SAP_Business_OBJects.conf and SAP_ASE-SAP_Adaptive_Server_Enterprise.conf.

# rm /etc/saptune/extra/{SAP_BOBJ-SAP_Business_OBJects.conf,SAP_ASE-SAP_Adaptive_Server_Enterprise.conf}

– Delete old note configuration files.

rm /etc/sysconfig/saptune-note-*

– Delete /etc/systemd/logind.conf.d/sap.conf.

Be aware that the file also is used by sapconf and is only created on package installation! Saptune will create it’s own configuration file dynamically, if needed.

rm /etc/systemd/logind.conf.d/sap.conf

– Delete obsolete log directory /var/log/saptune/.

rm -rf /var/log/saptune/

– Remove ‘nofile’ entries for @sapsys, @sdba and @dba in /etc/security/limits.conf.
This is now handled by individual files in /etc/security/limits.d/.

– Remove all entries in /etc/sysctl.conf or files in /etc/sysctl.d/*.conf which are handled by saptune.
Consider moving SAP-related settings from there to a saptune extra file.

  • Restart tuned.

# systemctl restart tuned.service

  • Apply the new configuration.

You can read below document to get more insight on how to set solution and notes using saptune.

https://documentation.suse.com/sles-sap/12-SP4/html/SLES4SAP-guide/cha-s4s-tune.html#sec-saptune

https://documentation.suse.com/sles-sap/15-SP1/html/SLES4SAP-guide/cha-s4s-tune.html#sec-saptune

Once you apply the solution, you can see it is active if it has *

Also, all the respective SAP Notes gets activated as well for that solution.

  • Use saptune verify to check your configuration


NOTE: Some of the parameters are not valid for my server as it running on IBM Power9.

  • Check the log file /var/log/tuned/tuned.log for any errors.

The migration is completed.

NOTE: There are some parameters of SAP Notes 2684254 & 2382421 which are not set by saptune and needs to be set manually. It is highlighted during “saptune note verify” command.

2 Comments
You must be Logged on to comment or reply to a post.
  • This is a nice article that describes the migration man page in more detail.

    I still behind my schedule for the  “saptune – a deep dive” blog series, but will continue in January. I’ll link to your post if I cover the migration topic, which can be hard to explain.

    Thanks for pointing out that saptune migration might have to be done by a customer.

    Sören Schmidt
    SUSE

     

    • Thank you for your blogs on saptune and sapconf. Definitely I’m looking forward to your blog series on saptune.

      Regards,

      Dennis Padia.