一、故障背景某运营商数据中心部署了一套基于DPDK开发的100G高性能交换机。系统承担二层交换IPv4/IPv6三层转发VXLAN GatewayACL过滤服务器配置如下配置项参数CPUIntel Xeon Gold 双路网卡Intel 100GbEDPDK24.11 LTSHugePage1GB HugePagePMD Worker16个系统上线半年一直稳定运行。某次版本升级以后压力测试发现一个奇怪现象。开始10分钟系统性能正常。持续运行约30分钟以后PPS开始出现周期性下降。每隔几十秒都会出现一次明显下降。持续时间约几十毫秒。随后恢复正常。整个过程不断重复。二、第一轮排查首先怀疑是不是网卡出现异常查看DPDK统计struct rte_eth_stats stats; rte_eth_stats_get(port, stats);结果imissed 0 ierrors 0 rx_nombuf 0继续查看ethtool -S eth0重点统计CRC ErrorRX MissDMA ErrorBuffer Error全部为0。说明网卡完全正常。核心知识点一DPDK统计的是软件能够观察到的状态。如果性能下降发生在Cache竞争内存分配CPU同步这些问题通常不会反映到网卡统计信息中。因此没有Error并不意味着没有性能问题。三、第二轮排查继续观察每个PMD Worker。结果如下WorkerCPUWorker0100%Worker1100%Worker2100%……100%CPU全部100%。这完全符合DPDK Poll Mode Driver的工作方式。继续统计RSS分布。发现16个Worker流量几乎一致。RX Queue没有积压。TX Queue没有阻塞。说明既不是RSS失衡。也不是Queue瓶颈。核心知识点二DPDK系统中CPU利用率并不是判断性能瓶颈的重要指标。真正需要关注的是每Packet CycleIPCCache命中率内存访问模式四、Perf开始暴露异常既然软件逻辑没有问题。开始使用perf stat \ -e cycles,instructions,cache-misses \ -p PMD_PID得到如下结果指标正常阶段抖动阶段Instructions基本一致基本一致Cycles略增加↑↑IPC1.921.61Cache Miss小幅增加小幅增加Cache Miss并没有明显变化。但是CPU执行效率明显下降。说明CPU不是在计算而是在等待。等待什么继续分析。五、真正的异常开始出现为了进一步定位。我们开启DPDK Telemetry并增加了Mempool统计rte_mempool_avail_count(mp); rte_mempool_in_use_count(mp);压测过程中发现每当系统吞吐下降时Global Pool对象数量开始剧烈波动。而Per-lcore Cache几乎全部被耗尽。几十毫秒后Cache重新填满性能恢复。又过一段时间。再次重复。这说明问题并不是mbuf数量不足。而是mbuf流转路径出现了异常。核心知识点三DPDK申请mbuf并不是每次都访问Global Pool。真正的数据路径首先经过Per-lcore Cache。只有Cache不足。才会访问Global Pool。因此Per-lcore Cache才是真正决定高速收发性能的关键。六、Mempool到底是如何工作的很多开发者认为Mempool就是一个对象池。实际上DPDK为了减少多核竞争在Global Pool之外又增加了一层Per-lcore Cache。真正结构如下Global Pool │ ┌──────────────┼──────────────┐ │ │ │ Worker0 Cache Worker1 Cache Worker2 Cache │ │ │ mbuf mbuf mbuf正常情况下Worker收包。释放mbuf。再次申请mbuf。几乎全部发生在自己的Cache里面。整个过程不会访问Global Pool。也不会产生跨核竞争。这也是DPDK能够支撑数亿PPS的重要原因之一。但是。如果Per-lcore Cache配置不合理。整个机制反而会成为性能瓶颈。七、问题逐渐浮出水面继续阅读DPDK源码。定位到lib/mempool/rte_mempool.c其中rte_mempool_get_bulk()首先尝试从Per-lcore Cache获取对象。只有Cache不足。才会访问Global Ring。而Global Ring正是所有Worker共享的资源。问题似乎开始指向这里……