孤独酒馆|6000+字,30+张图。JAVA线上故障排查全套路总结( 七 )
接下来我们通过wireshark打开抓到的包 , 可能就能看到如下图所示 , 红色的就表示RST包了 。
TIME_WAIT和CLOSE_WAITTIME_WAIT和CLOSE_WAIT是啥意思相信大家都知道 。 在线上时 , 我们可以直接用命令netstat -n | awk '/^tcp/ {++S[$NF]} END {for(a in S) print a, S[a]}'来查看time-wait和close_wait的数量
用ss命令会更快ss -ant | awk '{++S[$1]} END {for(a in S) print a, S[a]}'
img
TIME_WAITtime_wait的存在一是为了丢失的数据包被后面连接复用 , 二是为了在2MSL的时间范围内正常关闭连接 。 它的存在其实会大大减少RST包的出现 。
过多的time_wait在短连接频繁的场景比较容易出现 。 这种情况可以在服务端做一些内核参数调优:
#表示开启重用 。 允许将TIME-WAIT sockets重新用于新的TCP连接 , 默认为0 , 表示关闭net.ipv4.tcp_tw_reuse = 1#表示开启TCP连接中TIME-WAIT sockets的快速回收 , 默认为0 , 表示关闭net.ipv4.tcp_tw_recycle = 1当然我们不要忘记在NAT环境下因为时间戳错乱导致数据包被拒绝的坑了 , 另外的办法就是改小tcp_max_tw_buckets , 超过这个数的time_wait都会被干掉 , 不过这也会导致报time wait bucket table overflow的错 。
CLOSE_WAITclose_wait往往都是因为应用程序写的有问题 , 没有在ACK后再次发起FIN报文 。 close_wait出现的概率甚至比time_wait要更高 , 后果也更严重 。 往往是由于某个地方阻塞住了 , 没有正常关闭连接 , 从而渐渐地消耗完所有的线程 。
想要定位这类问题 , 最好是通过jstack来分析线程堆栈来排查问题 , 具体可参考上述章节 。 这里仅举一个例子 。
开发同学说应用上线后CLOSE_WAIT就一直增多 , 直到挂掉为止 , jstack后找到比较可疑的堆栈是大部分线程都卡在了countdownlatch.await方法 , 找开发同学了解后得知使用了多线程但是确没有catch异常 , 修改后发现异常仅仅是最简单的升级sdk后常出现的class not found 。
推荐阅读
- 孤独酒馆|NVIDIA 助力文远知行在自动驾驶的路上“乘风破浪”
- 孤独酒馆|日本研究机构拆解华为P30 Pro:美企零部件比例不到1%
- 泽宇讲历史|女儿做了外国皇后,不愿向日本求助,49岁孤独去世,父亲是华人
- 环球网|“世界上最孤独的大象”被解救,曾被关了整整35年
- 新鲜事儿|却被渣男抛弃终身不孕,而今孤独一人,她是80年代最火的“琼瑶女郎”
- “世界上最孤独的大象”被解救,曾被关了整整35年
- 世界上最孤独的大象被解救:“世界上最孤独的大象”被解救,曾被关了整整35年
- kaavan|从小被当赚钱工具,35年后,世界上最孤独的大象终于解放了……
- 「孤独」九月,好好生活,好好爱
- 灵魂伴侣|当偶像有多孤独?“韩国最美的男人”38岁改变形象,曾经的灵魂伴侣已转嫁他人
