非阻塞模式下TCP write操作偶现数毫秒级阻塞问题咨询

非阻塞模式write出现耗时尖刺的核心原因 #

首先需要明确：Linux系统下非阻塞套接字的write调用仅代表不会等待套接字发送缓冲区可用再返回，并不等于调用完全无耗时，更不会跳过内核态的资源竞争、内存分配、协议栈逻辑处理过程。你观测到的耗时尖刺基本都来自内核态处理流程的阻塞，和非阻塞标识是否生效无关，常见触发场景如下：

• 内核网络栈自旋锁竞争：6个客户端同时发送数据且阻塞现象同时出现，高概率是套接字发送队列自旋锁、网络栈全局锁的等待耗时。多个进程/线程同时触发内核网络IO时，write调用陷入内核后需要等待持有对应锁才能继续处理，这段等待时间会计入调用总耗时，且不受非阻塞模式的跳过逻辑覆盖。
• 流量控制队列（Qdisc）瓶颈：Linux默认网卡排队规则（pfifo_fast/fq_codel）队列长度不足，或者网卡发送队列被瞬时流量打满时，内核协议栈会在write处理逻辑中增加重试等待耗时，你观测到的SIOCOUTQ仅300KB左右、远小于默认TCP发送缓冲区大小的特征，完全匹配Qdisc层面阻塞的表现。
• 大块内存分配阻塞：你单次写入的数据量均为1MB以上，内核需要分配连续的skb内存块存储待发送数据，如果此时客户端系统内存碎片化严重，会触发直接内存回收逻辑，这个过程会阻塞当前系统调用直到内存分配完成，和套接字是否为非阻塞模式完全无关。
• 服务器端瞬时接收卡顿：如果服务器端进程出现IO阻塞、调度停顿，无法及时读取套接字接收缓冲区的数据，会向所有客户端发送0窗口通知，客户端TCP协议栈处理逻辑会触发短时等待，完全符合多客户端同时阻塞的特征。

排查思路建议 #

• 确认耗时分布：用strace -T、perf top工具采集阻塞时段的调用耗时，确认write的耗时是否全部产生于内核态，排除用户态代码逻辑的影响。
• 排查锁竞争：用perf lock record采集阻塞时段的内核锁竞争数据，重点排查tcp_sendmsg、sk_alloc相关函数的锁等待时间，如果确认是锁竞争导致，可以将单次写入的大块数据拆分为128KB以内的小块分次写入，减少单次write调用的内核锁持有时间。
• 排查服务器状态：阻塞发生时在服务器端执行ss -ti查看套接字状态，确认是否存在接收队列堆积、接收窗口为0的情况，如果存在，进一步排查服务器进程的CPU、IO负载是否存在瞬时尖刺。
• 排查内存碎片化：阻塞发生时查看客户端的/proc/buddyinfo文件，确认是否存在高阶内存不足的情况，如果是，可以开启内核透明巨页，或者调整/proc/sys/net/core/optmem_max配置减少大块内存分配需求。
• 调整流量控制队列配置：可以尝试将网卡的排队规则调整为无队列模式，测试是否能解决耗时尖刺问题，命令参考：

  tc qdisc add dev 你的网卡名称 root noqueue
  

内容的提问来源于stack exchange，提问作者J.M.