2019-03-04[D44打卡]
这个优化套路很全面,值得好好收藏.
根据TCP/IP的网络模型 从四层协议中的下面三层:传输、网络、链路层，逐步分析每层的优化方法。
以前知道的只有些浅显的：
一个MTU通常在1500字节
增加最大文件描述符的数量：ulimit -n xxxx
减少TIME_WAIT状态的时间 让系统尽快释放
真大TIME_WAIT状态的连接数
以前的都是遇到一个,谷歌一个. 也没见谁有这么全面的优化思路.
在不知道所以然的情况下,还很可能会出现返优化的情况.哈哈.
虽然目前工作中还暂时用不上那么多高大上的优化方法，但有了个印象，以后遇到了再来复习也是极好的。展开 9
2019-04-02timewait的优化：
timewait是由主动的一方主动关闭的，我认为应用层最好能够池化这些连接，而不是直接关闭这些链接; 另外，比如对于http有些场景的请求，对于需要关闭链接的情况，多个数据请求最好合并发送，也可以减少timewait的情况. 一半来说，我觉得一个服务器上有1W个左右的timewait的链接还是比较正常的.
keepAlive，对于长连接的场景，我觉得tcp层是最好不要开. 因为1.tcp默认是7200秒，需要通过更改内核的方式，不知道在何种情况下是合适的. 2:长连接的情况下，应用层也是需要心跳检查的,这个时候tcp层开keepalive话，反而是中浪费.
tcp层和应用层的网络优化，除了 tcp/ip详解卷一，有一本 effective Tcp/ip programming 也是不错的展开作者回复: 嗯嗯，总结的不错👍
5
2019-03-11老师，nr_open应该是单个进程可分配的最大文件数，file_max才是系统级别的？作者回复: 嗯嗯，是的，谢谢指出
2
2019-06-28老师，有个疑问，从“王亮”的留言中看到，`net.ipv4.tcp_fin_timeout`这个参数决定了它保持在`FIN-WAIT-2`状态的时间，那它怎么又可以“缩短处于TIME_WAIT状态的超时时间”（老师总结的图中）呢？作者回复: 谢谢指出，文中不太准确，net.ipv4.tcp_fin_timeout实际上是从TIME_WAIT_2到TIME_WAIT的超时时间，而 TIME_WAIT状态的超时时间是固定的 2MSL（也就是60s）。
1
2019-03-28关于tcp这块有个关于开启时间戳的验证 参数为tcp_timestamps，有nat环境千万不要打开，可以通过cat /proc/sys/net/ipv4/tcp_timestamps 是否开启作者回复: 嗯 是的
1 1
2019-03-05越来越期待后面的课了 1
2019-03-05打卡，学习本章，知道了使用调节内核网络参数，使用网卡特性，来调节个层性能，受益，感谢老师 1- 2019-03-04打卡day46
基础不牢，地动山摇，一些网络的概念没理解，消化起来比较费力～ 1 
2019-10-26在网卡支持RSS时，还需要用RPS或者RFS吗？请老师指教
2019-10-16对于nginx，我看网上大量的文章都说应该设置 tcp_max_tw_buckets=5000，但您推荐的是一个很大的值，能解释一下吗？谢谢！
2019-07-29老师，linux里面的这个变量net.ipv4.tcp_fin_timeout 到底指代的是什么意义呢。
tcp详解第一卷里面，
说time_wait的等待时间由这个变量记录
然后说 FIN_WAIT_2状态的等待时间也由这个变量记录
然后有些博客说，其实time_wait状态的超时时间，并没有读取这个变量，而是由代码中宏定义的。
有点懵逼展开 1
2019-06-18老师，您好，系统中发现大量closed连接，应该优化哪些参数。
2019-05-08net.ipv4.tcp_fin_timeout 应该是表示如果套接字由本端要求关闭，这个参数决定了它保持在FIN-WAIT-2状态的时间吧？作者回复: 是的
2019-05-03好的
2019-04-28打卡
2019-04-28ulimit -n : open files (-n) 1024 这个跟 fs.nr_open = 1048576 是一个意思吗？作者回复: 一个意思但作用范围不一样，fs.nr_open对应单个进程，ulimit设置用户当前会话
2019-03-27优化思路总结是挺好的，但是毕竟缺少实践，如果不实践，很快就会忘记!作者回复: 嗯嗯，多实践几次就记住了
- 2019-03-27TCP优化，内核选项参数怎么修改呢？在哪修改呢？
作者回复: 临时修改使用sysctl，持久化写入文件/etc/sysctl.conf
2019-03-20"增大本地端口的范围 net.ipv4.ip_local_port_range 。"这个优化手段不是很理解，服务器端通常不都是监听某个端口嘛，为什么说增大本地端口范围会优化呢？作者回复: 监听的端口通常是一个，但服务器程序还可能会通过网络去连接其他服务，这时候它又是一个客户端了
2019-03-18老师，您好，我在今天生产环境发现一个问题想请教下，同事反馈es的集群的索引速度过慢，我去集群上看了下，从表面看来，内存、cpu、网络、磁盘各方面指标都还可以，都不高。
操作系统为Centos，版本信息：Linux lc-gwrz-es25 3.10.0-693.el7.x86_64 #1 SMP Thu Jul 6 19:56:57 EDT 2017 x86_64 x86_64 x86_64 GNU/Linux
在dmesg去查看系统日志的时候，发现几乎每隔1-2s就有网卡重启的日志：
[12528931.704091] ixgbe 0000:01:00.0 em1: NIC Link is Up 10 Gbps, Flow Control: RX/TX
[12528933.478267] ixgbe 0000:01:00.0 em1: NIC Link is Down
[12528933.908089] ixgbe 0000:01:00.0 em1: NIC Link is Up 10 Gbps, Flow Control: RX/TX
[12528936.420314] ixgbe 0000:01:00.0 em1: NIC Link is Down
[12528938.116022] ixgbe 0000:01:00.0 em1: NIC Link is Up 10 Gbps, Flow Control: RX/TX
[12528948.595812] ixgbe 0000:01:00.0 em1: NIC Link is Down
[12528950.439906] ixgbe 0000:01:00.0 em1: NIC Link is Up 10 Gbps, Flow Control: RX/TX
[12528951.949896] ixgbe 0000:01:00.0 em1: NIC Link is Down
[12528952.643856] ixgbe 0000:01:00.0 em1: NIC Link is Up 10 Gbps, Flow Control: RX/TX
[12528953.305133] ixgbe 0000:01:00.0 em1: NIC Link is Down
[12528954.847848] ixgbe 0000:01:00.0 em1: NIC Link is Up 10 Gbps, Flow Control: RX/TX
[12528980.928031] ixgbe 0000:01:00.0 em1: NIC Link is Down
[12528981.199552] ixgbe 0000:01:00.0 em1: NIC Link is Up 10 Gbps, Flow Control: RX/TX
另外查看了下这个网卡的信息：
em1: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
ether 22:14:5b:e1:3e:2a txqueuelen 1000 (Ethernet)
RX packets 29473048069 bytes 29538551685381 (26.8 TiB)
RX errors 755381927 dropped 0 overruns 0 frame 755381927
TX packets 16901640311 bytes 17050517754286 (15.5 TiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
RX errors的数量有点多，通过es的日志来看，这台机器确实和其他主机的连接时常会超时，奇怪的是，对es的其他节点执行ping命令又能够在0.1ms内返回。我看了下网卡，网卡采用team绑定的方式，
TEAM_CONFIG="{\"runner\": {\"name\": \"lacp\"}}"。
请教下：1）为什么网络有问题，我ping显示正常；；2）这种可能是什么原因引起的。展开作者回复: 以前碰到过类似的问题，是网卡驱动到导致的，可以到驱动网站看看有没有类似的错误修复