eBPF SK_SKB程序引发Thrift RPC及HTTP服务连接异常问题排查

关于Thrift是否使用TCP套接字 #

Thrift官方CPP Tutorial及绝大多数默认配置下，底层都是基于TCP套接字通信的（通过TSocket实现）。除非你显式指定了UDP、UNIX域套接字或其他传输协议，否则不会偏离TCP。

可以通过两种方式快速确认：

• 查看Thrift服务端/客户端代码，确认使用的传输类是TSocket而非TUdpSocket或其他；
• 执行ss -tna命令，查看Thrift服务的监听端口对应的连接状态，TCP连接会显示ESTAB、LISTEN等状态。

关于eBPF SK_SKB程序是否引发资源竞争 #

空的SK_SKB程序仍会触发问题，说明不是程序逻辑本身的问题，而是加载SK_SKB程序这个行为导致了内核层面的变化，可能的原因包括：

• 内核skb处理路径延迟：SK_SKB程序挂载到cgroup ingress后，内核对数据包的处理链路新增了hook点，即使是空操作也会增加处理耗时。如果Thrift服务的超时阈值设置较严格，就可能触发THRIFT_EAGAIN；
• eBPF资源限制：虽然编译加载正常，但运行时可能遇到内存锁限制（RLIMIT_MEMLOCK），导致内核无法为eBPF程序或映射分配足够资源；
• SOCKHASH映射配置问题：如果映射的容量过小，压测时哈希表被占满，会导致数据包无法正常匹配或转发，进而引发服务端500错误；
• 内核版本兼容性bug：部分旧内核版本对SK_SKB的支持存在缺陷，比如处理skb时的竞态条件或资源泄漏；
• cgroup绑定错误：如果SK_SKB程序绑定的cgroup范围不正确，可能导致Thrift服务的数据包被错误拦截或未被正确处理，引发异常。

具体排查步骤 #

• 检查内核日志：执行dmesg | grep -i bpf，查看是否有eBPF相关的错误、警告（比如内存不足、程序验证失败、映射溢出等）；
• 查看SOCKHASH映射状态：用bpftool map show /sys/fs/bpf/sockops查看映射的已用元素数、总容量，确认是否存在溢出；
• 调整内存锁限制：执行ulimit -l unlimited后重新加载eBPF程序，验证问题是否缓解；
• 卸载SK_SKB程序测试：暂时卸载SK_SKB程序，确认Thrift服务和压测是否恢复正常，以此定位问题根源；
• 升级内核版本：如果使用的是5.4以下的旧内核，尝试升级到5.10及以上的稳定版本，修复已知的eBPF兼容性问题；
• 检查cgroup绑定范围：确认SK_SKB程序是否attach到了包含Thrift服务和压测工具的cgroup，避免数据包处理范围错误。

内容的提问来源于stack exchange，提问作者diviquery