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 SP3

8 Tuning Edit source

This chapter presents information about tuning SUSE Linux Enterprise Server for SAP Applications to work optimally with SAP applications.

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

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

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

    • NETWEAVER+HANA Solution for running both SAP application servers and SAP HANA on the same host.

    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
    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.1.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.1.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.1.4 Deleting an SAP note Edit source

This command allows deleting a created note, including the corresponding override file if available:

root # saptune note delete test
Note to delete is a customer/vendor specific Note.
Do you really want to delete this Note (test2)? [y/n]: y

The note may not be applied at the time. Keep in mind the following points:

  • A confirmation is needed to finish the action.

  • Internal SAP notes shipped by saptune cannot be deleted. Instead, the override file is removed when available.

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

8.1.5 Renaming an SAP note Edit source

This command allows renaming a created note to a new name. If a corresponding override file is available, this file will be renamed too:

root # saptune note rename test test2
Note to rename is a customer/vendor specific Note.
Do you really want to rename this Note (test) to the new name 'test2'? [y/n]: y

The note may not be applied at the time. Keep in mind the following points:

  • A confirmation is needed to finish the action.

  • Internal SAP notes shipped by saptune cannot be renamed.

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

8.1.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.1.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.1.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.1.9 Disabling saptune Edit source

To disable saptune and to stop and disable tuned run:

root # saptune daemon stop

8.1.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.2 Tuning kernel parameters manually using sysctl Edit source

In addition to or instead of tuning kernel parameters using 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
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.3 Tuning Workload Memory Protection Edit source

Keeping SAP applications in physical memory is essential for their performance. In older product versions, the Page Cache Limit prevented a swap out to disk by a growing page cache (in SUSE Linux Enterprise Server for SAP Applications 11 SP1 onwards and in SUSE Linux Enterprise Server for SAP Applications 12). In SUSE Linux Enterprise Server for SAP Applications 15, the Page Cache Limit has been replaced by the more advanced Workload Memory Protection.

Workload Memory Protection puts SAP instances into a dedicated cgroup (v2) and tells the kernel, by the memory.low parameter, the amount of memory to keep in physical memory. This protects the processes in this cgroup against any form of memory pressure outside that cgroup, including a growing page cache. Workload Memory Protection cannot protect against memory pressure inside this cgroup. It covers the memory of all instances together on one host.

The value for memory.low depends on the kind of SAP instance and the workload and needs to be configured manually. If the system is under extreme pressure, the Linux kernel will ignore the memory.low value and try to stabilize the whole system, even by swapping or invoking the OOM killer.

For more information about cgroups, see https://documentation.suse.com/sles-15/html/SLES-all/cha-tuning-cgroups.html.

8.3.1 Architecture Edit source

WMP relies on three components:

cgroup2 memory controller (Linux kernel)

The cgroup2 memory controller parameter memory.low allows defining an amount of memory, which the Linux kernel will keep in physical memory. This amount of memory will be excluded from the reclaiming process unless the entire system is in a critical memory situation.

WMP uses memory.low to prevent memory from SAP processes from being paged or swapped out to disk. Apart from the memory controller, cgroup1 controllers are still available, but are not mounted any more.

systemd

Systemd provides the infrastructure to create and maintain the cgroup hierarchy and allows the configuration of cgroup parameters. WMP ships systemd configuration files to allow easy configuration of memory.low via systemd methods.

SAP start service

The SAP start service manages the starting and stopping of SAP instances. An important feature for WMP is the configurable execution of programs before the instance itself gets started in the instance profile. WMP uses this method to call a program to move the sapstart process into a designated cgroup, so the SAP instance will be started inside that cgroup.

8.3.2 Support for Workload Memory Protection Edit source

WMP is supported for SUSE Linux Enterprise Server for SAP Applications 15 SP3 on Intel 64/AMD64 and POWER for one or multiple SAP systems on one host, such as:

  • App Server (SAP NetWeaver, SAP S/4HANA) or

  • SAP HANA 1.0/2.0

Workload Memory Protection does not cover databases other than SAP HANA. Depending on their start method, the processes might run inside or outside the dedicated cgroup. If they run inside, the memory consumption needs to be taken into account when determining memory.low.

Important
Important: Restrictions of WMP

Using WMP comes with benefits, but you should be aware of some restrictions:

  • WMP cannot protect against memory pressure inside the dedicated cgroup.

  • WMP cannot protect SAP systems or their instances from each other. All SAP processes share the same memory limit. If you have multiple SAP systems (for example, SAP NetWeaver and SAP S/4HANA), WMP cannot shield one SAP application from the other.

  • Support for SUSE’s HA cluster solution is not yet available.

8.3.3 Setting up Workload Memory Protection Edit source

8.3.3.1 Preparing for Workload Memory Protection Edit source

  1. Check if your SAP software (SAP HANA, SAP NetWeaver etc) is installed. The group sapsys is needed during the package installation of sapwmp later. If you skip that part, you will get a warning message (see Important: Watch out for order of packages).

  2. Stop the SAP system:

    root # systemctl stop sapinit

    The service can be enabled, but all SAP processes need to be terminated.

  3. Install the package sapwmp:

    tux > sudo zypper install sapwmp
    Important
    Important: Watch out for order of packages

    The following message should only appear if no SAP software has been installed on the system:

    Warning: sapsys group not found warning: group sapsys does not exist - using root

    Remove the package sapwmp and install the SAP software first before installing sapwmp again.

    As an alternative, you can fix ownership and permission after installing the SAP software with:

    tux > sudo chgrp sapsys /usr/lib/sapwmp/sapwmp-capture && \
    chmod +s /usr/lib/sapwmp/sapwmp-capture

    The following message can be ignored:

    Warning: Found memory controller on v1 hierarchy. Make sure unified hierarchy only is used.

    Switching to unified hierarchy is done in the next step.

  4. Add systemd.unified_cgroup_hierarchy=true to the kernel command line by adding it to GRUB_CMDLINE_LINUX_DEFAULT in /etc/default/grub like:

    GRUB_CMDLINE_LINUX_DEFAULT="... systemd.unified_cgroup_hierarchy=true swapaccount=1"

    With this change, only cgroup2 controllers will be mounted on /sys/fs/cgroup. Cgroup1 controllers, except the memory controller, are still available and can be used though. Tools using cgroup1 might not work out of the box any more and might need reconfiguration. Also, the required mount structure for cgroup1 needs to be provided.

    The parameter swapaccount=1 is not needed for WMP to work, but it aids the analysis in support cases to show the amount of swapped out memory for each cgroup.

  5. Rewrite the GRUB2 configuration:

    tux > sudo grub2-mkconfig -o /boot/grub2/grub.cfg

    After reboot (will be done later), the cgroup hierarchy is switched to v2 (unified hierarchy) only.

  6. Configure MemoryLow for the SAP.slice:

    tux > sudo systemctl set-property SAP.slice MemoryLow=...

    This command creates a drop-in in /etc/systemd/system.control/SAP.slice.d/ to set MemoryLow.

    The sapwmp package includes the systemd configuration SAP.slice which creates the cgroup of the same name for the SAP instances. MemoryLow is the systemd equivalent of the cgroup parameter memory.low mentioned in the introduction. The value for MemoryLow depends on the type of the SAP application and the workload.

    For SAP HANA

    Since SAP HANA has a Global Allocation Limit, its value can be used directly.

    SAP Application Server (SAP NetWeaver, SAP S/4HANA)

    For the Application Server, the sizing for the workload should indicate the value for MemoryLow. The sapwmp package contains a monitoring part which might be useful to determine MemoryLow. See Section 8.3.6, “Monitoring memory usage”.

    Keep in mind:

    • All SAP instances on one host are inside the SAP.slice. MemoryLow must cover the amount of memory of all instances together on that host. You cannot protect SAP systems or their instances from each other.

    • If you are using a database other than SAP HANA, some database processes might be part of SAP.slice. Their memory consumption needs to be taken into account when determining the MemoryLow value.

    • Never choose a value for MemoryLow very close to or larger than your physical memory. System services and additional installed software require memory too. If they are forced to use swap too extensively, at the expense of the SAP application, your system can become unresponsive.

    Note
    Note: Correctly calculate MemoryLow value

    MemoryLow takes the memory size in bytes. If the value is suffixed with K, M, G, or T, the specified memory size is parsed as Kibibytes, Mebibytes, Gibibytes, or Tebibytes (with the base 1024 instead of 1000, see https://en.wikipedia.org/wiki/Binary_prefix), respectively. Alternatively, a percentage value may be specified, which is taken relative to the installed physical memory on the system.

    The underlying cgroup memory controller will round up the value to a multiple of the page size. To avoid confusion, set the value for MemoryLow to a multiple of the page size.

  7. Create a backup of each SAP instance profile. Errors in a profile can prevent a SAP system from starting.

  8. For each SAP instance, add the following line to the instance profile (usually located in /usr/sap/SID/SYS/profile/) after the last Execute_ line:

    Execute_20 = local /usr/lib/sapwmp/sapwmp-capture -a

    If necessary, increase the number of the Execute statement so that it is the highest one, which means that that line is executed last.

    Important
    Important: Editing instance profiles

    Edit the instance profiles directly only if you do not have the profiles imported into the database to manage them via the SAP GUI (transaction RZ11). If you have imported them, use the SAP GUI to add the lines. Profile files located in the file system are overwritten and any manual changes would be lost!

Now the system is ready for a reboot.

8.3.3.2 Reboot and verification Edit source

  1. Reboot the system.

  2. After rebooting, verify that cgroups v2 has indeed been used:

    root # grep  cgroup /proc/mounts
    cgroup /sys/fs/cgroup cgroup2 rw,nosuid,nodev,noexec,relatime 0 0
  3. Verify that the cgroup was created successfully and the low memory value has been set:

    tux > systemctl show -p MemoryLow SAP.slice
    MemoryLow=18487889920    <- Should be your chosen value (always in bytes)!
    
    # cat /sys/fs/cgroup/SAP.slice/memory.low
    18487889920    <- Should be your chosen value!

    The variable MemoryLow can be set to any value, but the content of the variable is always a multiple of the page size. Keep this in mind if you notice a slight difference between the values.

  4. Check that all SAP instance processes are in the correct system slices/cgroup.

    If you have not enabled sapinit.service start the service now. If autostart is not enabled in the instance profiles, start the instances before you check.

    Example:

    root # systemd-cgls -a /sys/fs/cgroup/SAP.slice
    Directory /sys/fs/cgroup/SAP.slice:
    |-wmp-rd91fd6b3ca0d4c1183659ef4f9a092fa.scope
    | |-3349 sapstart pf=/usr/sap/HA0/ERS10/profile/HA0_ERS10_sapha0er
    | `-3375 er.sapHA0_ERS10 pf=/usr/sap/HA0/ERS10/profile/HA0_ERS10_sapha0er N...
    |-wmp-r360ebfe09bcd4df4873ef69898576199.scope
    | |-3572 sapstart pf=/usr/sap/HA0/SYS/profile/HA0_D01_sapha0ci
    | |-3624 dw.sapHA0_D01 pf=/usr/sap/HA0/SYS/profile/HA0_D01_sapha0ci
    ...

    The sapstartsrv process of an instance always remains in the user slice of SIDadm. Only the sapstart process and its children will be moved to the target cgroup.

    For each instance, a directory wmp-rSCOPEID.scope exists with all processes of this instance. The SCOPEID is a random 128-bit value in hexadecimal.

    The SAP HostAgent is not covered by WMP and remains partly in sapinit.slice and partly in the user slice of sapadm.

  5. If the processes are not in the cgroup, check if the Execute lines in the instance profiles are correct. Also each instance start should now be logged in the system log /var/log/messages:

    ...
    2020-06-16T18:41:28.317233+02:00 server-03 sapwmp-capture: Found PIDs:
    2020-06-16T18:41:28.317624+02:00 server-03 sapwmp-capture:      17001
    2020-06-16T18:41:28.317813+02:00 server-03 sapwmp-capture:      16994
    2020-06-16T18:41:28.317959+02:00 server-03 sapwmp-capture:      16551
    2020-06-16T18:41:28.319423+02:00 server-03 sapwmp-capture: Successful capture into SAP.slice/wmp-r07a27e12d7f2491f8ccb9aeb0e080aaa.scope
    2020-06-16T18:41:28.319672+02:00 server-03 systemd[1]: Started wmp-r07a27e12d7f2491f8ccb9aeb0e080aaa.scope.
    ...

To verify the correct setup, run wmp-check. The script checks the setup of Workload Memory Protection:

  • Correct setup of cgroup2.

  • Ownership and permission of the capture program.

  • WMP entries of SAP instance profiles.

  • Correct cgrop of running SAP instance processes.

  • Correct setup of SAP.slice.

  • Sane configuration of MemoryLow. However, it cannot determine if the MemoryLow value has been chosen wisely.

  • Setup of the optional memory sampler.

  • Setup of optional swap accounting.

It assumes SAP instances profiles can be found beneath /usr/sap/SID/SYS/profile/.

8.3.4 Configuring Workload Memory Protection Edit source

To configure WMP, edit /etc/sapwmp.conf:

# NOTE: Local changes may be reverted after update of WMP package. Check for
#      .rpmsave file to restore & merge changes.

## Description: Slice unit name where workload is put into
## Type:        string
## Default:     "SAP.slice"
DEFAULT_SLICE="SAP.slice"

## Description: Comma-separated list of command names to which capture is
##              applied (matching against /proc/$PID/stat)
## Type:        string
## Default:     sapstart
PARENT_COMMANDS=sapstart

After any change, restart all SAP instances.

Warning
Warning

Altering /etc/sapwmp.conf should not be necessary. Do not do it until you know exactly what you are doing!

8.3.5 Changing the value of memoryLow Edit source

To change the value of MemoryLow run:

root # systemctl set-property SAP.slice MemoryLow=...

The changes will take effect immediately.

The underlying cgroup memory controller will round up the value to a multiple of the page size. To avoid confusion, set the value of MemoryLow to a multiple of the page size.

Important
Important: Value of MemoryLow

Never set MemoryLow to a value lower than the memory already accounted in SAP.slice. To check, run:

root # systemctl show -p MemoryCurrent SAP.slice

8.3.6 Monitoring memory usage Edit source

Logging the memory usage can be necessary not only to determine the value for memory.low, but also for monitoring the correct operation of WMP.

To enable monitoring, activate the shipped timer unit:

root # systemctl enable --now wmp-sample-memory.timer

Now the timer should be listed by systemctl list-timers:

root # systemctl list-timers
NEXT    LEFT       LAST    PASSED  UNIT                     ACTIVATES
...
Tue...  9min left  Tue...  4s ago  wmp-sample-memory.timer  wmp-sample-memory.service
...

If you check the current configuration, you can see that memory data is collected every 10 minutes with a randomized delay of three minutes:

root # systemctl cat wmp-sample-memory.timer
# /usr/lib/systemd/system/wmp-sample-memory.timer
[Unit]
Description=WMP periodic log of memory consumption

[Timer]
OnCalendar=*:0/10
RandomizedDelaySec=180
AccuracySec=60

[Install]
WantedBy=timers.target

To change this, create a drop-in file and reload systemd (for example, by increasing the interval to 30 minutes):

root # mkdir /etc/systemd/system/wmp-sample-memory.timer.d

# cat <<EOF >/etc/systemd/system/wmp-sample-memory.timer.d/override.conf
[Timer]
OnCalendar=
OnCalendar=*:0/30
EOF

# systemctl daemon-reload

(The first OnCalendar= line is important for deleting previously defined OnCalendar= settings.)

To see the memory consumption, check the system log for lines written by wmp_memory_current:

root # grep wmp_memory_current /var/log/messages
...


2020-09-14T12:02:40.337266+02:00 server-03 wmp_memory_current: SAP.slice : memory.low=21474836480 memory.current=2294059008 memory.swap.current=0 , user.slice : memory.low=0 memory.current=5499219968 memory.swap.current=0 , init.scope : memory.low=0 memory.current=8364032 memory.swap.current=0 , system.slice : memory.low=0 memory.current=1863335936 memory.swap.current=0
2020-09-14T12:03:00.767838+02:00 server-03 wmp_memory_current: SAP.slice : memory.low=21474836480 memory.current=2294022144 memory.swap.current=0 , user.slice : memory.low=0 memory.current=5499473920 memory.swap.current=0 , init.scope : memory.low=0 memory.current=8364032 memory.swap.current=0 , system.slice : memory.low=0 memory.current=1862586368 memory.swap.current=0
2020-09-14T12:04:00.337315+02:00 server-03 wmp_memory_current: SAP.slice : memory.low=21474836480 memory.current=2294022144 memory.swap.current=0 , user.slice : memory.low=0 memory.current=5499207680 memory.swap.current=0 , init.scope : memory.low=0 memory.current=8355840 memory.swap.current=0 , system.slice : memory.low=0 memory.current=1862746112 memory.swap.current=0
...

Here is a reformatted log line to get a better impression:

2020-09-14T12:02:40.337266+02:00 server-03 wmp_memory_current:
SAP.slice    : memory.low=21474836480 memory.current=2294059008 memory.swap.current=0 ,
user.slice   : memory.low=0           memory.current=5499219968 memory.swap.current=0 ,
init.scope   : memory.low=0           memory.current=8364032    memory.swap.current=0 ,
system.slice : memory.low=0           memory.current=1863335936 memory.swap.current=0

For each cgroup directly below /sys/fs/cgroup/ one comma-separated block exists. On a normal system, you should find at least user.slice, system.slice, and init.scope. WMP adds SAP.slice.

Each block contains the information about the current value of memory.low and memory.current, and the currently allocated amount of physical memory of processes in this cgroup.

If you enabled swap accounting (swapaccount=1) during setup, you also have memory.swap.current, the amount of swapped-out memory of the cgroup.

All values are in bytes. See Step 6 in Section 8.3.3.1, “Preparing for Workload Memory Protection”.

Tip
Tip: Script for printing

You can find a script to print the information as table or CSV here: https://github.com/scmschmidt/wmp_log_extract

8.3.7 Verifying correct operation Edit source

Besides monitoring memory consumption and swapping (see Section 8.3.6, “Monitoring memory usage”), you should also regularly check that all SAP instance processes are in their scopes below SAP.slice.

To do so, run systemd-cgls and check each instance process.

Example:

root # systemd-cgls -a /sys/fs/cgroup/SAP.slice
Directory /sys/fs/cgroup/SAP.slice:
|-wmp-rd91fd6b3ca0d4c1183659ef4f9a092fa.scope
| |-3349 sapstart pf=/usr/sap/HA0/ERS10/profile/HA0_ERS10_sapha0er
| `-3375 er.sapHA0_ERS10 pf=/usr/sap/HA0/ERS10/profile/HA0_ERS10_sapha0er N...
|-wmp-r360ebfe09bcd4df4873ef69898576199.scope
| |-3572 sapstart pf=/usr/sap/HA0/SYS/profile/HA0_D01_sapha0ci
| |-3624 dw.sapHA0_D01 pf=/usr/sap/HA0/SYS/profile/HA0_D01_sapha0ci
...

A simpler test would be to list all processes, including cgroups, for all SIDs used on the system.

Example:

tux > ps -eo user,pid,cgroup:60,args | grep -e [h]a0adm
ha0adm    2062 0::/user.slice/user-1001.slice/user@1001.service/init.scope  /usr/lib/systemd/systemd --user
ha0adm    2065 0::/user.slice/user-1001.slice/user@1001.service/init.scope  (sd-pam)
ha0adm    3081 0::/SAP.slice/wmp-r73c594e050904c9c922a312dd9a28fd4.scope    sapstart pf=/usr/sap/HA0/SYS/profile/HA0_ASCS00_sapha0as
ha0adm    3133 0::/SAP.slice/wmp-r73c594e050904c9c922a312dd9a28fd4.scope    ms.sapHA0_ASCS00 pf=/usr/sap/HA0/SYS/profile/HA0_ASCS00_sapha0as
ha0adm    3134 0::/SAP.slice/wmp-r73c594e050904c9c922a312dd9a28fd4.scope    en.sapHA0_ASCS00 pf=/usr/sap/HA0/SYS/profile/HA0_ASCS00_sapha0as
ha0adm    3327 0::/SAP.slice/wmp-ra42489517eb846c282c57681e627a496.scope    sapstart pf=/usr/sap/HA0/ERS10/profile/HA0_ERS10_sapha0er
...

All instance processes except sapstartsrv need to be in a scope below 0::/SAP.slice/.

To verify the correct setup, use the wmp-check tool. See Section 8.3.3.2, “Reboot and verification” for more details.

8.3.8 Uninstalling Workload Memory Protection Edit source

  1. Stop the SAP system completely. The sapinit.service has to be stopped, but can stay enabled. All SAP processes have to be terminated.

  2. Remove any changes made to SAP.slice, such as setting MemoryLow:

    root # systemctl revert SAP.slice
  3. (Optional) Remove the package sapwmp:

    root # zypper remove sapwmp

    This step is optional. The package can stay on the system without having an influence.

  4. (Optional) Remove systemd.unified_cgroup_hierarchy=true from GRUB_CMDLINE_LINUX_DEFAULT in /etc/default/grub.

    This step is optional. You can keep cgroup2 without using WMP.

  5. Rewrite the GRUB2 configuration:

    root # grub2-mkconfig -o /boot/grub2/grub.cfg

    After the next boot, the system is switched back to the hybrid cgroup hierarchy.

  6. Remove the line to call sapwmp-capture from each SAP instance profile (usually located in /usr/sap/SID/SYS/profile/):

    Execute_20 = local /usr/lib/sapwmp/sapwmp-capture -a
    Important
    Important: Backup is necessary

    Before editing an instance profile, create a backup! Errors in a profile can prevent an SAP system from starting!

    Important
    Important: About editing profiles directly

    Edit the instance profiles directly only if you have not imported the profiles into the database to manage them via the SAP GUI (transaction RZ11). If you have imported them, use the SAP GUI to add the lines. Profile files located in the file system are overwritten, and any manual changes will be lost!

  7. Reboot the system and verify that your SAP system has been started successfully.

Print this page