netstat 不提供 socket 资源占用率百分比，但可通过 recv-q/send-q、nstat 丢包计数器、/proc/net/sockstat 等指标判断缓冲区压力；推荐用 ss 替代 netstat 获取更精准 socket 缓冲区用量。
netstat 本身不直接输出“Socket 资源占用率”这个百分比数值，但它能提供关键原始数据——包括各连接的接收/发送队列长度、监听状态、进程绑定关系及协议统计——这些是判断 Socket 资源是否紧张的核心依据。真正需要关注的是缓冲区积压、队列溢出、丢包计数器等可量化的压力信号，而非抽象的“占用率”。
查看 TCP/UDP 连接中 Socket 缓冲区实际使用情况
ss 是更推荐的现代工具（比 netstat 更精准、低开销），但 netstat 仍可用于快速筛查：
-
显示所有 ESTABLISHED 连接及其 Recv-Q/Send-Q（字节数）
netstat -ant | awk '$6 == "ESTABLISHED" && ($2 > 1024 || $3 > 1024) {print}'-
Recv-Q：内核接收队列中尚未被应用读取的数据字节数 -
Send-Q：内核发送队列中等待确认或重传的数据字节数 - 若某连接持续出现
Recv-Q > 0（尤其 > 数 KB），说明应用读取慢或卡住，Socket 接收缓冲区正在堆积。
-
-
配合
-p查看对应进程（需 root）sudo netstat -tunp | grep ':8080'
快速定位端口 8080 被哪个 PID 占用，再结合
/proc/<pid>/stack</pid>分析是否阻塞在 read()/recv() 等系统调用。
检查内核级 Socket 缓冲区告警与丢包
真正的资源瓶颈常体现在内核统计计数器里，而非单个连接：
-
TCP 接收队列溢出丢包（最常见问题）
nstat -az | grep TcpExtTCPRcvQDrop # 输出如：TcpExtTCPRcvQDrop 12745 0.0 → 表示已丢弃 12745 个因接收缓冲满而无法入队的包
-
UDP 缓冲区错误（接收/发送满）
nstat -az | grep -E 'UdpRcvbufErrors|UdpSndbufErrors' # UdpRcvbufErrors 高 → 应用没及时 recvfrom()，内核丢 UDP 包 # UdpSndbufErrors 高 → 应用发包太快，send() 阻塞或返回 ENOBUFS
-
全局 socket 内存使用（间接反映压力）
cat /proc/net/sockstat # 示例输出： # sockets: used 1245 # TCP: inuse 321 orphan 12 tw 45 alloc 389 mem 678 # UDP: inuse 42 mem 12 # 此处 mem 单位是页（通常 4KB），TCP mem 678 ≈ 2.6MB；若持续增长且接近系统限制（/proc/sys/net/core/wmem_max 等），说明缓冲区分配趋紧
关键阈值与响应建议
-
Recv-Q持续 > 64KB 或占rb（接收缓冲区上限）的 70%以上 → 检查应用读逻辑、是否存在反压或死锁 -
TcpExtTCPRcvQDrop或UdpRcvbufErrors计数非零且随时间上升 → 立即排查对应服务吞吐与消费能力 -
/proc/net/sockstat中TCP mem接近net.core.wmem_max + net.core.rmem_max总和 → 调整net.ipv4.tcp_rmem/net.ipv4.tcp_wmem或优化连接复用 -
netstat -s显示大量connection resets或timeouts→ 可能是远端异常断连，也可能是本端资源不足导致握手失败
替代与补充工具建议
- 优先用
ss -ntmp替代netstat -tulp：输出含skmem:(rX,rbY,tZ,tbW,...)，直接显示每个 socket 的实时缓冲区用量（r=当前接收队列字节数，rb=最大接收缓冲区字节） - 结合
sar -n sock 1（sysstat 包）长期监控 socket 创建/释放速率、inuse 数量趋势 - 对高并发服务，启用
net.core.somaxconn和net.core.netdev_max_backlog避免监听队列溢出
不复杂但容易忽略
