Skip to Content

Get more performance for SAP on Linux

Best Practices for Performance of SAP on Linux

There are three different areas, which affect the SAP system performance: the operating system, the database and the SAP system itself. This article is also organized into three parts covering these areas. Before using all the recommendations below in your productive environment test them in your development or test environment before.

Operating System specific

I assume a standard or a “install everything” installation of your Linux distriubtion. A box set up with everything runs a lot of background processes that are not needed for a SAP system at all. Please take into account that you do not shutdown any service you definitely need! Some candidates that are not needed might be:

* sendmail, postfix, canna, cups, gpm, cron, sysstat, syslog, portmap, nfs, httpd, mysql, smb, nmb, etc…

Furthermore an running X is not needed on a server. Setting id:3:initdefault: in the file /etc/inittab instead of id:5:initdefault: prevent the start of the X server after the boot process.

Administrative work on a running server is mostly done via remote ssh access. Only one tty is needed on the remote screen if there is any connected. Commenting mingetty two to six saves additional memory. To do so, comment “2:2345:respawn:/sbin/mingetty tty2” to “6:2345:respawn:/sbin/mingetty tty6” in the file /etc/inittab. After every reboot you now only have one tty. In the urgent case that you really need more running tty’s, change /etc/inittab back, and run “init q” to respawn all tty’s again.

Kernel parameters must be set up correctly to run an SAP system without any problems. Please apply the sapinit rpm on SUSE or on RedHat change the sysctl values manually (see SAP Note 722273)

If you do not rely on correct timestaps of logfiles, you should mount all filesystems with option “noatime”. Other options which are filesystem specific are:

ext3: data=writeback
reiserfs: noborder, nolog, notail

Database specific (MaxDB)

There are not many performance related options in MaxDB which you can turn on, as allmost all of them are already set to the optimum level. Nevertheless here are two of them, which might be adjusted:

MAXCPU = between 1/10 and 1/5 of CPU’s of System, but at minimum equals 1
USE_COROUTINES = YES (starting from MaxDB 7.5.0 Build 31)

SAP specific

As there are hundreds of SAP profile parameters it is hard to tell which combination of them gives you the best performance. The following list contains some of them which definitely increase performance. Please still keep in mind, to test them before using them in any productive environment

use/mprotect = false
es/implementation = std #(only on 64 bit Linux machines)
rdisp/wp_no_dia/upd with oracle 4/1 with MaxDB 3/1 or 2/1.

To get a good CPU utilisation and a good response time never configure more then 4 SAP processes per CPU core. You can of course set up more, if only 4 of them are used heavily.

NUMA featured hardware like SGI Altix machines or AMD Opteron need a special setup to get the best performance. Tests in the LinuxLab at SAP showed an significant increase of performance using one instance per NUMA node. As memory latency dramatically increases between different nodes it is mandatory to configure the system to have one SAP instance per node with the local memory attached to the node.

I’ll post a seperate blog about this topic soon, as it is too specific for this article

You must be Logged on to comment or reply to a post.
  • I wonder what could happen in worst case of deactivating mprotect. Note 807929 explicitly warns doing that:

    Therefore, you should never deactivate memory protection in live systems. If you deactivate it, you do so at your own risk.

    I turned on ‘std’ in our test system and switched mprotect off just to test if the performance will be better.

    Is that an “official” advise or just for personal laptop systems?

    BTW: that specific test system is running on IA64 – if that matters.


  • Hi Hannes,
    as a contribution i would like to suggest turning off the nscd caching daemon on your linux machines (#chkconfig nscd off). Nscd daemon is a process that implements a cache for name service requests. I suggest keeping this off as I’ve had direct experience on how it can impact performances; in particular it keeps too many open files till possibly stop the instance for the error “VFS: file-max limit xxxxx reached”.