Modifying linux kernel parameters

Linux kernel parameter optimization

As a high-performance WEB server, just tweaking the parameters of Nginx itself won’t work, because the Nginx service depends on a high-performance operating system.

The following are a few common Linux kernel parameter optimizations.

net.ipv4.tcp_max_tw_buckets

For a tcp connection, the state of the server and the client becomes a timewait after communication, and if a server is very busy and has a particularly high number of connections, then this timewait will be larger and larger.

After all, it takes up a certain amount of resources, so there should be a maximum value above which the system deletes the earliest connections, so that it always stays at an order of magnitude.

This value is what is determined by the parameter net.ipv4.tcp_max_tw_buckets.

CentOS7, you can use sysctl-a|greptw_buckets to see its value, the default is 32768,

You can appropriately lower it, for example, adjust it to 8000, after all, this state of too many connections can also consume resources.

But you don’t want to adjust it to dozens or hundreds like this, because this state of tcp connection is also useful,

If the same client communicates with the server again, you don’t need to establish a new connection again, use this old channel, save time and effort.

net.ipv4.tcp_tw_recycle=1

The purpose of this parameter is to quickly recycle connections in timewait state. Although it is mentioned above that the system automatically deletes connections in the timewait state, wouldn’t it be better to reuse such connections.

Setting this parameter to 1 allows the timewait connection to be reclaimed quickly, and it should be used in conjunction with the following parameters.

net.ipv4.tcp_tw_reuse=1

This parameter is set to 1 to repurpose timewait state connections for new TCP connections, and it needs to be used in conjunction with the parameter above.

net.ipv4.tcp_syncookies=1

Tcp three times handshake, the client initiates a syn request to the server, the server receives it and also initiates a syn request to the client with an ack acknowledgement,

If the client sends a request and then directly disconnects from the server and does not receive this request, the server will reissue the request.

If the client disconnects from the server after sending a request and does not receive the request, the server will retry several times,

This retry process will last for a period of time (usually more than 30s), when the number of connections in this state is very large, the server will consume a lot of resources, resulting in a paralyzed

Normal connections can not come in, this kind of malicious half-connections is actually called a synflood attack.

Setting it to 1 is to turn on SYNCookies, which when turned on prevents the synflood attack described above from occurring.

With this parameter turned on, the server receives the client’s ack and then asks the client to respond with a serial number within a short period of time before sending the ack+syn to the client.

If the client can’t provide a serial number or provides an incorrect serial number, then it is assumed that the client is illegitimate, so it will not send the ack+syn to the client, and it will not be involved in the retry.

net.ipv4.tcp_max_syn_backlog

This parameter defines the maximum number of half-connected tcp connections that the system can accept. The client sends a syn packet to the server, and when the server receives it, it logs it.

This parameter determines the maximum number of such connections that can be logged. In CentOS7, the default is 256, when there is a synflood attack, this value is too small then it is easy to cause the server to be paralyzed.

In fact, at this time, the server does not consume too many resources (cpu, memory, etc.), so you can appropriately adjust it up, for example, adjust it to 30000.

net.ipv4.tcp_syn_retries

net.ipv4. retries

This parameter applies to the client side, it defines the maximum number of retries for initiating syn, the default is 6, and it is recommended to change it to 2.

net.ipv4.tcp_synack_retries

This parameter applies to the server side, it defines the maximum number of retries for initiating syn+ack, the default is 5, and it is recommended to change it to 2 to properly prevent synflood attacks.

net.ipv4.ip_local_port_range

This parameter defines the range of ports, the system default reserved ports are 1024 and below, the above part is customized ports. This parameter applies to the client,

When the client and the server establish a connection, for example, to access port 80 on the server, the client randomly opens a port and the server initiates a connection,

This parameter defines the range of random ports. The default is 3276861000, and it is recommended that it be adjusted to 102561000.

net.ipv4.tcp_fin_timeout

One of the states of a tcp connection on the client is the FIN-WAIT-2 state, which is the state that precedes the state change to timewait.

This parameter defines the timeout for this connection state that does not belong to any process, the default value is 60, and it is recommended to adjust it to 6.

net.ipv4.tcp_keepalive_time

One of the tcp connection states is the ESTABLISHED state, which is the only state in which the client and the service side can communicate. Under normal circumstances, when communication is complete,

the client or server will tell the other side to close the connection, and the state will change to timewait. If the client does not tell the server,

and the server does not tell the client to close it (e.g., if the client’s side is disconnected from the network), then this parameter is needed to determine.

For example, if the client is disconnected, but the status of the connection on the server is still ESTABLISHED, in order to confirm that the client is disconnected,

the server needs to send a probe packet every once in a while to confirm that the other party is online. This time is determined by this parameter. It defaults to 7200 seconds and is recommended to be set to 30 seconds.

net.ipv4.tcp_keepalive_intvl

This parameter goes together with the one above. The server initiates a probe to see if the client is online within a specified period of time, and if the client doesn’t confirm it,

at this point, the server can’t conclude that the other party isn’t online, and has to try several times. This parameter defines how long it takes to resend the probe, i.e., how long it takes to initiate the probe again after the first time you realize that there is something wrong with the other side.

The default value is 75 seconds, which can be changed to 3 seconds.

net.ipv4.tcp_keepalive_probes

The 10th and 11th parameters specify when to initiate probes and how long to initiate probes again after a probe fails, but do not define how many probes in total are considered to be finished.

This parameter defines the number of packets for which probing is initiated. The default is 9, and it is recommended that it be set to 2.

Setup and examples

To adjust the kernel parameters under Linux, you can directly edit the configuration file /etc/sysctl.conf, and then execute the sysctl-p command to take effect.

How to set linux kernel parameters from the command line

How to set kernel parameters for Linux

1 How to view kernel parameters

Using the “sysctl-a” command, you can view all the kernel parameters in use. There are many kernel parameters (usually up to 500), which are mainly divided into the following categories according to their prefixes: net.ipv4, net.ipv6, net.core, vm, fs, dev.parport, dev.cdrom, dev.raid, kernel, etc. The same linux, with the same installed linux, can be viewed by using the command “sysctl-a” to view all the kernel parameters being used. The same linux, with different components installed and used in different ways, is using different kernel parameters.

The documentation for all kernel parameters is in /usr/src/linux/Documentation/sysctl, so if you want to know what the kernel parameters say, you can go to that directory and look at the appropriate documentation.

2 Setting Kernel Parameters

Since Linux kernel parameters are stored in memory, they can be changed directly via commands that take effect immediately. They can also be set by file. Both methods are described below.

2.1 Command Setting Methods

This can be accomplished in two ways.

1. Use “sysctl-w parameter name=value”

Suppose we change the value of net.ipv4.ip_forward to 1, use the command “sysctl-wnet.ipv4.ip_forward=1″. forward=1”.

2. Modify the proc file corresponding to the kernel parameters

The kernel parameters are located under /proc/sys/, and the names of the parameters are based on the path to the file, with “/” replaced by “.” instead of “/”. For example, the parameter name for /proc/sys/net/ip_forward is net.ipv4.ip_forward.

Also change the value of net.ipv4.ip_forward to 1, using the command “echo “1 “>/proc/sys/net/ipv4/ip_forward”.

Note that a proc file is not the same as a normal file here. Normally a file becomes a text file after you write to it with echo, but a proc file is still an empty file after echo modifies it.

How to modify the grub configuration under the new kernel linux

1 is manually selected at boot time by pressing the up and down arrow keys the interface will be stuck in the interface to select the kernel

2 automatic selection system defaults to select the latest installation of the kernel. If you want to change the default use of the kernel to modify the configuration file / boot / grub / menu.lst (directly modify grub.conf is also feasible) under the default default is 0 is the first menu options (boot kernel selection menu), changed to 1 is to use the second menu items. timeout indicates the menu waiting time, the unit is seconds.

General optimization of the linux kernel, what parameters need to be optimized

First of all, it is important to know a little bit of all the TCP/IP parameter modification is temporary, because they are located in /PROC/SYS/NET directory, if you want to make the parameters of the long term preservation, can be achieved by editing the /ETC/SYSCTL.CONF file, do not do a detailed description here, only for the Linux’s TCPIP kernel parameter optimization enumerates the relevant parameters:

1. Memory used to define sockets for auto-tuning

2. Default TCP data receive window size (bytes)

3. Maximum TCP data receive window

4. Default TCP send window size

5, Maximum TCP data sending window

6. Maximum number of packets allowed to be sent to the queue when each network interface receives packets at a faster rate than the kernel can process them

7. Defines the maximum listening queue length for each port in the system

8. Interval between retransmitting a probe message if the message does not get a response

9. The maximum number of keepalive probe messages that can be sent before a tcp connection is deemed to have failed, and so on.

Related optimization parameter code:

sh# net.core.wmem_default Default size of memory reserved for sending buffer Default value 16k

# net.core.rmem_default Default size of memory reserved for receiving buffer Default value 16k

# net.core.wmem_ max Maximum amount of memory reserved in send buffer Default 128k

# net.core.rmem_max Maximum amount of memory reserved in receive buffer Default 128k

# net.unix.max_dgram_qlen Inter-process communication to send data, default 10

# net.ipv4.tcp_syncookies

# net.ipv4.syn_retries

# net.ipv4.tcp_fin_timeout Time to keep a socket connection in FIN-WAIT-2 state if it is closed by this end

# net.ipv4.tcp_keepalive_time When keepalive works, tcp sends data to the server. How often tcp sends keepalive messages when keepalive is active, default is 2 hours

# net.ipv4.route_max_size Route cache maximum size.

How to configure oracle11g kernel parameters in linux

After modifying the /etc/sysctl.conf file, execute the command #sysctl-p to take effect immediately

1. kernel.shmmax

Used for defining the maximum value of a single shared memory segment

Shmmax setting should be large enough to accommodate the entire SGA under a single shared memory segment. Setting it too low may

lead to the need to create multiple shared memory segments, which may result in a degradation of system performance.

2. kernel.shmall

Controls the number of shared memory pages.Linux shared memory page size is 4KB, and the size of a shared memory segment is an integer multiple of the shared memory page size.

For example, if the maximum size of a shared memory segment is 16G, then the number of shared memory pages required is 16GB/4KB=16777216KB/4KB=4194304 (pages), which means 16GB of physical memory on a 64Bit system, and setting kernel.shmall=4194304 meets the requirement (which is almost the same as the original setting). 2097152

twice the original setting). At this point, you can adjust the shmmax parameter to 16G, and at the same time, you can modify the SGA_MAX_SIZE and SGA_TARGET to 12G (you want to set the maximum size of the SGA, of course, it can also be 2G ~ 14G, etc., but also to coordinate the use of the PGA parameter and other memory such as OS, can not be set too full, such as 16G).

3, kernel.shmmni

is the maximum number of shared memory segments (note that this parameter is not shmmin, it is shmmni, shmmin indicates the minimum size of the memory segment). shmmni default value of 4096, generally certainly enough.