Technology Blogs by Members
Explore a vibrant mix of technical expertise, industry insights, and tech buzz in member blogs covering SAP products, technology, and events. Get in the mix!
Showing results for 
Search instead for 
Did you mean: 
Dear SAP Community,

my name is Stefan and I am working as a technical project manager at a SAP customer in Liechtenstein. My goal is to deploy productive HANA database with HA in several automotive plants worldwide and manage a central reporting & analytics HANA database hosted at SAP Cloud Platform. Since we are at three productive HANA database systems already I want to share with the community my example of handling configurations.

Everyone who is dealing with SAP HANA databases on premise has the challenge to adjust some standard linux parameters to run the HANA in a perfect way. From my experience the parameters are increasing with every HANA and every LINUX version. So it is fair to say there should be a proper configuration file for a longterm use where you assign and describe and write down your parameters. In this blog post I am showing you my example how I configure the HANA parameters.

To apply SAP Note 2382421 - Optimizing the Network Configuration on HANA- and OS-Level I share my config file sap_hana.conf which I stored in /etc/sysctl.d/ in Red Hat Enterprise based linux environment to set this parameters in a persistent mode. After reboot of the server the parameters are still there.
# created by Stefan Kaiser
# date: 2020-02-05
# related SAP note: 2382421
# to reload sysctl configuration you can use: #sysctl --system

# This sets the max OS receive buffer size for all types of connections.
net.core.rmem_max = 64000000

# This parameter limits the size of the accept backlog of a listening socket.
# The Linux default of 128 is not sufficient so you need to set the parameter to at least 4096 in order that the HANA system can use higher values.
# There is an interdependency between this parameter and HANA configuration parameter tcp_backlog. If net.core.somaxconn is set to a lower value than tcp_backlog, tcp_backlog will be silently truncated to the value set for net.core.somaxconn. Therefore, you need to ensure that net.core.somaxconn is always set to a value equal to or greater than tcp_backlog.
net.core.somaxconn = 4096

# These settings define the maximum socket send and receive buffer size.
# To ensure complete functionality it must be ensured that the wmem_max and rmem_max values are at least the same as the respective maximum value of the parameters net.ipv4.tcp_wmem and net.ipv4.tcp_rmem.
net.core.wmem_max = 64000000

# This is the size of the SYN backlog.
# To prevent the kernel from using SYN cookies in a situation where lots of connection requests are sent in a short timeframe and to prevent a corresponding warning about a potential SYN flooding attack in the system log, the size of the SYN backlog should be set to a reasonably high value.
net.ipv4.tcp_max_syn_backlog = 8192

# These parameters specify the minimum, default and maximum size of the TCP send and receive buffer.
net.ipv4.tcp_rmem = 10000000 10000000 10000000
net.ipv4.tcp_wmem = 10000000 10000000 10000000

# This setting disables the need to scale-up incrementally the TCP window size for TCP connections which were idle for some time. Using this parameter it is ensured that the maximum speed is used from beginning also for previously idle TCP connections.
net.ipv4.tcp_slow_start_after_idle = 0

# The default value for this parameter is 5, which translates to a timeout of about 24 seconds.
# If the system is under load, a timeout of 24 seconds can be too short and lead to avoidable errors.
# It also prevents processes to set a longer timeout. The recommended value is 8, which translates into a timeout of 190 seconds
net.ipv4.tcp_syn_retries = 8

# This setting adds the timestamp field to the TCP header.
# It should already be active on most systems and is a prerequisite for net.ipv4.tcp_tw_reuse and net.ipv4.tcp_tw_recycle.
net.ipv4.tcp_timestamps = 1

# This setting reduces the time a connection spends in the TIME_WAIT state.
# One precondition for it to take effect is that TCP timestamps are enabled, i.e. net.ipv4.tcp_timestamps = 1, which is the default on most modern systems.
net.ipv4.tcp_tw_recycle = 1

# This setting allows HANA to reuse a client port immediately after the connection has been closed, even though the connection is still in TIME_WAIT state. A precondition for it to take effect is that TCP timestamps are enabled, i.e. net.ipv4.tcp_timestamps = 1, which is the default on most modern systems.
net.ipv4.tcp_tw_reuse = 1

# This setting enables the TCP window scaling.
# On most systems it already should be active. Moreover, it is a prerequisite for net.ipv4.tcp_wmem and net.ipv4.tcp_rmem.
net.ipv4.tcp_window_scaling = 1

# As HANA uses a considerable number of connections for the internal communication, it makes sense to have as many client ports available as possible for this purpose.
# At the same time, you need to ensure that you explicitly exclude the ports used by processes and applications which bind to specific ports by adjusting parameter net.ipv4.ip_local_reserved_ports accordingly.
net.ipv4.ip_local_port_range = 9000 64999

# SAP Host Agent takes care of adjusting this parameter and setting it manually is neither recommended nor required
#net.ipv4.ip_local_reserved_ports =

# SAP HANA is a NUMA (non-uniform memory access) aware database. Thus it does not rely on the Linux kernel's features to optimize NUMA usage automatically. Depending on the workload, it can be beneficial to turn off automatical NUMA balancing.
kernel.numa_balancing = 0


To reload the sysctl just use: #sysctl --system


Please pay attention to: Technical Resources for SAP HANA and Data Hub on Red Hat SAP HANA: Supported Operating Systems SAP HANA Guidelines for Red Hat Enterprise Linux (RHEL) Operating System) SAP HANA DB: Recommended OS settings for RHEL 7 SAP HANA DB: Recommended OS Settings for RHEL 8


I described the way how I am handling RedHat Enterprise Linux configurations with SAP HANA databases. It is important to think about a long-term strategy. Every technology consultant has the interessest that changes in the configurations file should be documented. Also it is recommended to add the relevant SAP notes to the config file entries. It is also fair to say that some parameters could  be included into some tuned profiles in the future. Never the less it is a plus to know what is the parameters description, behaviour and expression.


Since we had the first review of our HANA databases on premise and at SAP Cloud Platform we got an audit documentation with some recommended parameters. We had a lessons learnd because the first time we modified the parameters they where only valid until the server was up and running. After a maintenance downtime the parameters disappeard. This is why we now go strictly with persistent config file.


BR Stefan
Labels in this area