Initializing the Installation Environment

Creating the Required User Account and Configuring the Installation Environment
Establishing Mutual Trust Manually
Configuring OS Parameters

Creating the Required User Account and Configuring the Installation Environment

After the openGauss configuration file is created, you need to run the gs_preinstall script to prepare the account and environment so that you can perform openGauss installation and management operations with the minimum permission, ensuring system security.

Executing the gs_preinstall script enables the system to automatically complete the following installation preparations:

Sets kernel parameters for the SUSE Linux OS to improve server load performance. The kernel parameters directly affect database running status. Reconfigure them only when necessary. For details about the Linux OS kernel parameter settings in openGauss, see Configuring OS Parameters.
Automatically copies the openGauss configuration files and installation packages to the same directory on each openGauss host.
If the installation user and user group of the openGauss do not exist, the system automatically creates them.
Reads the directory information in the openGauss configuration file, creates the directory, and grants the directory permission to the installation user.

Prerequisites

You have completed all the tasks described in Preparing for Installation.

Precautions

You must check the upper-layer directory permissions to ensure that the user has the read, write, and execution permissions on the installation package and configuration file directory.
The mapping between each host name and IP address in the XML configuration file must be correct.
Only user root is authorized to run the gs_preinstall command.

Procedure

Log in to any host where the openGauss is to be installed as user root and create a directory for storing the installation package as planned.
```
mkdir -p /opt/software/openGauss
chmod 755 -R /opt/software
```
NOTE:
- Do not create the directory in the home directory or subdirectory of any openGauss user because you may lack permissions for such directories.
- The openGauss user must have the read and write permissions on the /opt/software/openGauss directory.
Upload the software package openGauss-x.x.x-openEuler-64bit-all.tar.gz and the configuration file cluster_config.xml to the created directory.
Go to the directory for storing the uploaded software package and decompress openGauss-x.x.x-openEuler-64bit-all.tar.gz. After the installation package is decompressed, the OM and Server installation packages are generated. After the OM installation package is decompressed, the script subdirectory is automatically generated in /opt/software/openGauss. OM tool scripts such as gs_preinstall are generated in the script subdirectory.
```
cd /opt/software/openGauss
tar -zxvf openGauss-1.1.0-openEuler-64bit-all.tar.gz
tar -zxvf openGauss-1.1.0-openEuler-64bit-om.tar.gz
```
NOTE:
- When you execute the gs_preinstall script, plan the directory for storing the openGauss configuration file, directory for storing software packages, installation directories of programs, and directories of instance data. Common users cannot change the directories after the directories are specified.
- When you execute the gs_preinstall script to prepare the installation environment, the script automatically copies the openGauss configuration file and decompressed installation package to the same directory on other servers.
- Before executing gs_preinstall and establishing mutual trust, check whether the /etc/profile file contains error information. If it does, manually rectify the error.
Go to the directory for storing tool scripts.
```
cd /opt/software/openGauss/script
```
For openEuler, run the following command to open the gspylib/common/CheckPythonVersion.py file and change if not pythonVersion == (3, 6): to if not pythonVersion >= (3, 6):. Press Esc to enter the command mode, and run the :wq command to save the modification and exit.
```
vi gspylib/common/CheckPythonVersion.py
```
If the openEuler operating system is used, run the following command to open the performance.sh file, comment out sysctl -w vm.min_free_kbytes=112640 &> /dev/null using the number sign (#), press Esc to enter the command mode, and run the :wq command to save the modification and exit.
```
vi /etc/profile.d/performance.sh
```
To ensure successful installation, run the following command to check whether the values of hostname and /etc/hostname are the same.
```
hostname
cat /etc/hostname 
```
If the value of hostname is different from the host name in the /etc/hostname file, run the following command to open the /etc/hostname file and change the host name. Press Esc to enter the command mode, and then run the :wq command to save the change and exit.
```
vi /etc/hostname 
```
Execute gs_preinstall to configure the installation environment. If the shared environment is used, add the --sep-env-file=ENVFILE parameter to separate environment variables to avoid mutual impact with other users. The environment variable separation file path is specified by users.
- Execute gs_preinstall in interactive mode. During the execution, the mutual trust between users root and between openGauss users is automatically established.
```
./gs_preinstall -U omm -G dbgrp -X /opt/software/openGauss/cluster_config.xml
```
  omm is the database administrator (also the OS user running the openGauss), dbgrp is the group name of the OS user running the openGauss, and /opt/software/openGauss/cluster_config.xml is the path of the openGauss configuration file. During the execution, you need to determine whether to establish mutual trust as prompted and enter the password of the OS user root or the user omm.
- If the mutual trust between users root cannot be created, create the omm user, perform local preinstallation on each host, and manually create the mutual trust between openGauss users. If the -L parameter is specified during preinstallation, manually write the mapping between the host names and IP addresses of all nodes to the /etc/hosts file of each host before preinstallation, add #Gauss OM IP Hosts Mapping to the end of each mapping.
  1. Run the following command to configure the installation environment:
```
cd /opt/software/openGauss/script
./gs_preinstall -U omm -G dbgrp -L -X /opt/software/openGauss/cluster_config.xml
```
    NOTE:
    You need to run this command on each host.
- Execute gs_preinstall in non-interactive mode.
  1. Manually establish mutual trust between users root and between openGauss users by following the instructions provided inEstablishing Mutual Trust Manually .
  2. Run the following command to configure the installation environment:
```
cd /opt/software/openGauss/script
./gs_preinstall -U omm -G dbgrp -X /opt/software/openGauss/cluster_config.xml --non-interactive
```
  NOTE:
  - In this mode, ensure that mutual trust has been established between the root users of all nodes and between the openGauss users of the cluster before performing.In this mode, ensure that mutual trust has been established between users root and between openGauss users on each node before executing gs_preinstall.
  - The mutual trust established between users root may incur security risks. You are advised to delete the mutual trust between users root immediately after the installation is complete.

Examples

Execute the gs_preinstall script.

plat1:/opt/software/openGauss/script # ./gs_preinstall -U omm -G dbgrp -X /opt/software/openGauss/cluster_config.xml
Parsing the configuration file.
Successfully parsed the configuration file.
Installing the tools on the local node.
Successfully installed the tools on the local node.
Are you sure you want to create trust for root (yes/no)? yes
Please enter password for root.
Password:
Creating SSH trust for the root permission user.
Checking network information.
All nodes in the network are Normal.
Successfully checked network information.
Creating SSH trust.
Creating the local key file.
Successfully created the local key files.
Appending local ID to authorized_keys.
Successfully appended local ID to authorized_keys.
Updating the known_hosts file.
Successfully updated the known_hosts file.
Appending authorized_key on the remote node.
Successfully appended authorized_key on all remote node.
Checking common authentication file content.
Successfully checked common authentication content.
Distributing SSH trust file to all node.
Successfully distributed SSH trust file to all node.
Verifying SSH trust on all hosts.
Successfully verified SSH trust on all hosts.
Successfully created SSH trust.
Successfully created SSH trust for the root permission user.
Setting pssh path
Successfully set core path.
Distributing package.
Begin to distribute package to tool path.
Successfully distribute package to tool path.
Begin to distribute package to package path.
Successfully distribute package to package path.
Successfully distributed package.
Are you sure you want to create the user[omm] and create trust for it (yes/no)? yes
Please enter password for cluster user.
Password:
Please enter password for cluster user again.
Password:
Successfully created [omm] user on all nodes.
Preparing SSH service.
Successfully prepared SSH service.
Installing the tools in the cluster.
Successfully installed the tools in the cluster.
Checking hostname mapping.
Successfully checked hostname mapping.
Creating SSH trust for [omm] user.
Checking network information.
All nodes in the network are Normal.
Successfully checked network information.
Creating SSH trust.
Creating the local key file.
Successfully created the local key files.
Appending local ID to authorized_keys.
Successfully appended local ID to authorized_keys.
Updating the known_hosts file.
Successfully updated the known_hosts file.
Appending authorized_key on the remote node.
Successfully appended authorized_key on all remote node.
Checking common authentication file content.
Successfully checked common authentication content.
Distributing SSH trust file to all node.
Successfully distributed SSH trust file to all node.
Verifying SSH trust on all hosts.
Successfully verified SSH trust on all hosts.
Successfully created SSH trust.
Successfully created SSH trust for [omm] user.
Checking OS software.
Successfully check os software.
Checking OS version.
Successfully checked OS version.
Creating cluster's path.
Successfully created cluster's path.
Setting SCTP service.
Successfully set SCTP service.
Set and check OS parameter.
Setting OS parameters.
Successfully set OS parameters.
Preparing CRON service.
Successfully prepared CRON service.
Setting user environmental variables.
Successfully set user environmental variables.
Setting the dynamic link library.
Successfully set the dynamic link library.
Setting Core file
Successfully set core path.
Setting pssh path
Successfully set pssh path.
Set ARM Optimization.
No need to set ARM Optimization.
Fixing server package owner.
Setting finish flag.
Successfully set finish flag.
Preinstallation succeeded.

If the passwords of the user root on the primary and standby nodes are different and cannot be changed to the same value, run the gs_preinstall script in local installation mode.

plat1:/opt/software/openGauss/script # ./gs_preinstall -U omm -G dbgrp -L -X /opt/software/openGauss/cluster_config.xml 
Parsing the configuration file.
Successfully parsed the configuration file.
Installing the tools on the local node.
Successfully installed the tools on the local node.
Checking OS version.
Successfully checked OS version.
Creating cluster's path.
Successfully created cluster's path.
Setting SCTP service.
Successfully set SCTP service.
Set and check OS parameter.
Setting OS parameters.
Successfully set OS parameters.
Warning: Installation environment contains some warning messages.
Please get more details by "/home/package/r8c00/script/gs_checkos -i A -h SIA1000068990".
Set and check OS parameter completed.
Preparing CRON service.
Successfully prepared CRON service.
Preparing SSH service.
Successfully prepared SSH service.
Setting user environmental variables.
Successfully set user environmental variables.
Configuring alarms on the cluster nodes.
Successfully configured alarms on the cluster nodes.
Setting the dynamic link library.
Successfully set the dynamic link library.
Setting Cgroup.
Successfully set Cgroup.
Setting finish flag.
Successfully set finish flag.
Preinstallation succeeded.

Execute gs_preinstall in non-interactive mode.

plat1:/opt/software/openGauss/script # ./gs_preinstall -U omm -G dbgrp -X /opt/software/openGauss/cluster_config.xml --non-interactive
Parsing the configuration file.
Successfully parsed the configuration file.
Installing the tools on the local node.
Successfully installed the tools on the local node.
Distributing package.
Begin to distribute package to tool path.
Successfully distribute package to tool path.
Begin to distribute package to package path.
Successfully distribute package to package path.
Successfully distributed package.
Installing the tools in the cluster.
Successfully installed the tools in the cluster.
Checking hostname mapping.
Successfully checked hostname mapping.
Checking OS version.
Successfully checked OS version.
Creating cluster's path.
Successfully created cluster's path.
Setting SCTP service.
Successfully set SCTP service.
Set and check OS parameter.
Setting OS parameters.
Successfully set OS parameters.
Set and check OS parameter completed.
Preparing CRON service.
Successfully prepared CRON service.
Preparing SSH service.
Successfully prepared SSH service.
Setting user environmental variables.
Successfully set user environmental variables.
Configuring alarms on the cluster nodes.
Successfully configured alarms on the cluster nodes.
Setting the dynamic link library.
Successfully set the dynamic link library.
Setting Cgroup.
Successfully set Cgroup.
Set ARM Optimization.
Successfully set ARM Optimization.
Setting finish flag.
Successfully set finish flag.
Preinstallation succeeded.

Troubleshooting

If configuring the installation environment fails, obtain the gs_preinstall-YYYY-MM-DD_HHMMSS.log and gs_local-YYYY-MM-DD_HHMMSS.log files from the $GAUSSLOG/om directory for storing openGauss logs. Then, locate the problem based on the log information. For example, if the path specified by the gaussdbLogPath parameter in the configuration file is /var/log/gaussdb, the $GAUSSLOG/om path is /var/log/gaussdb/omm/om, and the omm user is the user running openGauss.

NOTICE:
While the installation user and environment is prepared, user root is used to add scheduled tasks for routine inspection and reporting.

Establishing Mutual Trust Manually

During the openGauss installation, you need to perform operations such as running commands and transferring files between hosts in openGauss. Establish mutual trust among the hosts before installing the cluster as a common user. During the execution of the pre-installation script, establish mutual trust between users root, then create a common user account, and finally establish mutual trust between common users.

NOTICE:
The mutual trust between users root may incur security risks. You are advised to delete the mutual trust between users root after the installation is complete.

Prerequisites

The SSH service has been enabled.
You have verified that SSH ports will not be disabled by firewalls.
Each host name and IP address have been correctly configured in the XML file.
Communication among all the hosts is normal.
If the mutual trust is to be established for common users, the same user needs to be created and password set on each host.
If the SELinux service is installed and has been started on each host, ensure that the security context of the /root directory is set to the default value system_u:object_r:admin_home_t:s0 and that of the /home directory is set to the default value system_u:object_r:home_root_t:s0, or disable the SELinux service.
To check the SELinux status, run the getenforce command. If the command output is Enforcing, SELinux is installed and has been enabled.
To check the security contexts of the directories, run the following commands:
```
ls -ldZ  /root | awk '{print $4}'
```
```
ls -ldZ  /home | awk '{print $4}'
```
To restore the security contexts of the directories, run the following commands:
```
restorecon -r -vv /home/
```
```
restorecon -r -vv /root/
```

Establishing Mutual Trust Using a Script

Establishing a mutual trust relationship using a script has the following impacts:

The /etc/hosts file may be modified. Back up the /etc/hosts file before using the script to establish mutual trust.
The script deletes the existing .ssh file directory. If you want to retain the mutual trust relationship established between nodes, use the method described in Establishing Mutual Trust Manually .

Create the file for executing the mutual trust script, and add the IP addresses of all the hosts in the openGauss to the file.
```
plat1:/opt/software/openGauss> vim hostfile
192.168.0.1
192.168.0.2
192.168.0.3
```
Execute the script as the user who needs to establish mutual trust with the hosts.
```
plat1:/opt/software/openGauss/script# ./gs_sshexkey -f /opt/software/hostfile
```
The /opt/software/hostfile file contains a list of the hosts. The list provides the IP addresses of all the hosts among which mutual trust needs to be established.

Establishing Mutual Trust Manually

If the passwords of user root on the hosts in the openGauss are different, the gs_preinstall script cannot be used to establish mutual trust. In this case, manually establish mutual trust.

NOTE:
The following files are generated during establishment of mutual trust: authorized_keys, id_rsa, id_rsa.pub, and known_hosts. Do not delete or corrupt the files.

The procedure of manually establishing mutual trust is as follows (plat1, plat2, and plat3 are host names):

Generate a licensed file for user root on any host (referred to as the local host). Host plat1 is used as an example. a. Generate a key.

   ssh-keygen -t rsa

The following is an example:

    plat1:~ # ssh-keygen -t rsa 
    Generating public/private rsa key pair.
    Enter file in which to save the key (/root/.ssh/id_rsa): 
    Created directory '/root/.ssh'.
    Enter passphrase (empty for no passphrase): 
    Enter same passphrase again: 
    Your identification has been saved in /root/.ssh/id_rsa.
    Your public key has been saved in /root/.ssh/id_rsa.pub.
    The key fingerprint is:
    d5:35:46:33:27:22:09:f0:1e:12:a7:87:fa:33:3f:ab root@plat1
    The key's randomart image is:
    +--[ RSA 2048]----+
    |      o.o.....O .|
    |       *  .o + * |
    |      + + . .    |
    |     . + o       |
    |    .   S        |
    |     .           |
    |      +          |
    |       +.        |
    |      E.oo       |
    +-----------------+

b. Generate the licensed file.

    cat .ssh/id_rsa.pub >> ~/.ssh/authorized_keys

The following is an example:

    plat1:~ # cat ~/.ssh/id_rsa.pub >> ~/.ssh/authorized_keys

Obtain the public keys of all the hosts among which mutual trust needs to be established, and write the public keys into the known_hosts file on the local host. This step needs to be performed on the host where Step 1 is performed. You need to obtain the public keys of the plat1, plat2, and plat3 hosts. a. Obtain the public key of host plat1, and write the public key into the known_hosts file on the local host.
```
    ssh-keyscan -t rsa plat1 >> ~/.ssh/known_hosts
```
The following is an example:
```
    plat1:~ # ssh-keyscan -t rsa plat1 >> ~/.ssh/known_hosts 
    # plat1 SSH-2.0-OpenSSH_5.1 
```
b. Obtain the public key of host plat2, and write the public key into the known_hosts file on the local host.
```
    ssh-keyscan -t rsa plat2 >> ~/.ssh/known_hosts
```
The following is an example:
```
    plat1:~ # ssh-keyscan -t rsa plat2 >> ~/.ssh/known_hosts 
    # plat2 SSH-2.0-OpenSSH_5.1 
```
c. Obtain the public key of host plat3, and write the public key into the known_hosts file on the local host.
```
    ssh-keyscan -t rsa plat3 >> ~/.ssh/known_hosts
```
The following is an example:
```
    plat1:~ # ssh-keyscan -t rsa plat3 >> ~/.ssh/known_hosts 
    # plat3 SSH-2.0-OpenSSH_5.1 
```
NOTE:
- After being accepted, the public key of a remote host will be saved in the $HOME/.ssh/known_hosts file on the local host. When connecting to the remote host next time, the system can recognize that the public key of the remote host has been saved on the local host and then skip alarms.
- If the known_hosts file is deleted from the local host, the mutual trust between the local and remote hosts remains valid, but alarms will be reported. To prevent such alarms, set the StrictHostKeyChecking parameter in the /etc/ssh/ssh_config file to no.
Send the known_hosts file to all the other hosts except the local host. In this example, send the known_hosts file on host plat1 to hosts plat2 and plat3.
a. Send the known_hosts file to host plat2. When Password: is displayed, enter the password for logging in to host plat2.
scp -r ~/.ssh plat2:~
The following is an example: plat1:~ # scp -r ~/.ssh plat2:~ Password: authorized_keys 100% 796 0.8KB/s 00:00
id_rsa 100% 1675 1.6KB/s 00:00
id_rsa.pub 100% 398 0.4KB/s 00:00
known_hosts 100% 1089 1.1KB/s 00:00
b. Send the known_hosts file to host plat3. When Password: is displayed, enter the password for logging in to host plat3.
```
    scp -r ~/.ssh plat3:~
```
The following is an example:
```
    plat1:~ # scp -r ~/.ssh plat3:~
    Password: 
    authorized_keys                 100%  796     0.8KB/s   00:00    
    id_rsa                          100% 1675     1.6KB/s   00:00    
    id_rsa.pub                      100%  398     0.4KB/s   00:00    
    known_hosts                     100% 1089     1.1KB/s   00:00    
```
Run the **ssh **Host name command to check whether mutual trust has been successfully established. Then, enter exit.
```
plat1:~ # ssh plat2
Last login: Sat Jun 20 14:01:07 2020
plat2:~ # exit
logout
Connection to plat2 closed.
plat1:~ # 
```
NOTE:
If there are more than three hosts, the procedure of manually establishing mutual trust between the hosts is similar to the one in this section. Assume that the host names are plat1, plat2, plat3, … Firstly, generate a licensed file for user root on host plat1 (referred to as the local host). Secondly, obtain the public keys of all the hosts (plat1, plat2, plat3, …) between which mutual trust needs to be established, and write the public keys to the known_hosts file on the local host. Thirdly, send the file from the local host to all the other hosts (plat2, plat3, …). Finally, verify that mutual trust has been successfully established.

Deleting Mutual Trust Between Users root

The mutual trust established between users root may incur security risks. You are advised to delete the mutual trust between users root immediately after the installation is complete.

Delete the mutual trust file /root/.ssh from each openGauss database node.
rm –rf ~/.ssh
Check whether the mutual trust is successfully deleted. If the host names cannot be reached from each other through SSH and a mutual trust failure message is displayed, the mutual trust is successfully deleted.
plat1:~ # ssh plat2
he authenticity of host ' plssat2 (plat2)' can't be established.
ECDSA key fingerprint is SHA256:Q4DPRedFytsjsJSKf4l2lHKuzVw4prq3bIUCNVKIa7M.
ECDSA key fingerprint is MD5:e2:77:6c:aa:4c:43:5f:f2:c4:58:ec:d5:53:de:7c:fc.
Are you sure you want to continue connecting (yes/no)?

Examples

The following is an example describing how to establish mutual trust between users root:

plat1:~ # gs_sshexkey -f /opt/software/hostfile -W Gauss_123
Checking network information.
All nodes in the network are Normal.
Successfully checked network information.
Creating SSH trust.
Creating the local key file.
Successfully created the local key files.
Appending local ID to authorized_keys.
Successfully appended local ID to authorized_keys.
Updating the known_hosts file.
Successfully updated the known_hosts file.
Appending authorized_key on the remote node.
Successfully appended authorized_key on all remote node.
Checking common authentication file content.
Successfully checked common authentication content.
Distributing SSH trust file to all node.
Successfully distributed SSH trust file to all node.
Verifying SSH trust on all hosts.
Successfully verified SSH trust on all hosts.
Successfully created SSH trust.

The following is an example describing how to establish mutual trust between common users:

gaussdb@plat1:~ > gs_sshexkey -f /opt/software/hostfile -W Gauss_123
Checking network information.
All nodes in the network are Normal.
Successfully checked network information.
Creating SSH trust.
Creating the local key file.
Successfully created the local key files.
Appending local ID to authorized_keys.
Successfully appended local ID to authorized_keys.
Updating the known_hosts file.
Successfully updated the known_hosts file.
Appending authorized_key on the remote node.
Successfully appended authorized_key on all remote node.
Checking common authentication file content.
Successfully checked common authentication content.
Distributing SSH trust file to all node.
Successfully distributed SSH trust file to all node.
Verifying SSH trust on all hosts.
Successfully verified SSH trust on all hosts.
Successfully created SSH trust.

The following is an example describing how to establish mutual trust in security mode. This mode is recommended. Users need to manually enter their passwords as prompted.

plat1:~ # gs_sshexkey -f /opt/software/hostfile
Please enter password for current user[root].
Password: 
Checking network information.
All nodes in the network are Normal.
Successfully checked network information.
Creating SSH trust.
Creating the local key file.
Appending local ID to authorized_keys.
Successfully appended local ID to authorized_keys.
Updating the known_hosts file.
Successfully updated the known_hosts file.
Appending authorized_key on the remote node.
Successfully appended authorized_key on all remote node.
Checking common authentication file content.
Successfully checked common authentication content.
Distributing SSH trust file to all node.
Successfully distributed SSH trust file to all node.
Verifying SSH trust on all hosts.
Successfully verified SSH trust on all hosts.
Successfully created SSH trust.

Configuring OS Parameters

openGauss requires that the OS parameters on every host be set to specified values to ensure system running performance.

Some of these parameters are set during the openGauss installation environment preparation phase, and these parameters directly affect the running status of the openGauss. You need to manually adjust these parameters only when necessary. You can use the following methods:

Log in to a server as user root.
Modify the /etc/sysctl.conf file.
For details about how to modify parameters, see [OS Parameters](#OS Parameters).
Run the following command to make the modifications take effect:
```
sysctl -p
```

OS Parameters

Table 1 OS parameters

Parameter	Description	Automatically Set by Scripts During Pre-Installation	Recommended Value
net.ipv4.tcp_max_tw_buckets	Specifies the maximum number of TCP/IP connections concurrently remaining in the TIME_WAIT state. If the number of TCP/IP connections concurrently remaining in the TIME_WAIT state exceeds the value of this parameter, the TCP/IP connections in the TIME_WAIT state will be released immediately, and alarm information will be printed.	Yes	10000
net.ipv4.tcp_tw_reuse	Reuses sockets whose status is TIME-WAIT for new TCP connections. 0: This function is disabled. 1: This function is enabled.	Yes	1
net.ipv4.tcp_tw_recycle	Rapidly reclaims sockets whose status is TIME-WAIT in TCP connections. 0: This function is disabled. 1: This function is enabled.	Yes	1
net.ipv4.tcp_keepalive_time	Specifies how often keep-alive messages are sent through TCP connections when Keep-Alive is enabled.	Yes	30
net.ipv4.tcp_keepalive_probes	Specifies the number of keep-alive detection packets sent through a TCP connection before the connection is regarded invalid. The product of the parameter value multiplied by the value of the tcp_keepalive_intvl parameter determines the response timeout after a keep-alive message is sent through a connection.	Yes	9
net.ipv4.tcp_keepalive_intvl	Specifies how often a detection packet is re-sent when the previous packets are not acknowledged.	Yes	30
net.ipv4.tcp_retries1	Specifies the maximum TCP reattempts during the connection establishment process.	No	5
net.ipv4.tcp_syn_retries	Specifies the maximum SYN packet reattempts in the TCP.	No	5
net.ipv4.tcp_synack_retries	Specifies the maximum SYN response packet reattempts in the TCP.	No	5
net.ipv4.tcp_retries2	Specifies the number of times that the kernel re-sends data to a connected remote host. A smaller value leads to earlier detection of an invalid connection to the remote host, and the server can quickly release this connection. If "connection reset by peer" is displayed, increase the value of this parameter to avoid the problem.	Yes	12
vm.overcommit_memory	Specifies the kernel check method during memory allocation. 0: The system accurately calculates the current available memory. 1: The system returns a success message without a kernel check. 2: The system returns a failure message if the memory size you have applied for exceeds the result of the following formula: Total memory size x Value of vm.overcommit_ratio/100 + Total SWAP size. The default value is 2, which is too conservative. The recommended value is 0. If memory usage is high, set this parameter to 1.	Yes	0
net.ipv4.tcp_rmem	Specifies the free memory in the TCP receiver buffer. Three memory size ranges in the unit of page are provided: min, default, and max.	Yes	8192 250000 16777216
net.ipv4.tcp_wmem	Specifies the free memory in the TCP sender buffer. Three memory size ranges in the unit of page are provided: min, default, and max.	Yes	8192 250000 16777216
net.core.wmem_max	Specifies the maximum size of the socket sender buffer.	Yes	21299200
net.core.rmem_max	Specifies the maximum size of the socket receiver buffer.	Yes	21299200
net.core.wmem_default	Specifies the default size of the socket sender buffer.	Yes	21299200
net.core.rmem_default	Specifies the default size of the socket receiver buffer.	Yes	21299200
net.ipv4.ip_local_port_range	Specifies the range of temporary ports that can be used by a physical server.	No	26000-65535
kernel.sem	Specifies the kernel semaphore.	Yes	250 6400000 1000 25600
vm.min_free_kbytes	Specifies the minimum free physical memory reserved for unexpected page breaks.	Yes	5% of the total system memory
net.core.somaxconn	Specifies the maximum length of the listening queue of each port. This is a global parameter.	Yes	65535
net.ipv4.tcp_syncookies	Specifies whether to enable SYN cookies to guard the OS against SYN attacks when the SYN waiting queue overflows. 0: The SYN cookies are disabled. 1: The SYN cookies are enabled.	Yes	1
net.core.netdev_max_backlog	Specifies the maximum number of data packets that can be sent to the queue when the rate at which the network device receives data packets is higher than that at which the kernel processes the data packets.	Yes	65535
net.ipv4.tcp_max_syn_backlog	Specifies the maximum number of unacknowledged connection requests to be recorded.	Yes	65535
net.ipv4.tcp_fin_timeout	Specifies the default timeout duration.	No	60
kernel.shmall	Specifies the total shared free memory of the kernel.	Yes	1152921504606846720
kernel.shmmax	Specifies the maximum value of a shared memory segment.	Yes	18446744073709551615
net.ipv4.tcp_sack	Specifies whether selective acknowledgment is enabled. The selective acknowledgment on out-of-order packets can increase system performance. Restricting users to sending only lost packets (for wide area networks) should be enabled, but this will increase CPU usage. 0: This function is disabled. 1: This function is enabled.	No	1
net.ipv4.tcp_timestamps	Specifies whether the TCP timestamp (12 bytes are added in the TCP packet header) enables a more accurate RTT calculation than the retransmission timeout (for details, see RFC 1323) for better performance. 0: This function is disabled. 1: This function is enabled.	No	1
vm.extfrag_threshold	When system memory is insufficient, Linux will score the current system memory fragments. If the score is higher than the value of vm.extfrag_threshold, kswapd triggers memory compaction. When the value of this parameter is close to 1000, the system tends to swap out old pages when processing memory fragments to meet the application requirements. When the value of this parameter is close to 0, the system tends to do memory compaction when processing memory fragments.	No	500
vm.overcommit_ratio	When the system uses the algorithms where memory usage never exceeds the thresholds, the total memory address space of the system cannot exceed the value of swap+RAM multiplied by the percentage specified by this parameter. When the value of vm.overcommit_memory is set to 2, this parameter takes effect.	No	90
MTU	Specifies the maximum transmission unit (MTU) for a node NIC. The default value is 1500 in the OS. You can set it to 8192 to improve the performance of sending and receiving data.	No	8192

File System Parameters

soft nofile
Indicates the soft limit. The number of file handles used by a user can exceed this parameter value. However, an alarm will be reported.
Recommended value: 1000000
hard nofile
Indicates the hard limit. The number of file handles used by a user cannot exceed this parameter value.
Recommended value: 1000000
stack size
Indicates the thread stack size.
Recommended value: 3072

Setting the transparent_hugepage Service

By default, openGauss disables the transparent_hugepage service and this setting is written into the OS startup file.

Setting File Handles

To manually set the number of file handles, run the following commands to modify the involved parameters as user root:

echo "* soft nofile 1000000" >>/etc/security/limits.conf
echo "* hard nofile 1000000" >>/etc/security/limits.conf

After the modification is complete, restart the OS to make the setting take effect.

Table 2 Parameters for setting the number of file handles

Parameter	Description	Automatically Set by Scripts During Pre-Installation	Recommended Value
* soft nofile	Specifies the soft limit on the number of file handles. For example, if this parameter is set to 1000000, any user can open a maximum of 1,000,000 files regardless of how many shells are enabled.	Yes	1000000
* hard nofile	Specifies the hard limit. The soft limit must be less than or equal to the hard limit.	Yes	1000000

Setting the Maximum Number of Allowed Processes

To manually set the maximum number of allowed processes, run the following command to open the configuration file:

vim /etc/security/limits.d/90-nproc.conf

Modify the * soft nproc parameter in the file.

After the modification is complete, restart the OS to make the setting take effect.

Table 3 Setting the maximum number of allowed processes

Parameter	Description	Automatically Set by Scripts During Pre-Installation	Recommended Value
* soft nproc	Specifies the maximum number of processes allowed per user.	Yes	unlimited

Setting NIC Parameters

Table 4 Setting NIC parameters

Parameter	Description	Automatically Set by Scripts During Pre-Installation	Recommended Value
rx	Specifies the receive queue length for an NIC.	Yes	4096
tx	Specifies the transmission queue length for an NIC.	Yes	4096

NOTICE:

NIC parameters can be configured only for 10GE and larger service NICs, that is, the NIC bound to backIp1.
The commands for setting NIC parameters are written into the OS startup file only after the parameters are successfully set. Information about command execution failures is recorded in logs on the server.