项目标题是防止linux出现大量 FIN_WAIT1这是个很典型的运维场景问题。我按从业者分享实操经验的思路来写先讲清 FIN_WAIT1 是什么、为什么会堆再讲内核怎么回收、应用层哪些写法会造出它最后给排查链路和参数计算。全程围绕预防和根因展开不写成参数手册。早上九点半监控群里弹出一条告警某台业务机的 FIN-WAIT-1 连接数突破两万。值班的同事第一反应是去拉 sysctl把 net.ipv4.tcp_fin_timeout 从 60 改成 15重启了一下应用告警消失了半天第二天同一时间又来了。这个场景我见过太多次问题从来不在那个参数上。**FIN_WAIT1** 是 TCP 状态机里最容易被误读的一个状态它既不像 TIME_WAIT 那样有明确的内核回收窗口也不像 CLOSE_WAIT 那样一眼就能定位到应用没关连接它更像是本机已经把话说完、对方迟迟不点头——半句话卡在那里谁也不知道对方是真没收到还是收到了懒得回。这篇内容我想把这件事从头捋一遍FIN_WAIT1 产生的内核路径是什么孤儿 socket 是怎么被回收的tcp_orphan_retries 和 tcp_fin_timeout 各自管哪一段应用层有哪些写法会批量制造这个状态以及真到了现场该怎么用 ss 和 tcpdump 三眼看清楚。适合正在被这个问题困扰的后端、运维、SRE 同学也适合写网络客户端库的开发者——很多时候锅不在运维这边。 ## 1. FIN_WAIT1 到底是什么为什么它总在告警里出现 ### 1.1 从四次挥手说起那个只发了半句话的状态 TCP 关闭连接要四次挥手主动关闭的一方先发 FIN然后进入 **FIN_WAIT1**等对方回一个 ACK。收到 ACK 之后才进入 FIN_WAIT2再等对方的 FIN最后进 TIME_WAIT。所以 FIN_WAIT1 的准确含义是**我已经把 FIN 发出去了但还没收到对方的确认**。注意这里的关键——它等的不是对方的 FIN只是一个 ACK一个序列号确认而已。 这一点特别重要因为很多文章把 FIN_WAIT1 描述成等待对方关闭那是 FIN_WAIT2 的事。FIN_WAIT1 等的东西轻得多理论上对方内核收到 FIN 之后立刻就该回 ACK中间不该有任何业务逻辑参与。也就是说一个连接在 FIN_WAIT1 停留的正常时长应该是**一个 RTT 量级**同机房几百微秒跨地域也就几十毫秒。如果你看到某个连接在 FIN_WAIT1 停留了几十秒甚至几分钟那一定是链路上出了问题或者对端压根没打算回。 我习惯用一个不太严谨但很好用的类比FIN_WAIT1 就像你给对方发了条我说完了挂了啊的消息然后盯着屏幕等一个收到。正常情况一秒内就有回应如果对面十分钟没吭声你要么怀疑网络断了要么怀疑对方故意不理你。而 TCP 的做法是——不停地重发这条消息重发到一定次数就放弃。 ### 1.2 堆积的本质本该几毫秒的事被拉长到了几分钟 既然正常停留时间只有一个 RTT那大量堆积这件事本身就是异常的。堆积只有两种可能一是**并发关闭的速率太高**即便每个连接只停留几十毫秒乘上每秒几千次的关闭也能堆出几千个二是**单个连接的停留时间被拉长**本该 1 毫秒的变成 200 秒那即便关闭速率不高也会慢慢累积成一堵墙。 第一种情况其实是健康的——高频短连接业务本来就该有大量瞬时 FIN_WAIT1只要数值在一个稳定区间内波动不用管。真正麻烦的是第二种连接进来出不去越积越多最后撞上 net.ipv4.tcp_max_orphans 的上限内核开始直接给新连接回 RST业务侧表现为偶发连接被重置而且这种报错非常随机抓不到规律。 我在一个网关项目里遇到过一次典型的第二种。现象是每台机器上稳定挂着三千到五千个 FIN_WAIT1不涨也不跌看起来很稳定。用 ss -tanpo state fin-wait-1 一看定时器剩余时间从 100 多秒到 200 多秒都有说明这些连接都在反复重传 FIN。抓包发现 FIN 发出去了对端一个 ACK 都没有但 TCP 握手和数据传输都正常。最后定位到中间一层负载均衡设备的会话老化策略它把长时间无数据的连接从会话表里提前踢掉了之后到达的 FIN 因为找不到会话直接被丢弃而且丢弃是静默的不回 RST。本机就一直重传、一直等直到重传次数耗尽。 ### 1.3 先分清谁是主动关闭方这决定了排查方向 FIN_WAIT1 只可能出现在**主动关闭方**。所以看到这个指标第一件事是搞清楚本机在这条连接里是客户端还是服务端。这个判断直接决定后面的排查路径完全不同。 如果是服务端主动关比如 Nginx 的 keepalive_timeout 到期、后端连接池主动踢空闲连接那问题多半出在服务端的关闭策略上——是不是关得太急、是不是把还在传数据的连接硬关了。如果是客户端主动关比如调用第三方接口后立即断开、爬虫类业务的短连接那要查的是客户端的连接复用做得怎么样、有没有连接泄漏。 还有一种容易忽略的情况**两端几乎同时关闭**。这时本机发 FIN 进 FIN_WAIT1同时也收到了对方的 FIN状态会切到 CLOSING 而不是 FIN_WAIT2。CLOSING 也是要等 ACK 的如果 ACK 丢了同样会卡住。所以排查时不能只看 FIN_WAIT1ss -s 里 CLOSING 的数量也要一起看。 ## 2. 内核是怎么兜住这些孤儿连接的 ### 2.1 close() 之后 socket 并没有立刻消失 很多人以为应用调用 close() 之后连接就交给内核了内核发完 FIN 收到 ACK 就完事。实际情况要复杂一些close() 的时候如果发送缓冲区里还有没发完的数据、或者有已发送但未确认的数据内核不能立刻释放这个 socket因为它还得负责重传。这时候 socket 会进入**孤儿orphan状态**从原来的 socket 哈希表里摘出来挂到一张专门的孤儿链表上由内核的定时器接管。 这个设计是必要的——应用已经撒手不管了但数据可能还没送到内核得替它把尾巴收干净。代价就是如果对端一直不确认这个孤儿 socket 会一直挂在链表上占着内存。所以内核给孤儿 socket 设了两道闸一道是**数量上限** net.ipv4.tcp_max_orphans超过就直接 RST 掉另一道是**重传次数上限** net.ipv4.tcp_orphan_retries重传到次数就放弃释放。 /proc/net/sockstat 里能看到当前孤儿数这个数字比 FIN_WAIT1 计数更能反映问题的严重程度 bash cat /proc/net/sockstat # sockets: used 1024 # TCP: inuse 800 orphan 3500 tw 2000 alloc 4500 mem 120orphan 3500意味着有三千多个 socket 已经脱离应用、正在由内核代管。如果这个数字持续上涨并逼近tcp_max_orphans那就是真出事了。2.2 FIN 重传的定时器和 tcp_orphan_retries 的真实作用FIN 的重传走的是 TCP 的重传定时器和普通数据重传共用一套退避逻辑第一次重传等 1 秒TCP_TIMEOUT_INIT之后每次翻倍到 120 秒TCP_RTO_MAX封顶。重传几次放弃由tcp_orphan_retries决定默认 8。把这两个数代进去算一下就很清楚了重传序号等待时长累计耗时第 1 次1s1s第 2 次2s3s第 3 次4s7s第 4 次8s15s第 5 次16s31s第 6 次32s63s第 7 次64s127s第 8 次120s247s也就是说默认配置下一个 FIN 发出去没人理内核会陪它耗大约 4 分钟才放弃。四分钟不算长但如果每秒有一百个这样的连接进来稳态下就会挂着两万多个 FIN_WAIT1。这个数字和前面那个两万告警完全对得上。所以tcp_orphan_retries才是真正控制 FIN_WAIT1 生命周期长度的参数。把它从 8 调到 5生命周期就从 247 秒压到 31 秒同样的关闭速率下堆积量直接降一个数量级。这个调整的代价后面再说先把账算清楚——任何关于 FIN_WAIT1 的调参如果不落到这个参数上基本都是隔靴搔痒。还有一点需要提醒较新的内核版本里这个参数的语义还受一个对端是否还活着的标志影响。如果内核观察到对端在重传期间还在回数据或 ACK会倾向于更早放弃重传。所以不同内核版本上同样的配置值实际表现可能有差异改完一定要用ss -tanpo观察实际停留时长来验证别只看配置文件。2.3 tcp_fin_timeout 被误读的这十年net.ipv4.tcp_fin_timeout这个参数大概是网络调优领域被误传最广的一个。无数篇Linux 性能优化文章把它描述成FIN_WAIT1 的超时时间实际上它管的是FIN_WAIT2。FIN_WAIT2 是收到对方 ACK 之后的状态这时候本机该做的都做完了就等对方的 FIN。对方如果一直不发典型情况是对方应用崩了但机器还活着本机不能无限等于是有个超时默认 60 秒超时后直接关闭连接。这就是tcp_fin_timeout的作用范围。所以把它从 60 改成 15对 FIN_WAIT1 的堆积一点用都没有。而且调小它还有副作用FIN_WAIT2 缩短意味着更早释放连接但如果对方只是慢了一点比如它的应用在排队处理还没轮到发 FIN本机提前关闭会导致对端后续发来的数据被回 RST对端业务侧会看到莫名其妙的连接重置。这个副作用在长连接场景下特别隐蔽往往要过几天才暴露成偶发报错。我把这两个参数的职责列一下贴墙上的那种参数作用状态默认值调小的影响tcp_orphan_retriesFIN_WAIT1 / CLOSING / LAST_ACK8缩短 FIN 重传窗口回收快但对端短暂卡顿时容易被 RSTtcp_fin_timeoutFIN_WAIT260缩短等对端 FIN 的时间对端处理慢时易触发 RSTtcp_max_orphans孤儿 socket 总量随内存调大的影响是内存占用调小会提前 RST3. 把 FIN_WAIT1 造出来的六种应用层写法3.1 半关闭与只发不读的经典误用有一种写法非常常见客户端把请求发完调用shutdown(fd, SHUT_WR)表示我不再发送数据了然后等着读响应。这时候内核会立刻发 FIN连接进入 FIN_WAIT1。如果对端的协议实现是读到 EOF 才认为请求结束、然后再处理、再回响应那这个处理过程可能几秒甚至几十秒中间 FIN 的 ACK 是内核回的理论上不影响状态推进——但前提是对端内核能正常回 ACK。问题出在另一种情况对端的接收窗口满了。比如对端在做批量处理没及时读 socket接收缓冲区满了之后它连 FIN 都塞不进接收队列自然也就不会回 ACK。本机就一直卡在 FIN_WAIT1 重传。这种卡顿在压测时特别明显QPS 一上去FIN_WAIT1 跟着飙升QPS 降下来就自动恢复。还有一种更隐蔽的应用只shutdown写端但从来没调用closefd 泄漏。这种情况下 socket 不会进孤儿状态因为应用还持有引用会长期挂在 FIN_WAIT1 上ss里能看到它但/proc/net/sockstat的 orphan 计数不涨。这种不占孤儿名额的 FIN_WAIT1最难查因为所有基于孤儿数的监控指标都是瞎的。我的经验是孤儿数正常但 FIN_WAIT1 很多优先怀疑 fd 泄漏或半关闭误用。3.2 连接池、keepalive 和超时三者的错位长连接池是 FIN_WAIT1 的另一个高产地带核心矛盾在于三个时间参数各自为政连接池的空闲回收时间比如 30 秒没用就关TCP 层的 keepalive 探测时间默认tcp_keepalive_time7200 秒中间设备负载均衡、NAT、防火墙的会话老化时间只要中间设备的会话老化时间短于连接池的空闲时间就会出现这种情况连接池认为这条连接还活着实际中间设备早就把会话表项删了。等连接池真的拿这条连接去发请求或者到了空闲时间主动关闭发 FIN包到了中间设备直接被丢掉——因为找不到会话了。本机就卡在 FIN_WAIT1 重传直到 247 秒后放弃。我在一个内部服务里调过这类问题当时的配置是连接池空闲 60 秒回收中间负载均衡的 TCP 空闲会话是 300 秒理论上没问题。但负载均衡上还有一条单连接最大存活时间 30 分钟的硬限制到点强制剔除会话。结果就是每 30 分钟有一批连接同时失效FIN_WAIT1 出现规律的周期性尖峰。这种周期性尖峰是判断中间设备问题的强信号——如果 FIN_WAIT1 曲线是规律的锯齿状别再翻内核参数了去问网络那边要会话老化配置。3.3 中间设备静默丢包与协议层不匹配比会话老化更麻烦的是静默丢弃。安全组、防火墙如果是 DROP 策略而不是 REJECT包进去就没了本机收不到任何反馈只能靠重传超时。RST 至少还能让连接快速失败DROP 会让它慢慢耗死。这也是为什么我一直建议内部服务之间的访问控制能用 REJECT 就别用 DROP快速失败比慢速超时对系统更友好。另一类是协议层的不匹配。比如某些老旧设备会改写序列号、或者对 TCP 选项处理有问题导致 FIN 包被判定为非法而丢弃。这类问题用tcpdump看特别明显——FIN 发出去了对方回来的包里序列号对不上或者干脆没有任何回包。还有一种情况是 MTU 不匹配带选项的 FIN 包被分片后丢了一片表现也是没有回音。我把这几种成因的判断特征整理成表现场排查时对着看能省不少时间现象特征大概率原因验证方式FIN_WAIT1 平稳高位不涨不跌中间设备会话老化抓包看 FIN 有无回包规律锯齿状尖峰中间设备定时剔除会话对比中间设备配置孤儿数高但 FIN_WAIT1 不高重传中数据没发完/proc/net/sockstat孤儿数正常但 FIN_WAIT1 高fd 泄漏或半关闭未 closess -tamp看 inode 归属压测时飙升、降载即恢复对端接收窗口满看对端Recv-Q3.4 应用层超时缺位带来的连锁反应还有一类根因不在网络纯粹是应用代码里没设超时。HTTP 客户端、数据库驱动、RPC 框架很多默认是不设超时的或者设了个特别大的值。业务线程卡在一个永远不返回的读操作上连接就一直占着。等到某个环节终于超时、代码开始清理连接会突然迸发出一批关闭请求——这时候 FIN_WAIT1 就集中出现了。这个模式的典型特征是FIN_WAIT1 和响应时间告警同时出现。因为超时集中触发的那一刻正是大量连接同时被关闭的时刻。如果你看到 FIN_WAIT1 飙升的同时接口 P99 也在飙升那基本可以确定是超时配置的问题而不是网络的问题。这种情况调内核参数完全治标不治本该做的是给每一个对外调用加上合理的连接超时和读超时通常读超时设置在 P99 响应时间的 2 到 3 倍比较合适。4. 一次完整的现场排查从 ss 到 tcpdump4.1 第一眼状态、进程、定时器一次看全现场第一步别急着改参数先把现状看清楚。我习惯用一条命令把需要的信息全捞出来# 列出所有 FIN-WAIT-1带上进程信息和定时器 ss -tanpo state fin-wait-1 # 老版本 ss 如果不支持状态名用这个 ss -tanpo | awk $1FIN-WAIT-1 # 按本地端口聚合看是哪个服务 ss -tan state fin-wait-1 | awk {print $4} | awk -F: {print $NF} | sort | uniq -c | sort -rn | head-o这个选项是关键它会把定时器信息打出来格式类似timer:(on,163sec,7)。三个字段分别是定时器状态、剩余时间、已重传次数。看到7这种数字就说明已经重传了七次快耗尽了——这条连接基本没救了后面就是等它自己放弃或者直接 RST。-p显示进程信息但要拿到它通常得用 root或者至少是 socket 的属主。如果ss -p显示不出来归属进程那说明这些 socket 已经是孤儿了应用已经 close 了。这时候可以用 inode 反查# 先拿到 socket inode再从 /proc 里反查 ss -tanpo state fin-wait-1 | grep -oP ino:\K\d | head -5 # 然后遍历 /proc/*/fd 找匹配的 fd不过对于孤儿 socket/proc里是查不到的因为应用已经释放了引用。这也从侧面告诉你这批连接的应用侧已经处理完了问题在链路上。4.2 第二眼确认 FIN 到底有没有被 ACKss只能告诉你卡住了卡在哪一头必须靠抓包。抓包的核心目标是回答三个问题FIN 有没有发出去、对方有没有回、回的是什么。# 抓指定端口的 FIN/RST 包 tcpdump -i any -nn -c 200 \ tcp port 8080 and (tcp[tcpflags] (tcp-fin|tcp-rst) ! 0) \ -w /tmp/fin.pcap # 简单看的话直接打到屏幕 tcpdump -i any -nn -A \ tcp port 8080 and (tcp[tcpflags] tcp-fin ! 0) | head -50看抓包结果时有三种典型形态。第一种FIN 发出去对方回了个纯 ACK那这个连接状态推进应该正常ss里看到的 FIN_WAIT1 应该很快消失如果没消失那是ss采样瞬间的噪音。第二种FIN 发出去对方回 RST那连接立刻关闭不会堆积但业务侧会报连接被重置这是另一种问题。第三种FIN 发出去没有任何回包这就是真问题一定是链路中间把包吃了或者对端应用层/内核层已经彻底不管这条连接了。我一般会同时抓两端的包做对比。如果本机显示发了 FIN对端抓包根本没看到那丢在中间如果对端收到了 FIN 但没回 ACK那是对方内核或应用的问题。这个对比能直接把排查范围砍掉一半。4.3 第三眼内核统计、孤儿数和 conntrack第三眼看的是全局统计用来判断这到底是个别连接的偶发问题还是系统性压力。# 协议栈统计重点看重传和孤儿相关 netstat -s | grep -iE retrans|orphan|prune|drop # 更细的扩展计数器 nstat -az | grep -iE TcpExtTCPAbort|TcpRetransSegs|TcpOutOfOrder # 孤儿数实时观察 watch -n 1 cat /proc/net/sockstat # 如果开了 conntrack看会话表 conntrack -S sysctl net.netfilter.nf_conntrack_count net.netfilter.nf_conntrack_maxnetstat -s里如果出现TCP: too many orphaned sockets这类计数说明孤儿数已经撞到上限了这时候内核会对新连接直接回 RST业务侧表现为随机连接失败。这是最危险的阶段必须立刻处理——最直接的办法是临时把tcp_max_orphans调大争取时间同时查根因。conntrack 这块容易被忽略。如果本机开了防火墙或者做了 NAT每条连接都会占一个会话表项nf_conntrack_tcp_timeout_fin_wait默认 120 秒。在 FIN_WAIT1 堆积的时候这些会话也在占用配额如果nf_conntrack_count逼近nf_conntrack_max新连接会被直接丢弃症状是新连接建不上老连接也断不干净特别容易误判成应用挂了。5. 参数怎么调能调的、不该调的、调了也白调的5.1 重传次数到底该怎么定tcp_orphan_retries该设多少取决于你能容忍多长的半死连接存活时间。这个没有标准答案我一般按下面的思路推先估算一个 RTT 上限。同机房 1ms 以内跨可用区 5ms 左右跨地域 50ms 以上。对端内核回一个 ACK 最多一个 RTT加上调度延迟10 倍 RTT 已经很宽松了。如果一条连接在 FIN 发出后 10 倍 RTT 内都没收到 ACK基本可以断定对端有问题。再看退避序列。设tcp_orphan_retries N累计耗时大约是2^N - 1秒N 小于 7 的时候超过 7 之后受 120 秒封顶影响。N3累计 7 秒太激进对端只要 GC 停顿一下就会被 RSTN5累计 31 秒我常用的折中值能覆盖大部分短暂的网络抖动N6累计 63 秒保守但不至于积太多N8累计 247 秒默认值高频短连接场景下积压明显我一般的做法是高频短连接业务设 5中低频长连接业务保持 6 或 7。设 5 意味着一条连接最多卡 31 秒按每秒 200 次关闭算稳态堆积上限也就 6000 左右这个量级对内存没有压力。如果业务方反馈偶发 RST 变多再往上加一档每次调整后观察至少一个完整的业务高峰周期再定。5.2 一份可以直接抄的 sysctl 配置下面这份是我在网关类服务上用了比较久的配置注释写清了每一项的理由可以直接参考但要结合自己的场景改# FIN 重传 5 次放弃累计约 31 秒 net.ipv4.tcp_orphan_retries 5 # 孤儿 socket 上限按内存给8G 机器给 32768 比较宽松 net.ipv4.tcp_max_orphans 32768 # FIN_WAIT2 保持默认不乱动 net.ipv4.tcp_fin_timeout 60 # 客户端侧复用 TIME_WAIT服务端不要开 net.ipv4.tcp_tw_reuse 1 # TIME_WAIT 桶上限适度提高避免被打日志 net.ipv4.tcp_max_tw_buckets 65536 # keepalive 探测长连接场景建议打开并调短 net.ipv4.tcp_keepalive_time 600 net.ipv4.tcp_keepalive_intvl 15 net.ipv4.tcp_keepalive_probes 3几个说明。tcp_tw_reuse只对主动发起连接的一方有效服务端监听端口开它没有意义而且要求时间戳开启net.ipv4.tcp_timestamps 1现在基本都是开的。tcp_max_orphans的值要给够但也不能无脑加大每个孤儿 socket 至少占几 KB 内存三万多个就是几百 MB 的量级。keepalive那三项的意义是把应用层无感知的死连接探测出来——默认 7200 秒太长了等于没开调到 600 秒加上 3 次探测十分钟内能发现对端没了比等 247 秒的 FIN 重传更主动。改完之后一定要验证别改完就完事sysctl -p ss -tanpo state fin-wait-1 | head -20 # 观察 timer 字段里的秒数确认最长停留时间符合预期5.3 三个流传很广但解决不了问题的偏方第一个偏方是改tcp_fin_timeout。前面说过了它管 FIN_WAIT2对 FIN_WAIT1 无效。这个误区传播太广以至于很多团队的性能优化清单里都挂着它实际上做了什么完全说不清。第二个偏方是tcp_tw_recycle。这个参数在较新的内核里已经被移除了老内核上开着它会导致 NAT 环境下的连接随机失败因为它是靠时间戳判断连接新鲜度的NAT 后面多个客户端的时间戳会互相干扰。凡是在老文章里看到推荐这个参数的那篇文章的其他部分也别信了。第三个偏方是调大文件描述符上限。ulimit -n确实可能成为瓶颈但它影响的是能不能建新连接跟 FIN_WAIT1 堆积没有因果关系。而且如果 fd 真的耗尽了症状是accept返回EMFILE日志里会有明确的报错跟 FIN_WAIT1 的表现完全不同。这三个偏方有个共同点都是某篇文章说这样能优化网络然后被复制粘贴了十几年。我自己的原则是调参数之前必须能说清楚这个参数在协议栈的哪一行代码里起作用说不清就先别动。6. 常见问题速查与踩坑记录6.1 现场速查表问题现象排查动作常见结论FIN_WAIT1 数量持续上涨ss -tanpo state fin-wait-1看定时器对端不回 ACK查链路ss里看不到归属进程说明已进孤儿态应用已 close看链路侧能看到进程但 fd 一直不释放/proc/PID/fd计数持续涨半关闭误用或 fd 泄漏dmesg有 too many orphancat /proc/net/sockstat已触顶先调大上限争取时间周期性锯齿对比中间设备会话老化会话被强制剔除伴随 P99 飙升查应用超时配置超时集中触发批量关闭只有单机出现对比同集群其他机器单机内核参数或网络策略差异6.2 几条不写在文档里的经验第一条监控 FIN_WAIT1 的绝对值意义不大要看变化率和持续时间。一个每秒处理五千次短连接的机器稳态挂着几千个 FIN_WAIT1 完全正常。我在告警规则里用的是五分钟均值超过基线三倍且持续十分钟比设一个固定阈值靠谱得多。第二条先看孤儿数再看状态数。/proc/net/sockstat里那一行 TCP 统计信息orphan字段反映的是内核正在替应用擦屁股的数量这个数字比 FIN_WAIT1 更能说明问题本质。如果 orphan 很高但 FIN_WAIT1 不高说明连接在别的状态堆积比如 LAST_ACK排查方向完全不一样。第三条改tcp_orphan_retries之前先确认业务能不能接受 RST。把这个值调小本质上是更早放弃、更快释放代价是对端如果只是短暂卡顿本来还能救回来的连接会被直接放弃。对于幂等的读请求这没问题对于非幂等的写请求可能意味着数据没送到但连接被重置业务侧要能处理这种不确定性。第四条抓包永远比猜快。我见过太多次靠猜定位问题猜了两天不如抓十分钟包。tcpdump加上正确的过滤表达式五分钟就能看出 FIN 到底有没有被回应这个信息量比翻十个监控面板都大。第五条也是最容易忽视的一条FIN_WAIT1 是一个症状不是病。它告诉你有一批连接本机想关但关不掉真正的原因可能在应用代码、在连接池配置、在中间设备的会话策略、在对方的处理能力。把参数调到让这个指标消失很容易但如果根因还在它只会换个形式冒出来可能是 RST 增多可能是业务侧的超时告警也可能是数据丢失。我自己踩过最深的坑就是为了让告警消失把重传次数调到 2结果业务侧开始间歇性报请求已发送但响应为空查了三天才发现是自己给自己埋的雷。
