tcp内存占用高而rss低是内核socket缓冲区堆积所致，非用户态进程直接占用；需通过/proc/net/sockstat、ss -i、tcp_mem等定位接收队列积压及对应进程。
ss -m 显示 TCP 内存占用高，但对应进程的 RSS（Resident Set Size） 却很低，这是典型的内核协议栈内存未及时释放现象，不是用户态进程直接“吃掉”了内存，而是 TCP socket 缓冲区（尤其是接收队列）堆积导致内核 sk_buff 和相关结构体持续驻留。关键在于：TCP 内存统计在内核层面（/proc/net/sockstat、ss -m），而 RSS 只反映进程地址空间中实际映射的物理页，不包含内核为该进程 socket 分配的缓冲区内存。
确认是否真为 TCP 内存泄漏
先排除误判：
- 执行
cat /proc/net/sockstat，重点关注sockets: used和TCP:行中的inuse、orphan、tw（TIME_WAIT）、alloc、mem字段；若mem持续增长且远高于inuse × 128KB（默认单 socket 内存上限），说明存在异常积压 - 运行
ss -i -n state established | head -20，观察每个 ESTAB 连接的rcv_rtt、rcv_space、rcv_ssthresh，特别留意rcv_q（接收队列长度）是否长期 > 0 且不下降——这表示应用未及时调用recv()，数据卡在内核接收缓冲区 - 检查
/proc/sys/net/ipv4/tcp_mem，确认当前系统 TCP 内存压力等级（第三值为上限），再看/proc/net/snmp中Tcp:行的InSegs与OutSegs是否匹配，若InSegs ≫ OutSegs，说明入包远多于被应用读走的量
定位具体 socket 和所属进程
ss -t -i -n -m 可同时显示连接状态、TCP 信息和内存详情，但需配合 -p（需 root）才能关联 PID：
- 用
sudo ss -t -i -n -m -p | grep -A5 'rcv_q:[[:digit:]]\{4,\}'找出接收队列过大的连接 - 对目标连接提取 inode 号（如
ino:12345678），再查sudo ls -l /proc/*/fd/ | grep 12345678定位进程 PID - 更高效方式：
sudo ss -t -i -n -m -p | awk '$1~/^u/ || $1~/^t/ {if($NF~/pid=/) print $NF,$(NF-1)}' | sort -k2,2nr | head -10，按接收队列大小倒序列出进程名和 PID
检查应用行为与配置
常见根因集中在应用层消费能力不足或配置不合理：
- 服务端未启用
SO_RCVBUF自动调优（/proc/sys/net/ipv4/tcp_window_scaling=1必须开启），或手动设了过小固定值，导致窗口无法扩展，对端持续重传，内核被迫缓存更多数据 - 应用使用阻塞 I/O 且 recv 调用频率低、每次读取字节数少（如只读 1 字节），造成大量小包堆积在
sk_receive_queue - 长连接场景下，客户端发送速率远高于服务端处理速度（如日志推送、IoT 上报），又未实现流控或背压机制
- 存在连接泄漏：socket 未 close，但应用逻辑已丢失引用（如 Java 中未关闭 InputStream），导致连接处于 FIN_WAIT2 或 CLOSE_WAIT 状态，接收缓冲区无法释放
临时缓解与长期修复
应急可降低影响，但治本需修改应用逻辑：
- 临时：调大
/proc/sys/net/ipv4/tcp_rmem第三项（max），避免因缓冲区满触发丢包重传加剧堆积；或用echo 1 > /proc/sys/net/ipv4/tcp_fin_timeout加速 FIN_WAIT2 回收（慎用） - 监控项补充：在 Prometheus + node_exporter 中添加
node_netstat_Tcp_InSegs、node_sockstat_TCP_mem、process_resident_memory_bytes{process=~"your_app"}三者对比告警 - 代码侧：确保所有 socket 调用
setsockopt(..., SO_RCVBUF, ...)合理值（如 1MB）；使用非阻塞 I/O + epoll/kqueue；每轮 recv 至少读取min(64KB, available)；对慢客户端主动断连
