套接字缓冲区溢出不会直接生成日志，而是通过内核丢包计数（如netstat -s中的packet receive errors）、socket队列水位（ss命令显示recv-q/send-q持续非零）及应用层errno（enobufs/eagain）三类信号间接暴露，需交叉验证sysctl参数与实际生效值。
套接字缓存溢出（如接收/发送缓冲区满）在高并发场景下不会直接生成“溢出日志”，而是通过内核统计、队列水位和错误码间接暴露。排查重点不是找某条日志，而是抓取三类信号：内核丢包计数、socket 队列堆积、应用层 errno。
查内核级丢包与缓冲区拒绝记录
这些是真正反映缓存溢出的底层证据：
-
接收缓冲区满丢包：执行
netstat -s | grep -A 5 "packet receive errors"，关注recvbuf errors或tcp recv queue full类似字段（部分内核版本显示为RTCP: packet receive errors或UDP: packet receive errors中的rcvbuferror） -
发送缓冲区满失败：检查
netstat -s | grep -i "send buffer"，若出现send buffer errors或tcp send queue full，说明应用 write() 调用因 sndbuf 满而阻塞或返回 ENOBUFS -
控制消息空间不足：运行
dmesg | grep -i "optmem_max\|no space for control"，若提示sk_alloc: no space for control messages，说明net.core.optmem_max过小，影响 SCM_RIGHTS 等操作
看实时 socket 队列水位是否持续积压
Recv-Q / Send-Q 是最直观的缓存压力指标：
PyCharm 2026.2.0.1 Linux版
下载
PyCharm 2026.2.0.1 Linux版提供 JetBrains 官方 2026.2.0.1 版本安装包，适合需要指定 PyCharm 版本进行 Python 项目开发、运行和调试的用户。
- 用
ss -tunp | awk '$2 > 0 || $3 > 0 {print $1,$4,$2,$3}'筛出 Recv-Q 或 Send-Q 非零的连接 - Recv-Q 长期 > 64KB（尤其 > 256KB）：大概率是应用读取慢，数据卡在
sk_receive_queue，内核已开始丢新包（见/proc/net/snmp中TcpExt的DelayedACKLost或ListenOverflows） - Send-Q 长期 > 0 且对端窗口为 0：说明对方接收能力不足，本端 sndbuf 持续填满；若 Send-Q 突增 + 重传上升（
netstat -s | grep "retransmitted"），可能是网络拥塞或对方丢 ACK
确认应用是否收到 ENOBUFS 或 EAGAIN 错误
这是用户态感知缓冲区满的关键信号：
- 若应用使用
send()/write()返回 -1 且errno == ENOBUFS：明确表示发送缓冲区无空间，内核拒绝入队 - 若使用非阻塞 socket 的
send()返回 -1 且errno == EAGAIN或EWOULDBLOCK：说明 sndbuf 暂时满，但未丢包，属正常流控 - 检查应用日志或用
strace -p PID -e trace=send,write,sendto 2>&1 | grep -i "eno"实时捕获错误调用
交叉验证缓冲区配置是否生效
避免参数设了却没起作用：
- 查全局值：
sysctl net.core.rmem_max net.core.wmem_max net.ipv4.tcp_rmem net.ipv4.tcp_wmem - 查某连接实际值：
ss -ti 'sport = :8080' | grep -E "(rcv_space|snd_space)"（需 root） - 确认应用是否显式调用
setsockopt(SO_RCVBUF/SO_SNDBUF)：若在listen()或connect()后设置，部分内核会忽略，必须前置
