TCP内核参数与Nginx配置的简单测试

tcp,内核,参数,nginx,配置,简单,测试 · 浏览次数 : 244

小编点评

#生成内容时需要带简单的排版 #1. 创建一个简单的排版 ``` #内容 #内容 #内容 ``` #2. 在排版中添加简单的描述 ``` #内容 #内容 #内容 #内容 #内容 #内容 ``` #3. 编写内容时使用简单的描述 ``` #内容 #内容 #内容 #内容 #内容 #内容 ``` #4. 编写内容时使用简单的描述 ``` #内容 #内容 #内容 #内容 #内容 #内容 ``` #5. 测试内容的正确性 ``` #内容 #内容 #内容 #内容 #内容 #内容 ``` #6. 修改排版的描述 ``` #内容 #内容 #内容 #内容 #内容 #内容 #内容 #内容 #内容 #内容 #内容 ```

正文

背景

昨天晚上整理了下几个TCP内核的参数.
学习到了一点内核参数的影响.
但是因为时间比较晚了没有继续钻研与nginx的关系
今天想着继续研究一下TCP的部分参数与nginx的关系 
每个系统都不一样. 结果可能跟内核版本和内核参数强相关.
我这里用的是基于ARM的银河麒麟
还有基于x86的OpenEuler
内核版本都比较高

测试机器信息

1. 域名站点
aarch64  
银河麒麟V10SP3
8c 64g
内核: 4.19.90-52.15.v2207.ky10.aarch64

2. 微服务方向代理节点
x86_64
OpenEuler 2203 LTS
16c 96g
内核: 5.10.0-60.18.0.50.oe2203.x86_64

测试点

1. keepalive对域名和应用服务器的影响.
2. 内核参数 ip_local_port_range 对nginx的response code 的影响

Nginx的keepalive的设置

Nginx最常用的是两种模式:
1. Nginx作为web服务器进行使用
   是一个纯粹的Server服务.只需要关注他与客户端的连接就可以了. 
2. Nginx作为反向代理的实现
   此时Nginx不仅是一个Server服务, 对于upstream的服务器还是
   一个client. 
基于如上两个配置:
Nginx的keepalive 的设置也分为两个地方
一个是http时的keepalive设置
另外一个是 upstream 上面的keepalive的设置

Nginx的测试

http的keepalive的设置效果
Nginx的http配置节下面可以使用如下命令进行设置
keepalive_timeout 0;
单位是秒钟, 设置为0 表示禁用长连接. 

进行测试:
注意每次测试都至少间隔 1min 保证上一次测试的 time_wait 都进行了释放. 
先禁用为0 
打开 界面:https://10.110.136.50/
查看TCP链接的情况:
[root@KylinV10SP3ARM64 nginx]#  netstat -anop |grep tcp |grep -v LISTEN |grep -v 637 |grep -v 8848 |grep -v 1521 |grep -v tcp6 |grep -v :22  |grep 10.110.81.124
tcp        0      0 10.110.136.50:443       10.110.81.124:57491     TIME_WAIT   -                    timewait (57.65/0/0)
tcp        0      0 10.110.136.50:443       10.110.81.124:57492     TIME_WAIT   -                    timewait (57.45/0/0)
# 发现只有两个 time_wait的连接
打开登录界面: https://10.110.136.50/login.html
# 至少会有 20个time_wait的连接. 
# 如果是刷新 产生20个time_wait的连接, 如果是全新打开, 产生73个time_wait的连接. 
# 数量太多就不在一一展示了. 


Nginx的测试

修改为: keepalive_timeout 10;
然后再次进行测试
注意需要重启nginx 不要使用 -s reload的模式. 

发现打开登录:https://10.110.136.50/ 还有 https://10.110.136.50/login.html
都是两个 established 的连接. 

但是很快就变成了FIN_WAIT 然后TCP连接很快就消失了.
而且明显感觉 10秒钟最后就已经全部没有了. 
[root@KylinV10SP3ARM64 nginx]#  netstat -anop |grep tcp |grep -v LISTEN |grep -v 637 |grep -v 8848 |grep -v 1521 |grep -v tcp6 |grep -v :22  |grep 10.110.81.124  
tcp        0      0 10.110.136.50:443       10.110.81.124:59809     ESTABLISHED 2532685/nginx: work  off (0.00/0/0)
tcp        0      0 10.110.136.50:443       10.110.81.124:59810     ESTABLISHED 2532685/nginx: work  off (0.00/0/0)
[root@KylinV10SP3ARM64 nginx]#  netstat -anop |grep tcp |grep -v LISTEN |grep -v 637 |grep -v 8848 |grep -v 1521 |grep -v tcp6 |grep -v :22  |grep 10.110.81.124  
tcp        0      0 10.110.136.50:443       10.110.81.124:59809     FIN_WAIT2   -                    timewait (39.81/0/0)
tcp        0      0 10.110.136.50:443       10.110.81.124:59810     FIN_WAIT2   -                    timewait (39.59/0/0)

Upstream 的 keepalive 的测试

Upstream 不设置 keepalive的测试
域名层的nginx 会没次刷新多一个 TIME_WAIT的连接. 
[root@CentOS7MINI nginx]# netstat -anop |grep tcp |grep -v LISTEN |grep -v :637 |grep -v :884 |grep -v :1521 |grep -v tcp6 |grep -v :22 |grep -v 127.0.0.1 |grep 10.110.139.230
tcp        0      0 10.110.139.181:65176    10.110.139.230:5200     TIME_WAIT   -                    timewait (58.09/0/0)
tcp        0      0 10.110.139.181:64752    10.110.139.230:5200     TIME_WAIT   -                    timewait (55.55/0/0)
tcp        0      0 10.110.139.181:23646    10.110.139.230:5200     TIME_WAIT   -                    timewait (42.51/0/0)
tcp        0      0 10.110.139.181:64984    10.110.139.230:5200     TIME_WAIT   -                    timewait (56.86/0/0)
tcp        0      0 10.110.139.181:65142    10.110.139.230:5200     TIME_WAIT   -                    timewait (57.37/0/0)
tcp        0      0 10.110.139.181:65374    10.110.139.230:5200     ESTABLISHED 2340/nginx: worker   off (0.00/0/0)

第二层方向代理会产生更多的TIME_WAIT的连接
一次登录和退出会生产非常多的time_wait的信息:
打开登录界面 10个time_wait
登录成功:    17个time_wait
退出登录:    13个time_wait
[root@openeuler2203 ~]# netstat -anop |grep tcp |grep -v LISTEN |grep -v :637 |grep -v :884 |grep -v :1521 |grep -v tcp6 |grep -v :22 |grep 10.110.139.181
tcp        0      0 10.110.139.230:5200     10.110.139.181:28270    TIME_WAIT   -                    timewait (43.00/0/0)
tcp        0      0 10.110.139.230:5200     10.110.139.181:28502    TIME_WAIT   -                    timewait (44.91/0/0)
tcp        0      0 10.110.139.230:5200     10.110.139.181:26174    TIME_WAIT   -                    timewait (57.03/0/0)
tcp        0      0 10.110.139.230:5200     10.110.139.181:28506    TIME_WAIT   -                    timewait (44.93/0/0)
tcp        0      0 10.110.139.230:5200     10.110.139.181:28452    TIME_WAIT   -                    timewait (44.71/0/0)
tcp        0      0 10.110.139.230:5200     10.110.139.181:28478    TIME_WAIT   -                    timewait (44.91/0/0)
tcp        0      0 10.110.139.230:5200     10.110.139.181:26158    TIME_WAIT   -                    timewait (57.02/0/0)
tcp        0      0 10.110.139.230:5200     10.110.139.181:28440    TIME_WAIT   -                    timewait (44.70/0/0)
tcp        0      0 10.110.139.230:5200     10.110.139.181:28268    TIME_WAIT   -                    timewait (42.99/0/0)
tcp        0      0 10.110.139.230:5200     10.110.139.181:51306    TIME_WAIT   -                    timewait (36.06/0/0)
tcp        0      0 10.110.139.230:5200     10.110.139.181:28514    TIME_WAIT   -                    timewait (44.99/0/0)
tcp        0      0 10.110.139.230:5200     10.110.139.181:28564    TIME_WAIT   -                    timewait (45.20/0/0)
tcp        0      0 10.110.139.230:5200     10.110.139.181:26148    TIME_WAIT   -                    timewait (56.93/0/0)
tcp        0      0 10.110.139.230:5200     10.110.139.181:28466    TIME_WAIT   -                    timewait (44.74/0/0)
tcp        0      0 10.110.139.230:5200     10.110.139.181:26186    TIME_WAIT   -                    timewait (57.06/0/0)

Upstream 的 keepalive 的测试

在upstream里面增加设置
keepalive  32; 
并且在 location 里面设置 
proxy_http_version 1.1;

然后重启nginx

需要注意的是:
在当前服务器只会看到一个 tcp 对中间层nginx的连接
但是中间nginx的连接
会产生 20个time-wait 的连接. 

TCP内核的验证

image


TCP内核验证出现502错误的过程

sysctl -w "net.ipv4.ip_local_port_range=6000 6001"

然后登录nginx 所在的服务器
使用两个客户端打开 或者是打开具体个功能
F12会立即发现有很多的502 badgates 的提示信息. 

也就验证出 如果time_wait+eslabished 的连接数大于 ip_local_port_range 
的范围的话 有极大的概率出现 502的问题. 

注意这个修改完之后 需要立即改回来 不然会出现严重的问题. 

与 TCP内核参数与Nginx配置的简单测试相似的内容:

TCP内核参数与Nginx配置的简单测试

背景 昨天晚上整理了下几个TCP内核的参数. 学习到了一点内核参数的影响. 但是因为时间比较晚了没有继续钻研与nginx的关系 今天想着继续研究一下TCP的部分参数与nginx的关系 每个系统都不一样. 结果可能跟内核版本和内核参数强相关. 我这里用的是基于ARM的银河麒麟 还有基于x86的Open

TCP内核参数的简单验证

前言 春节假期时学习了下内核参数与nginx的调优 最近因为同事遇到问题一直没有解,自己利用晚上时间再次进行验证. 这里将几个参数的理解和验证结果简单总结一下. 希望能够在学习的过程中将问题解决掉. 其实很后悔没有好好学习代码.现在很多问题都已经到了瓶颈期 无法深入的研究下去. 参数一 net.ip

【转帖】TCP内核参数

https://www.cnblogs.com/chia/p/7799231.html tcp_syn_retries :INTEGER默认值是5对于一个新建连接,内核要发送多少个 SYN 连接请求才决定放弃。不应该大于255,默认值是5,对应于180秒左右时间。(对于大负载而物理通信良好的网络而言

[转帖]内核 TCP 参数调优

https://cloud.tencent.com/developer/article/1993859?areaSource=&traceId= Linux系统下,TCP连接断开后,会以 TIME_WAIT 状态保留一定时间,然后才释放端口。当并发请求过多时,会产生大量 TIME_WAIT 状态连接

[转帖]内核参数优化

net.ipv4.tcp_timestamps= 1 #服务器时间截,默念为1 net.ipv4.tcp_tw_reuse= 1 #服务器作为客户端时起作用,开启后time_wait在一秒内回收,(两端都要开启tw_timestamps=1时才有效) net.ipv4.tcp_tw_recycle=

[转帖]Linux内核参数net.ipv4.ip_local_port_range对服务器连接数影响的正确解释

首先明确一下该参数的意义:net.ipv4.ip_local_port_range表示本机作为客户端对外发起tcp/udp连接时所能使用的临时端口范围。 对于TCP连接,本机所能发起的tcp连接数受四元组(源地址*源端口*目标地址*目标端口)限制。 而对于UDP连接,本机所能发起的udp连接数则受二

[转帖]一个简单的内核参数优化

一个简单的内核参数优化 作者:孤风孤影 https://www.bilibili.com/read/cv15200947/ 出处:bilibili net.ipv4.tcp_keepalive_time=600 #此参数表示TCP发送keepalive探测消息的间隔时间(秒) net.ipv4.tc

[转帖]k8s实践指南-排错案例-tcp_tw_recycle 引发丢包

https://www.oomspot.com/post/k8sshijianzhinanpaicuoanlitcptwrecycleyinfadiubao tcp_tw_recycle 引发丢包 tcp_tw_recycle 这个内核参数用来快速回收 TIME_WAIT 连接,不过如果在 NAT

[转帖]Linux内核调优

Linux服务器调优 转载于:https://blog.csdn.net/largetalk/article/details/16863689 安装一台新的Linux服务器之后都要做些配置调整工作,优化一下系统,以前零零碎碎记录过一些,这里集中整理一下。 Linux内核参数 net.ipv4.tcp

[转帖]Linux内核 TCP/IP、Socket参数调优

文章系转载,便于整理和分类,原文地址:http://www.360doc.com/content/14/0606/16/3300331_384326124.shtml Doc1: /proc/sys/net目录 所有的TCP/IP参数都位于/proc/sys/net目录下(请注意,对/proc/sy