linux内核参数其实一般不改也没关系,一般公司的业务服务器很少会突破默认的kernel限制,但是对于一些特殊应用如nginx之类业务入口或者高并发服务器,如果出现性能问题导致故障,其实挺难查的,所以记录一下日常遇到过的一些优化方案。
控制内核向已经建立连接的远程主机重新发送数据的次数,低值可以更早的检测到与远程主机失效的连接,因此服务器可以更快的释放该连接,可以修改为5,默认为15,大约再13-30min,改为5大概在3-6min.
假设应用没有设置TCP重传次数,就会走kernel的默认配置,比如中间件的监听等,就会导致一旦服务端挂了,客户端没有快速将资源回收,在一般场景下可能会导致应用的阻塞
对于还未获得对方确认的连接请求,可保存在队列中的最大数目。如果服务器经常出现过载,可以尝试增加这个数字,生产一般2048就够了。可以关注netstat的syn_wait字段, 这里是半连接上限
对于本端断开的socket连接,TCP保持在FIN-WAIT-2状态的时间(秒)。对方可能会断开连接或一直不结束连接或不可预料的进程死亡。
开启syn cookies,如果SYN队列满了会启用cookie处理。1表示
表示是否允许将处于TIME-WAIT状态的socket(TIME-WAIT的端口)用于新的TCP连接,tcp复用
TIME-WAIT状态的socket快速回收,1打开
7.tcp_fin_timeout
保持在FIN-WAIT-2状态的时间(秒)。对方可能会断开连接或一直不结束连接或不可预料的进程死亡,默认60 设置为30
TCP发送keepalive探测消息的间隔时间(秒),用于确认TCP连接是否有效,默认7200,改为1800
探测消息未获得响应时,重发该消息的间隔时间(秒)默认75,建议30
在认定TCP连接失效之前,最多发送多少个keepalive探测消息,默认9 建议3
最大追踪conntrack的条目量,一般设置是 RAMSIZE (in bytes) / 16384 / (ARCH / 64)
conntrack追踪的各个状态的时间,一般根据当前链接进行修改,单位是s
常见于redis的优化和一些webapp的优化,表示socket监听(listen)的backlog上限backlog是socket的监听队列,当一个请求(request)尚未被处理或建立时,他会进入backlog,一旦这个队列满了,接下来的请求会被拒绝,一般redis处理消息性能赶不上的时候,会有类似问题,这里是全连接上限
0, 表示内核将检查是否有足够的可用内存供应用进程使用;如果有足够的可用内存,内存申请允许;否则,内存申请失败,并把错误返回给应用进程。
1, 表示内核允许分配所有的物理内存,而不管当前的内存状态如何。
2, 表示内核允许分配超过所有物理内存和交换空间总和的内存
redis dump的时候也会使用一段内存,只根据redis配置里的使用内存可能会导致性能问题
Transparent Huge Pages (THP)是一种Linux内存管理系统,可以通过使用更大的内存页来减少对带有大量内存的机器Translation Lookaside Buffer (TLB)的开销
tcp 全连接满了之后,默认是0,表示来的连接直接丢弃,1表示reset
为自动调优定义socket使用的内存。第一个值是为socket接收缓冲区分配的最少字节数;第二个值是默认值(该值会被rmem_default覆盖),缓冲区在系统负载不重的情况下可以增长到这个值;第三个值是接收缓冲区空间的最大字节数(该值会被rmem_max覆盖)。