Linux服务器内核参数优化

ulimit设置

ulimit -n 要调整为100000甚至更大。 命令行下执行 ulimit -n 100000即可修改。如果不能修改,需要设置 /etc/security/limits.conf,加入

* soft nofile 262140
* hard nofile 262140
root soft nofile 262140
root hard nofile 262140
* soft core unlimited
* hard core unlimited
root soft core unlimited
root hard core unlimited

注意,修改limits.conf文件后,需要重启系统生效

内核设置

Linux操作系统修改内核参数有3种方式:

  • 修改/etc/sysctl.conf文件,加入配置选项,格式为key = value,修改保存后调用sysctl -p加载新配置
  • 使用sysctl命令临时修改,如:sysctl -w net.ipv4.tcp_mem=“379008 505344 758016”
  • 直接修改/proc/sys/目录中的文件,如:echo “379008 505344 758016” >
    /proc/sys/net/ipv4/tcp_mem

第一种方式在操作系统重启后会自动生效,第二和第三种方法重启后失效

net.unix.max_dgram_qlen = 100

swoole使用unix socket dgram来做进程间通信,如果请求量很大,需要调整此参数。系统默认为10,可以设置为100或者更大。
或者增加worker进程的数量,减少单个worker进程分配的请求量。

net.core.wmem_max

修改此参数增加socket缓存区的内存大小

net.ipv4.tcp_mem  =   379008       505344  758016
net.ipv4.tcp_wmem = 4096        16384   4194304
net.ipv4.tcp_rmem = 4096          87380   4194304
net.core.wmem_default = 8388608
net.core.rmem_default = 8388608
net.core.rmem_max = 16777216
net.core.wmem_max = 16777216

net.ipv4.tcp_tw_reuse

是否socket reuse,此函数的作用是Server重启时可以快速重新使用监听的端口。如果没有设置此参数,会导致server重启时发生端口未及时释放而启动失败

net.ipv4.tcp_tw_recycle

使用socket快速回收,短连接Server需要开启此参数。此参数表示开启TCP连接中TIME-WAIT sockets的快速回收,Linux系统中默认为0,表示关闭。打开此参数可能会造成NAT用户连接不稳定,请谨慎测试后再开启。

消息队列设置

当使用消息队列作为进程间通信方式时,需要调整此内核参数

  • kernel.msgmnb = 4203520,消息队列的最大字节数
  • kernel.msgmni = 64,最多允许创建多少个消息队列
  • kernel.msgmax = 8192,消息队列单条数据最大的长度

FreeBSD/MacOS

  • sysctl -w net.local.dgram.maxdgram=8192
  • sysctl -w net.local.dgram.recvspace=200000 修改Unix Socket的buffer区尺寸

开启CoreDump

设置内核参数

kernel.core_pattern = /data/core_files/core-%e-%p-%t

通过ulimit -c命令查看当前coredump文件的限制

ulimit -c

如果为0,需要修改/etc/security/limits.conf,进行limit设置。

开启core-dump后,一旦程序发生异常,会将进程导出到文件。对于调查程序问题有很大的帮助
其他重要配置

net.ipv4.tcp_syncookies=1
net.ipv4.tcp_max_syn_backlog=81920
net.ipv4.tcp_synack_retries=3
net.ipv4.tcp_syn_retries=3
net.ipv4.tcp_fin_timeout = 30
net.ipv4.tcp_keepalive_time = 300
net.ipv4.tcp_tw_reuse = 1
net.ipv4.tcp_tw_recycle = 1
net.ipv4.ip_local_port_range = 20000 65000
net.ipv4.tcp_max_tw_buckets = 200000
net.ipv4.route.max_size = 5242880

查看配置是否生效

如:修改net.unix.max_dgram_qlen = 100后,通过

cat /proc/sys/net/unix/max_dgram_qlen

如果修改成功,这里是新设置的值。

不同时开启tcp_timestamps和tcp_tw_recycle的场景描述

FULL NAT下

FULL NAT 在client请求VIP 时,不仅替换了package 的dst ip,还替换了package的 src ip;但VIP 返回给client时也替换了src ip

lvs后端为web服务器。

假如web服务器开启了tcp的tcp_timestamps和tcp_tw_recycle这两个参数。那么存在下面这种情况

RFC1323中有如下一段描述:

An additional mechanism could be added to the TCP, a per-hostcache of
the last timestamp received from any connection.This value could then
be used in the PAWS mechanism to rejectold duplicate segments from
earlier incarnations of theconnection, if the timestamp clock can be
guaranteed to haveticked at least once since the old connection was
open. Thiswould require that the TIME-WAIT delay plus the RTT
togethermust be at least one tick of the sender’s timestamp clock.Such
an extension is not part of the proposal of this RFC.

大概意思是说TCP有一种行为,可以缓存每个连接最新的时间戳,后续请求中如果时间戳小于缓存的时间戳,即视为无效,相应的数据包会被丢弃。意思就是同一个源IP来连接同一个目的端口的数据包时间戳必须是递增的

Linux是否启用这种行为取决于tcp_timestamps和tcp_tw_recycle,因为tcp_timestamps缺省就是开启的,所以当tcp_tw_recycle被开启后,实际上这种行为就被激活了。

现在很多公司都用LVS做负载均衡,通常是前面一台LVS,后面多台后端服务器,这其实就是NAT,当请求到达LVS后,它修改地址数据后便转发给后端服务器,
但不会修改时间戳数据,对于后端服务器来说,请求的源地址就是LVS的地址,加上web端口会复用,所以从后端服务器的角度看,原本不同客户端的请求经过LVS的转发,
就可能会被认为是同一个连接,加之不同客户端的时间可能不一致,所以就会出现时间戳错乱的现象,于是后面的数据包就被丢弃了,
具体的表现通常是是客户端明明发送的SYN,但服务端就是不响应ACK,还可以通过下面命令来确认数据包不断被丢弃的现象

假如LVS地址是222.222.222.222,名字是L

web服务器地址为111.111.111.111,名字是W

比如客户端地址客户端C1地址为100.100.100.101,客户端C2地址为100.100.100.102

假如出现这种情况

13:23:02这个时间点

C1发出的TCP数据包源IP和源端口为100.100.100.101:6332,目标地址和端口是222.222.222.222:80

13:23:05这个时间点

C2发出的TCP数据包源IP和源端口为100.100.100.102:52223,目标地址和端口是222.222.222.222:80

经过LVS的full nat。

假如在13:23:06时刻LVS收到C2的数据包

C2的数据包被转换为

222.222.222.222:52223 ---->111.111.111.111:80

假如在13:23:07时刻LVS收到C1的数据包

C1的数据包被转换为

222.222.222.222:6332 ---->111.111.111.111:80

假如web服务器开启了tcp的tcp_timestamps和tcp_tw_recycle这两个参数。web服务器根据数据包的时间戳

C1的数据包由于时间戳小于目前系统登记的此源IP连接的时间戳,被认为是重传数据,C1的数据包就被丢弃了

(不仅lvs的full nat会出现源地址被替换的情况,一些3层交换机作为负载均衡也会把源地址替换掉)

这个参数默认2.4的内核就禁用了。我们是能不开启就不要开启

注意点

  1. tw_reuse,tw_recycle 必须在客户端和服务端timestamps 开启时才管用(默认打开),其实意思就是假如服务端和客户端两边有一边timestamps没开启。tw_reuse和tw_recycle都没啥作用
  2. tw_reuse 只对客户端起作用,开启后客户端在1s内回收。reuse就是重用time_wait的socket连接。 服务端同一个端口被连接理论上是没限制的。
  3. tw_recycle 对客户端和服务器同时起作用,开启后在 3.5*RTO 内回收,RTO 200ms~ 120s 具体时间视网络状况。
      内网状况比tw_reuse 稍快,公网尤其移动网络大多要比tw_reuse 慢,优点就是能够回收服务端的TIME_WAIT数量

对于客户端

  1. 作为客户端因为有端口65535问题,TIME_OUT过多直接影响处理能力,打开tw_reuse 即可解决,不建议同时打开tw_recycle,帮助不大。
  2. tw_reuse 帮助客户端1s完成连接回收,基本可实现单机6w/s请求,需要再高就增加IP数量吧。
  3. 如果内网压测场景,且客户端不需要接收连接,同时tw_recycle 会有一点点好处。

对于服务端

  1. 打开tw_reuse无效,因为是客户端连接web服务器,服务端肯定不会重用socket去主动连接客户端。这个参数服务器一般用不到,除非web服务器又作为客户端去连接后端数据库才用到。
    但是web服务器作为客户端连接数据库达到6万端口的限制时你的数据库早承受不了压力瘫痪了。一般数据库5000连接数就已经很高了。
    tw_resue这个参数,只有客户端用得到。意思就是重用处于time_wait的socket连接。
  2. 线上环境 tw_recycle 不要打开
    服务器处于NAT 负载后,或者客户端处于NAT后(这是一定的事情,基本公司家庭网络都走NAT);
    公网服务打开就可能造成部分连接失败,内网的话到时可以视情况打开;
    有些负载均衡设备会把timestamp 都给清空,后端web服务器开启不开启tw_recycle都无所谓了。
  3. 服务器TIME_WAIT 高怎么办
    服务器time_wait不用担心,因为我是服务端,是客户端很多IP和端口主动连接我的一个端口,比如连接我的80端口。很可能出现一种情况就是虽然我机器上有10万个time_wait连接。但是我的端口才用到一个80端口。
    不像客户端有端口限制,处理大量TIME_WAIT Linux已经优化很好了,每个处于TIME_WAIT 状态下连接内存消耗很少,
    而且也能通过tcp_max_tw_buckets = 262144 配置最大上限,现代机器一般也不缺这点内存。

总之,生产中服务器不管有没有在nat设备后面.

tcp_tw_recycle不开启就行了。默认就是不开启的状态,值为0
tcp_timestamps保持默认开启就行了,值为1
tcp_tw_reuse.客户端最好开启。负载均衡设备连接web服务器时,辅助均衡设备也尽量开启

关于服务器端出现大量time_wait,有些人会问,我是web服务器端,为什么会出现客户端那种time_wait。

其实关于time_wait,它是出现在主动请求关闭连接的那一段。 服务器主动关闭http的连接。它就转变为了客户端。

发起断开连接这个动作,不是说就一定是客户端发起断开的。很多时候都是服务器端先发起断开连接操作。比如很多http服务器,短连接。很多时候服务器主动断开。

服务出现tcp连接问题可以先查看下下面,看看是否有很多,很多时候就是开启了tcp_tw_recycle导致的

[root@localhost ~]$ netstat -s | grep timestamp
    351 packets rejects in established connections because of timestamp
[root@localhost ~]$

客户端相关优化的地方如下。(服务器不开启tcp_tw_recycle即可)

[root@B ~]# cat /proc/sys/net/ipv4/ip_local_port_range
32768   61000
[root@B ~]# cat /proc/sys/net/ipv4/tcp_timestamps
1
[root@B ~]# cat /proc/sys/net/ipv4/tcp_tw_recycle
0
[root@B ~]# cat /proc/sys/net/ipv4/tcp_tw_reuse
0
[root@B ~]# echo 1 > /proc/sys/net/ipv4/tcp_tw_reuse
[root@B ~]# cat /proc/sys/net/ipv4/tcp_tw_reuse
1
[root@B ~]# echo "10240  62000" > /proc/sys/net/ipv4/ip_local_port_range
[root@B ~]# cat /proc/sys/net/ipv4/ip_local_port_range
10240   62000
[root@B ~]#

文档涉及的Linux内核参数说明

文档涉及的Linux内核参数说明如下,可参考如下参数说明进行相关操作。

参数 描述
net.core.rmem_default 默认的TCP数据接收窗口大小(字节)。
net.core.rmem_max 最大的TCP数据接收窗口(字节)。
net.core.wmem_default 默认的TCP数据发送窗口大小(字节)。
net.core.wmem_max 最大的TCP数据发送窗口(字节)。
net.core.netdev_max_backlog 当内核处理速度比网卡接收速度慢时,这部分多出来的包就会被保存在网卡的接收队列上,而该参数说明了这个队列的数量上限。在每个网络接口接收数据包的速率比内核处理这些包的速率快时,允许送到队列的数据包的最大数目。
net.core.somaxconn 该参数定义了系统中每一个端口最大的监听队列的长度,是个全局参数。该参数和net.ipv4.tcp_max_syn_backlog有关联,后者指的是还在三次握手的半连接的上限,该参数指的是处于ESTABLISHED的数量上限。若您的ECS实例业务负载很高,则有必要调高该参数。listen(2)函数中的参数backlog 同样是指明监听的端口处于ESTABLISHED的数量上限,当backlog大于net.core.somaxconn时,以net.core.somaxconn参数为准。
net.core.optmem_max 表示每个套接字所允许的最大缓冲区的大小。
net.ipv4.tcp_mem 确定TCP栈应该如何反映内存使用,每个值的单位都是内存页(通常是4KB)。
第一个值是内存使用的下限。
第二个值是内存压力模式开始对缓冲区使用应用压力的上限。
第三个值是内存使用的上限。在这个层次上可以将报文丢弃,从而减少对内存的使用。对于较大的BDP可以增大这些值(注:其单位是内存页而不是字节)。
net.ipv4.tcp_rmem 为自动调优定义Socket使用的内存。
第一个值是为Socket接收缓冲区分配的最少字节数。
第二个值是默认值(该值会被rmem_default覆盖),缓冲区在系统负载不重的情况下可以增长到这个值。
第三个值是接收缓冲区空间的最大字节数(该值会被rmem_max覆盖)。
net.ipv4.tcp_wmem 为自动调优定义Socket使用的内存。
第一个值是为Socket发送缓冲区分配的最少字节数。
第二个值是默认值(该值会被wmem_default覆盖),缓冲区在系统负载不重的情况下可以增长到这个值。
第三个值是发送缓冲区空间的最大字节数(该值会被wmem_max覆盖)。
net.ipv4.tcp_keepalive_time TCP发送keepalive探测消息的间隔时间(秒),用于确认TCP连接是否有效。
net.ipv4.tcp_keepalive_intvl 探测消息未获得响应时,重发该消息的间隔时间(秒)。
net.ipv4.tcp_keepalive_probes 在认定TCP连接失效之前,最多发送多少个keepalive探测消息。
net.ipv4.tcp_sack 启用有选择的应答(1表示启用),通过有选择地应答乱序接收到的报文来提高性能,让发送者只发送丢失的报文段,(对于广域网通信来说)这个选项应该启用,但是会增加对CPU的占用。
net.ipv4.tcp_fack 启用转发应答,可以进行有选择应答(SACK)从而减少拥塞情况的发生,这个选项也应该启用。
net.ipv4.tcp_timestamps TCP时间戳(会在TCP包头增加12B),以一种比重发超时更精确的方法(参考RFC 1323)来启用对RTT的计算,为实现更好的性能应该启用这个选项。
net.ipv4.tcp_window_scaling 启用RFC 1323定义的window scaling,要支持超过64KB的TCP窗口,必须启用该值(1表示启用),TCP窗口最大至1GB,TCP连接双方都启用时才生效。
net.ipv4.tcp_syncookies 该参数表示是否打开TCP同步标签(SYN_COOKIES),内核必须开启并编译CONFIG_SYN_COOKIES,SYN_COOKIES可以防止一个套接字在有过多试图连接到达时,引起过载。默认值0表示关闭。
当该参数被设置为1,且SYN_RECV队列满了之后,内核会对SYN包的回复做一定的修改,即在响应的SYN+ACK包中,初始的序列号是由源IP+Port、目的IP+Port及时间这五个参数共同计算出一个值组成精心组装的TCP包。由于ACK包中确认的序列号并不是之前计算出的值,恶意攻击者无法响应或误判,而请求者会根据收到的SYN+ACK包做正确的响应。启用net.ipv4.tcp_syncookies后,会忽略net.ipv4.tcp_max_syn_backlog。
net.ipv4.tcp_tw_reuse 表示是否允许将处于TIME-WAIT状态的Socket(TIME-WAIT的端口)用于新的TCP连接。
net.ipv4.tcp_tw_recycle 能够更快地回收TIME-WAIT套接字。
net.ipv4.tcp_fin_timeout 对于本端断开的Socket连接,TCP保持在FIN-WAIT-2状态的时间(秒)。对方可能会断开连接或一直不结束连接或不可预料的进程死亡。
net.ipv4.ip_local_port_range 表示TCP/UDP协议允许使用的本地端口号。
net.ipv4.tcp_max_syn_backlog 该参数决定了系统中处于SYN_RECV状态的TCP连接数量。SYN_RECV状态指的是当系统收到SYN后,作为SYN+ACK响应后等待对方回复三次握手阶段中的最后一个ACK的阶段。对于还未获得对方确认的连接请求,可保存在队列中的最大数目。如果服务器经常出现过载,可以尝试增加这个数字。默认为1024。
net.ipv4.tcp_low_latency 允许TCP/IP栈适应在高吞吐量情况下低延时的情况,这个选项应该禁用。
net.ipv4.tcp_westwood 启用发送者端的拥塞控制算法,它可以维护对吞吐量的评估,并试图对带宽的整体利用情况进行优化,对于WAN通信来说应该启用这个选项。
net.ipv4.tcp_bic 为快速长距离网络启用Binary Increase Congestion,这样可以更好地利用以GB速度进行操作的链接,对于WAN通信应该启用这个选项。
net.ipv4.tcp_max_tw_buckets 该参数设置系统的TIME_WAIT的数量,如果超过默认值则会被立即清除。默认为180000。
net.ipv4.tcp_synack_retries 指明了处于SYN_RECV状态时重传SYN+ACK包的次数。
net.ipv4.tcp_abort_on_overflow 设置该参数为1时,当系统在短时间内收到了大量的请求,而相关的应用程序未能处理时,就会发送Reset包直接终止这些链接。建议通过优化应用程序的效率来提高处理能力,而不是简单地Reset。默认值为0。
net.ipv4.route.max_size 内核所允许的最大路由数目。
net.ipv4.ip_forward 接口间转发报文。
net.ipv4.ip_default_ttl 报文可以经过的最大跳数。
net.netfilter.nf_conntrack_tcp_timeout_established 在指定之间内,已经建立的连接如果没有活动,则通过iptables进行清除。
net.netfilter.nf_conntrack_max 哈希表项最大值。

参考文章:
http://www.easyswoole.com/Cn/Other/kernelOptimization.html
https://www.cnblogs.com/nmap/p/6435057.html
https://help.aliyun.com/knowledge_detail/41334.html#h2–linux-

猜你喜欢

转载自blog.csdn.net/uisoul/article/details/104513883