ss -m 显示 TCP 内存爆炸但进程 RSS 正常的 orphaned socket 清理方法

这是典型的 orphaned socket（孤儿套接字）堆积现象：连接已断开、应用层释放 socket 后内核未及时回收，sk_buff 内存仍计入 tcp_memory_allocated 但无对应进程 rss。

ss -m 显示 TCP 内存暴涨但 ps/htop 看不到对应进程 RSS 占用

这是典型的 orphaned socket（孤儿套接字）堆积现象：连接已断开、应用层早已释放 socket，但内核尚未彻底回收，sk_buff 和相关内存仍挂在 tcp_memory_allocated 计数器里。它不归属任何用户进程，所以 ps、top、pmap 都看不到 RSS 上升。

常见诱因包括：短连接洪峰后服务端未及时调用 close()（尤其 fork 子进程后父进程忘了关 fd）、应用崩溃但 socket 未被 kernel 彻底清理、或设置了 SO_LINGER 且 linger 时间过长。

• 用 ss -m -i state established 或 ss -m -i state time-wait 观察单个连接的 rmem_alloc/wmem_alloc，若大量连接显示非零但无对应 PID，基本可确认是 orphaned
• /proc/net/sockstat 中的 orphan 行会直接暴露数量：TCP: inuse 1234 orphan 890 tw 567 —— 这里的 orphan 890 就是关键指标
• 不要依赖 netstat，它无法显示 ss -m 的内存字段，且在高连接数下性能差、易丢数据

Linux 内核如何判定并回收 orphaned socket

内核不会无限保留 orphaned socket。是否回收、何时回收，取决于三个硬性阈值和一个软性策略：

• /proc/sys/net/ipv4/tcp_max_orphans：全局上限。一旦 orphan 数量超此值，内核会强制重置（RST）新建立的连接，** 不等超时 **
• /proc/sys/net/ipv4/tcp_fin_timeout：仅影响 FIN_WAIT_2 状态的孤儿连接，对已完全关闭（即进入 TIME_WAIT 或已从连接哈希表移除）的 orphan 无效
• 真正决定“存活时间”的是 tcp_retries2（默认 15），它控制 FIN 重传次数；但 orphaned socket 已无重传行为，所以这个参数实际不生效
• 关键机制是内存压力驱动回收：当 tcp_memory_allocated 接近 tcp_mem[2]（即 /proc/sys/net/ipv4/tcp_mem 的第三个值），内核会主动扫描并销毁 orphaned socket，哪怕它们还没到“理论超时”

快速验证是否是内存压力触发的延迟回收

如果 ss -m 显示大量 orphaned socket 却迟迟不释放，先看内核是否卡在“等内存压力”这一步：

• 运行 cat /proc/sys/net/ipv4/tcp_mem，得到三个数字，例如 123456 234567 345678；第三个值 345678 是 high watermark（单位为页）
• 查当前分配量：cat /proc/net/sockstat | grep -i memory → 找 allocated 后面的数字（单位也是页）
• 若 allocated 接近甚至超过 tcp_mem[2]，说明内核正在节流，orphaned socket 会被优先干掉；反之若远低于，那它们就真可能卡在链表里不动了
• 临时加压测试：用 echo 1 > /proc/sys/net/ipv4/tcp_low_latency（不推荐生产）或人为制造 socket 分配（如快速建连断连脚本），观察 orphan 数是否下降

线上应急清理与长期规避建议

没有一键清 orphaned socket 的命令 —— 它们本就不属于任何进程，kill 或 lsof 都无效。唯一可靠路径是让内核自己回收，或重启网络子系统（风险高，不推荐）。

• 紧急时可小幅调低 tcp_max_orphans（如从 32768 改为 8192）：echo 8192 > /proc/sys/net/ipv4/tcp_max_orphans，内核会立即扫描并踢掉超额部分
• 长期方案必须从应用侧入手：检查所有 fork() 后的 socket fd 是否被显式 close()；禁用 SO_LINGER 或设 linger.l_linger = 0；使用 epoll 时确保 EPOLLIN|EPOLLRDHUP 被监听，及时捕获对端关闭
• 注意：调大 tcp_mem 只是延缓问题，不能解决根源；而盲目调小 tcp_fin_timeout 对 orphaned socket 几乎没用

最常被忽略的一点：Go 的 http.Server 默认启用 KeepAlive，但若客户端异常断连（比如移动网络切换），连接可能滞留在 ESTABLISHED 状态却不发数据，最终变成 orphaned。这时得靠 ReadTimeout + WriteTimeout 主动断连，而不是等内核收。