44 | 套路篇：网络性能优化的几个思路（下）

timewait的优化： timewait是由主动的一方主动关闭的，我认为应用层最好能够池化这些连接，而不是直接关闭这些链接; 另外，比如对于http有些场景的请求，对于需要关闭链接的情况，多个数据请求最好合并发送，也可以减少timewait的情况. 一半来说，我觉得一个服务器上有1W个左右的timewait的链接还是比较正常的. keepAlive，对于长连接的场景，我觉得tcp层是最好不要开. 因为1.tcp默认是7200秒，需要通过更改内核的方式，不知道在何种情况下是合适的. 2:长连接的情况下，应用层也是需要心跳检查的,这个时候tcp层开keepalive话，反而是中浪费. tcp层和应用层的网络优化，除了 tcp/ip详解卷一，有一本 effective Tcp/ip programming 也是不错的

关于tcp这块有个关于开启时间戳的验证 参数为tcp_timestamps，有nat环境千万不要打开，可以通过cat /proc/sys/net/ipv4/tcp_timestamps 是否开启

老师，nr_open应该是单个进程可分配的最大文件数，file_max才是系统级别的？

老师，有个疑问，从“王亮”的留言中看到，`net.ipv4.tcp_fin_timeout`这个参数决定了它保持在`FIN-WAIT-2`状态的时间，那它怎么又可以“缩短处于TIME_WAIT状态的超时时间”（老师总结的图中）呢？

TCP优化，内核选项参数怎么修改呢？在哪修改呢？

"增大本地端口的范围 net.ipv4.ip_local_port_range 。"这个优化手段不是很理解，服务器端通常不都是监听某个端口嘛，为什么说增大本地端口范围会优化呢？

ulimit -n : open files (-n) 1024 这个跟 fs.nr_open = 1048576 是一个意思吗？

老师，您好，我在今天生产环境发现一个问题想请教下，同事反馈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）这种可能是什么原因引起的。

我来请教了，今天服务器发现这个，软中断NET_RX为什么这么不均衡，是否意味着什么问题？ [root]# watch -d cat /proc/softirqs Every 2.0s: cat /proc/softirqs Fri Mar 8 22:34:25 2019 CPU0 CPU1 CPU2 CPU3 HI: 4 1 0 1 TIMER: 713624971 755107323 712371160 933839267 NET_TX: 2 1 3 81 NET_RX: 16219 17426 17488 1270269922 BLOCK: 0 0 0 0 BLOCK_IOPOLL: 0 0 0 0 TASKLET: 5647 9600 8682 14476 SCHED: 535200439 484313787 449453690 603342848 HRTIMER: 0 0 0 0 RCU: 206853385 237158342 227458167 255373399

老师，您好！提一个与本篇无关的系统故障，最近几天经常出现tomcat进程自动消失，之前碰到的一种是因为ssh连接上去，然后执行bin/startup.sh | tail logs/catalina.out这样的命令启动并查看启动日志，这种启动方式在ssh连接断开的瞬间，会因为父子进程的关系，父进程（sshd）退出，所以tomcat进程也跟着自动退出了。这种异常退出有两个特点：1、会在/var/log/secure日志中看到Mar 5 16:40:36 host-10-234-8-172 su: pam_unix(su:session): session closed for user test这样的日志，这个session closed时间点跟tomcat进程退出的时间点是一样的。2、tomcat的catalina.out日志中会有平滑关闭退出的日志。 但是最近的故障没有上面两个特点，dmesg日志或/var/log/messages日志中也没有oom killer之类的错误信息。目前分析没什么头绪了，老师看看是否遇到过类似问题，或者有什么分析思路，谢谢！