抽丝剥茧：生产环境中负载均衡产品DPDK问题的解决

ULB4是UCloud自主研发的基于DPDK的高可用四层负载均衡产品，转发能力接近线速；DPDK则是一个高性能的开源数据面开发套件。ULB4作为用户应用的全局入口，在大流量多元化场景下保证用户业务的持续稳定至关重要，这也是UCloud网络产品团队的技术使命。尤其现网单个ULB集群承载带宽已达10G，包量83万PPS，运行环境复杂，即使面临突发因素(比如触发未知BUG)，我们也要设法保证产品正常工作，避免产生严重影响。

近期，我们在ULB4的线上环境中，发现了一个DPDK的发包异常现象，由于整个ULB产品为集群架构，该异常并未导致用户服务不可用。但为了任何时刻都能保证用户服务的足够稳定，团队通过GDB、报文导出工具、生产环境流量镜像等手段，从现网GB级流量中捕获异常报文，再结合DPDK源码分析，定位到原因出自DPDK本身的BUG并修复解决。期间未对用户业务造成影响，进一步保证了UCloud数万ULB实例的稳定运行。

本文将从问题现象着手，抽丝剥茧，详述问题定位、分析与解决全过程，希望能为ULB用户和DPDK开发者提供参考与启迪。

问题背景

在12月初一向稳定的ULB4集群中突然出现了容灾，某台ULB4服务器工作异常被自动移出了集群。当时的现象是：

转发面服务监控到网卡接收方向流量正常，但是发送方向流量为0，重启转发面服务后又可以正常收发，同时集群其他机器也会不定期出现异常情况。对用户业务而言，会出现少量连接轻微抖动，随后迅速恢复。

下面是整个问题的处理过程，我们在此过程中做出种种尝试，最终结合DPDK源码完成分析和解决，后续也准备将自研的报文导出工具开源共享。

问题定位与分析

ULB4集群一直很稳定地工作，突然陆续在集群的不同机器上出现同样的问题，并且机器恢复加入集群后，过了一段时间又再次出现同样的问题。根据我们的运营经验，初步猜测是某种异常报文触发了程序BUG。但是，面对GB级流量如何捕获到异常报文？又如何在不影响业务情况下找出问题呢？

一、GDB调试报文，发现疑点

想要知道整个程序为什么不发包，最好的办法就是能够进入到程序中去看看具体的执行过程。对于DPDK用户态程序来说，GDB显然是一个好用的工具。我们在发包程序逻辑中设置断点，并通过disassemble命令查看该函数的执行逻辑，反汇编之后足足有七百多行。（该函数中调用的很多函数都使用了inline修饰，导致该函数在汇编之后指令特别多）

结合对应DPDK版本的源码，单条指令一步步执行。在多次尝试之后，发现每