服务端连接建立慢、偶发超时或 reset,ss -lnt 的 LISTEN Recv-Q 接近 Send-Q。
高并发时新连接偶发超时、被重置或延迟升高,但服务进程仍在运行;ss -lnt 中监听套接字的 Recv-Q 持续大于 0 并接近 Send-Q。netstat -s 或 nstat 的 listen overflow 计数增长。
先看监听队列深度。对 LISTEN 套接字,Recv-Q 是当前等待 accept 的连接数,Send-Q 是 backlog 上限:
ss -lnt
ss -lntp | awk 'NR == 1 || $2 > 0'
watch -n1 "ss -lnt '( sport = :8080 )'"
再看内核溢出计数器,区分 accept 队列和 SYN 队列:
nstat -az TcpExtListenOverflows TcpExtListenDrops TcpExtTCPReqQFullDrop TcpExtSyncookiesSent
netstat -s | grep -iE 'listen|overflow|SYN'
cat /proc/sys/net/core/somaxconn
cat /proc/sys/net/ipv4/tcp_max_syn_backlog
sysctl net.ipv4.tcp_abort_on_overflow net.ipv4.tcp_syncookies
检查应用是否及时 accept:
strace -f -c -e trace=accept4 -p <PID>
ss -s
易误判:ss -lnt 的 Send-Q 是 backlog 上限,不是待发送数据;Recv-Q 短暂大于 0 只说明有连接在等待 accept,持续贴近上限才是溢出。tcp_max_syn_backlog 管 SYN 队列,somaxconn 管 accept 队列,两个计数器不同,只调一个可能无效。netstat -s 里 “SYNs to LISTEN sockets dropped”(ListenDrops)涵盖多种丢弃原因,与 “listen queue overflowed”(ListenOverflows)也不是同一个计数器。
listen() 传入值或 net.core.somaxconn 限制。tcp_abort_on_overflow=1 直接回 RST,放大失败率。listen() backlog 提到 1024 以上,同时确保 net.core.somaxconn 不小于该值。tcp_abort_on_overflow=0,让客户端重传;开启 tcp_syncookies=1 抵御 SYN 洪泛。somaxconn 没有被镜像或运行时重置,必要时通过 sysctls 显式设置。TcpExtListenOverflows/TcpExtListenDrops 速率和队列深度,按秒级告警。Recv-Q 和 Send-Q 分别代表什么?somaxconn 与 tcp_max_syn_backlog 管的是同一个队列吗?tcp_abort_on_overflow 设为 1 会放大故障?Recv-Q 是当前等待 accept 的已完成连接数,Send-Q 是 backlog 上限。somaxconn 限制 accept 队列,tcp_max_syn_backlog 限制 SYN 队列。