Example for sap_hana.conf | RHEL 7.6 | HANA 2.0
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:
https://wiki.scn.sap.com/wiki/display/ATopics/Technical+Resources+for+SAP+HANA+and+Data+Hub+on+Red+Hat Technical Resources for SAP HANA and Data Hub on Red Hat
https://launchpad.support.sap.com/#/notes/2235581 SAP HANA: Supported Operating Systems
https://launchpad.support.sap.com/#/notes/2009879 SAP HANA Guidelines for Red Hat Enterprise Linux (RHEL) Operating System)
https://launchpad.support.sap.com/#/notes/2292690 SAP HANA DB: Recommended OS settings for RHEL 7
https://launchpad.support.sap.com/#/notes/2777782 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.
Very nice and practical content.
Thanks for sharing.
As handling system configurations is notoriously error-prone when dealing with many different text files, many possible people that are involved and many systems, a file-local history usually is not a good idea.
Instead, keeping track of the configuration files can be done in a shared git repository.
That way one can define a template configuration file (with it's commented history) and pull it to the downstream systems one by one (again with keeping track of the history and maybe additional changes).
thank you for your great comment. I was thinking about ANSIBLE for downstream pushing changes. But with GIT I could also have versioning. Thanks for the inspiration.
thanks for collecting all valid notes and adding a example of such a config. But there will be a lot of people who copy this example 1:1. This values should be tested very well because every vendor (hypervisor, storage, backup tools etc.) has different recommendations.
Nowadays the manual way to add all parameters is a little bit old fashioned as you already named the tuned profiles. Therefore can use sapconf / tuned-adm.
To stay on a homogeneous level you have to orchestrate this configs on a central server (e.g. a git repository) like Lars already mentioned. If you get more and more server you will end up in a configuration zoo without a management tool which shows you differences.
In the future you can use ansible playbooks. If there is an update on a SAP note which includes a parameter this will be considered when you update your repository.
Check out the blog series of Marcos Entenza
exactly - every tech consultant has to validate parameters for his landscape. Nobody wants to have a configuration zoo. We build up some ANSIBLE scripts for deployment. Unfortunally the sapconf / tuned-adm on RHEL is not as accurate as recommended in the SAP notes.
To give you an example. I am used to only touch tuned.profiles only when it comes to a linux kernel upgrade and then also updated tuned and RHEL specific repos. The sap_hana.conf I am modifying more frequently, due to new SAP notes.