前言

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

参数一

  • net.ipv4.tcp_max_tw_buckets
先说一下基本的结论:
CentOS默认的值: 262144
阿里云虚拟机的默认值: 5000
华为云虚拟机的默认值: 5000
腾讯云虚拟机的默认值: 131072 在简单描述一下这个参数的作用:
在 TIME_WAIT 数量等于 tcp_max_tw_buckets 时,
不会有新的 TIME_WAIT 产生。 类似 Nginx 之类的中间代理一定要关注这个值,因为它对你的系统起到一个保护的作用,
一旦端口全部被占用,服务就异常了。
tcp_max_tw_buckets 能帮你降低这种情况的发生概率,争取补救时间。
学习来源: https://www.jianshu.com/p/b7e991be0909 我这边理解就类似于 JVM里面GC over limited的处理机制相仿.
能够快速重用部分端口, 避免无端口可用无法建立新连接.

参数二

  • net.ipv4.ip_local_port_range
这个参数 云计算和CentOS的默认值出奇的一致:
32768 60999
第一个参数代表随机端口的下限
第二个参数代表建立TCP连接时端口的上限
C10K甚至是C100K的很多优化里面都是需要改这个参数的 TCP是有四元素 local_ip local_port remote_ip remote_port
来唯一确认一个TCP连接的.
理论上一个TCP的LISTEN的监听端口可以建立很多个TCP连接的.

参数三

  • net.ipv4.tcp_tw_reuse
个人感觉这个参数其实是存在一定风险的
可能会导致错误的TCP连接.
但是理论上 linux内核有TCP状态的检验还有TCP的序列号进行串行化处理
几乎零可能性的出现严重的数据问题.

一个简单的进行验证的脚本

echo "443:" `netstat -anop |grep tcp |grep -v LISTEN |grep -v 637 |grep -v 884 |grep -v 1521 |grep -v tcp6 |grep -v :22 |grep :443 |awk '{++state[$6]} END {for(key in state) print key,state[key]}'`
echo "5000:" `netstat -anop |grep tcp |grep -v LISTEN |grep -v 637 |grep -v 884 |grep -v 1521 |grep -v tcp6 |grep -v :22 |grep :5000 |awk '{++state[$6]} END {for(key in state) print key,state[key]}'`
echo "5200:" `netstat -anop |grep tcp |grep -v LISTEN |grep -v 637 |grep -v 884 |grep -v 1521 |grep -v tcp6 |grep -v :22 |grep :520 |awk '{++state[$6]} END {for(key in state) print key,state[key]}'` 可以定量分析不同端口的连接信息.

内核参数的验证-1

修改内核参数
sysctl -w "net.ipv4.tcp_max_tw_buckets=50000"
登录系统进行分析查看time wait的TCP数量.
[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 :5200
tcp 0 0 10.110.139.230:5200 10.110.136.50:57506 TIME_WAIT - timewait (0.71/0/0)
tcp 0 0 10.110.139.230:5200 10.110.136.50:37506 TIME_WAIT - timewait (57.65/0/0)
tcp 0 0 10.110.139.230:5200 10.110.136.50:37604 TIME_WAIT - timewait (57.94/0/0)
tcp 0 0 10.110.139.230:5200 10.110.136.50:57490 TIME_WAIT - timewait (0.70/0/0)
tcp 0 0 10.110.139.230:5200 10.110.136.50:37708 TIME_WAIT - timewait (58.02/0/0)
tcp 0 0 10.110.139.230:5200 10.110.136.50:37696 TIME_WAIT - timewait (58.02/0/0)
tcp 0 0 10.110.139.230:5200 10.110.136.50:37630 TIME_WAIT - timewait (57.96/0/0)
tcp 0 0 10.110.139.230:5200 10.110.136.50:57538 TIME_WAIT - timewait (0.75/0/0) 发现会有40条 time wait的 tcp连接.
最后一列是等待终结的time wait的tcp连接 等到所有的连接都停止后再次修改内核参数
sysctl -w "net.ipv4.tcp_max_tw_buckets=10"
# 注意我这种修改仅是验证问题, 没有生产适用性.
# 注意每次测试至少要等待60秒等待之前的tcp连接终结. 再次执行登录简单测试,效果为:
[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 :5200
tcp 0 0 10.110.139.230:5200 10.110.136.50:59150 ESTABLISHED 716321/nginx: worke off (0.00/0/0) 发现没有再次生成 time wait的连接
# 注意这个参数是整个操作系统所有的time_wait的连接数 不单纯是一个端口的. 所以10个肯定是不够用的.

内核参数验证-2

直接修改参数:
sysctl -w "net.ipv4.ip_local_port_range=3000 4000"
# 注意结果可以与内核参数验证-1 里面的结果进行对照.
# 注意需要修改回 bucket的数据避免测试失效.
[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.139.230
tcp 0 0 10.110.136.50:3508 10.110.139.230:5200 ESTABLISHED 3872246/nginx: work off (0.00/0/0)
tcp 0 0 10.110.136.50:31062 10.110.139.230:5200 TIME_WAIT - timewait (51.06/0/0)
注意可以再次修改一下 端口信息再次进行验证
sysctl -w "net.ipv4.ip_local_port_range=5000 5100"
测试结果为:
[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.139.230
tcp 0 0 10.110.136.50:5096 10.110.139.230:5200 ESTABLISHED 3872246/nginx: work off (0.00/0/0)
tcp 0 0 10.110.136.50:3508 10.110.139.230:5200 TIME_WAIT - timewait (55.94/0/0)
仅仅是执行了一下刷新动作.
就会看到上面一个3508 local 的本地端口开始进入time_wait状态
新建立的连接的local_port 就是 5096
sysctl -w "net.ipv4.ip_local_port_range=5000 5050"
效果也是完全一致符合猜测.
[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.139.230
tcp 0 0 10.110.136.50:5096 10.110.139.230:5200 TIME_WAIT - timewait (56.10/0/0)
tcp 0 0 10.110.136.50:5008 10.110.139.230:5200 ESTABLISHED 3872246/nginx: work off (0.00/0/0) # 需要注意 修改改端口仅影响 第四列的本地连接信息, 不会影响第五列的外部连接信息
# 外部的需要是一个 监听端口为主.

TCP内核参数的简单验证的更多相关文章

  1. TCP三次握手与Linux的TCP内核参数优化

    感谢各位技术大佬的资料分享,这里我把我理解的内容做一个整理 一:TCP的三次握手 1.TCP简述 TCP是一个面向连接的协议,在连接双方发送数据之前,首先需要建立一条连接.TCP建立连接可以简单称为: ...

  2. 修改tcp内核参数:somaxconn

    修改somaxconn 该内核参数默认值一般是128(定义了系统中每一个端口最大的监听队列的长度),对于负载很大的服务程序来说大大的不够.一般会将它修改为2048或者更大. echo 2048 > ...

  3. TCP内核参数

    tcp_syn_retries :INTEGER默认值是5对于一个新建连接,内核要发送多少个 SYN 连接请求才决定放弃.不应该大于255,默认值是5,对应于180秒左右时间.(对于大负载而物理通信良 ...

  4. linux内核参数sysctl.conf,TCP握手ack,洪水攻击syn,超时关闭wait

    题记:优化Linux内核sysctl.conf参数来提高服务器并发处理能力 PS:在服务器硬件资源额定有限的情况下,最大的压榨服务器的性能,提高服务器的并发处理能力,是很多运维技术人员思考的问题.要提 ...

  5. linux内核参数sysctl.conf,TCP握手ack,洪水攻击syn,超时关闭wait(转)

    http://www.xshell.net/linux/Linux_sysctl_conf.html 优化Linux内核sysctl.conf参数来提高服务器并发处理能力 Posted by 破冰 o ...

  6. Linux上TCP的几个内核参数调优

    Linux作为一个强大的操作系统,提供了一系列内核参数供我们进行调优.光TCP的调优参数就有50多个.在和线上问题斗智斗勇的过程中,笔者积累了一些在内网环境应该进行调优的参数.在此分享出来,希望对大家 ...

  7. tcp ip参数详解

    http://www.cnblogs.com/digdeep/p/4869010.html 1. TCP/IP模型 我们一般知道OSI的网络参考模型是分为7层:“应表会传网数物”——应用层,表示层,会 ...

  8. nginx的linux服务器内核参数调整【转】

    概述 由于默认的linux内核参数考虑的是最通用场景,这明显不符合用于支持高并发访问的Web服务器的定义,所以需要修改Linux内核参数,让Nginx可以拥有更高的性能: 在优化内核时,可以做的事情很 ...

  9. 转载:Linux内核参数的优化(1.3.4)《深入理解Nginx》(陶辉)

    原文:https://book.2cto.com/201304/19615.html 由于默认的Linux内核参数考虑的是最通用的场景,这明显不符合用于支持高并发访问的Web服务器的定义,所以需要修改 ...

  10. Linux(Centos )的网络内核参数优化来提高服务器并发处理能力【转】

    简介 提高服务器性能有很多方法,比如划分图片服务器,主从数据库服务器,和网站服务器在服务器.但是硬件资源额定有限的情况下,最大的压榨服务器的性能,提高服务器的并发处理能力,是很多运维技术人员思考的问题 ...

随机推荐

  1. KubeEdge和Kuiper“双剑合并”,轻松解决边缘流式数据处理

    摘要:KubeEdge 是一个开源的边缘计算平台,它在Kubernetes原生的容器编排和调度能力之上,扩展实现了 云边协同.计算下沉.海量边缘设备管理.边缘自治等能力.KubeEdge还将通过插件的 ...

  2. Nacos是什么?

    摘要:Nacos是 Dynamic Naming and Configuration Service的首字母简称,相较之下,它更易于构建云原生应用的动态服务发现.配置管理和服务管理平台. 本文分享自华 ...

  3. Python图像处理丨两种实现图像形态学转化运算

    摘要:本篇文章主要讲解Python调用OpenCV实现图像形态学转化,包括图像顶帽运算和图像黑帽运算. 本文分享自华为云社区<[Python图像处理] 十.形态学之图像顶帽运算和黑帽运算> ...

  4. 云图说|每个成功的业务系统都离不开APIG的保驾护航

    摘要:华为云API网关(APIG)是为企业开发者及合作伙伴提供的高性能.高可用.高安全的API托管服务, 帮助企业轻松构建.管理和部署不同规模的API. 本文分享自华为云社区<[云图说]第243 ...

  5. 近数据处理(NDP)——GaussDB(for MySQL)性能提升的秘密

    摘要:云堆栈的深度集成是释放云数据库力量的关键,华为云在实现这一目标方面处于领先地位,正如GaussDB(for MySQL)所证明的那样. 本文分享自华为云社区<近数据处理(NDP),为Gau ...

  6. iOS分发证书过期或手动吊销,会影响App的下架吗?

    ​ iOS distribution发布证书过期或者被手动revoke了app会被下架吗? 在距离distribution 证书过期一个月(或被手动revoke了)的时候会受到apple的邮件 ​编辑 ...

  7. 抖音APP如何实现用户生命周期提升

    > 更多技术交流.求职机会,欢迎关注字节跳动数据平台微信公众号,回复[1]进入官方交流群 近日,在火山引擎数智平台在北京举办的"超话数据:企业产品优化分享"的活动上,抖音策略 ...

  8. HanLP — 路径规划算法 - 求解最短路径 - 维特比(Viterbi)算法

    维特比算法:从众多路径中,挑出最优的那条,他和隐马尔可夫没有强关联 中文分词任务 语料库 => 训练集 初始.转移.发射矩阵 => 训练过程 维特比算法,得到真正结果 训练的时候,是用不到 ...

  9. CountDownLatch、CyclicBarrier 使用区别

    主要区别 CountDownLatch:所有子线程完成后,再执行主线程 CyclicBarrier: 所有子线程就绪后,再执行子线程 CountDownLatch 所有子线程完成后,再执行主线程 多线 ...

  10. PPT 用图片轻松做出高大上的精修

    PPT 用图片轻松做出高大上的精修 图片留白充分 图片很花 文字和图片中间,插入一个透明背景 单图片型 放大+色块 左右分割 上下分割 用一个容器 图形结合 多图型 图片并列