DPDK高性能交换机深度实践：一次Hugepage碎片化引发的“隐性性能衰退”故障分析

一、故障背景

某云数据中心部署了一套基于DPDK的软件交换机集群。

主要承担：

• VXLAN Gateway
• EVPN Leaf
• IPv4/IPv6 Routing
• ACL Filtering
• Telemetry Export

硬件配置：

上线初期：

64B PPS： 95Mpps

稳定运行。

三个月后：

95Mpps ↓ 87Mpps ↓ 79Mpps ↓ 68Mpps

持续下降。

但：

CPU = 100%

始终不变。

重启后：

68Mpps ↓ 95Mpps

立即恢复。

二、第一次排查

首先查看：

dpdk-proc-info

RX统计：

imissed = 0

TX统计：

oerrors = 0

RSS：

均衡

Mempool：

正常

FIB：

正常

ACL：

正常

没有任何传统瓶颈。

三、发现一个奇怪规律

运维团队发现：

性能下降并非突然发生。

而是：

每天下降一点点

这种现象非常不符合：

• Descriptor耗尽
• RSS倾斜
• ACL膨胀

等典型问题。

更像：

某种资源长期退化

四、重新审视DPDK内存体系

DPDK启动：

--huge-dir=/dev/hugepages

其核心思想：

不是普通malloc。

而是：

Hugepage ↓ memseg ↓ mempool ↓ mbuf

典型结构：

五、为什么DPDK依赖Hugepage

原因很多。

但最重要的是：

TLB覆盖范围。

CPU访问内存：

VA ↓ TLB ↓ PA

如果TLB未命中：

Page Walk

开始。

延迟：

几十到数百Cycle

六、TLB Reach

以Ice Lake为例：

L1 DTLB：

64 Entries

覆盖：

4KB页：

64 × 4KB =256KB

而1GB页：

64 × 1GB =64GB

差距：

262144倍

七、问题开始出现

进一步分析。

发现交换机运行期间：

控制面持续创建：

• Telemetry对象
• Flow统计对象
• Mirror对象

这些对象：

最终进入：

rte_malloc()

体系。

虽然最终释放。

但：

长期创建 ↓ 长期销毁

形成：

Hugepage内部碎片

八、什么是Hugepage碎片化

很多工程师理解：

碎片化 = 内存不足

其实不是。

示意：

正常：

Hugepage [连续空间]

运行数月：

[对象] [空洞] [对象] [空洞] [对象]

形成：

Fragmentation

九、为什么会影响性能

关键来了。

DPDK分配新对象时：

原来：

连续内存

后来：

跨多个memseg

结果：

CPU访问：

Flow Table ACL Metadata Route Cache

需要：

更多TLB Entry

十、Perf验证

使用：

perf stat

统计：

dTLB-load-misses

正常：

0.2%

异常：

5.8%

增长：

29倍

十一、为什么CPU仍然100%

因为：

PMD：

while(1) { rte_eth_rx_burst(); process(); rte_eth_tx_burst(); }

不会停。

CPU依旧：

100%

但：

每个包：

TLB Miss ↑ Page Walk ↑ Cycles ↑

结果：

Cycles/Packet 增加

吞吐下降。

十二、进一步发现

查看：

cat /proc/pid/smaps

发现：

Hugepage映射数量：

正常：

18

异常：

147

说明：

原本：

少量大块

变成：

大量离散区域

十三、验证实验

重启交换机。

重新压测：

95Mpps

恢复。

再运行：

60天

后：

76Mpps

现象复现。

十四、根因确认

完整链路：

长期运行 ↓ 对象频繁创建销毁 ↓ Hugepage内部碎片 ↓ Memseg离散 ↓ TLB Miss增加 ↓ Page Walk增加 ↓ Cycles/Packet增加 ↓ PPS下降

十五、解决方案

方案一

对象池化。

禁止：

rte_malloc() rte_free()

频繁调用。

改：

预分配 对象复用

方案二

控制面独立内存区

Telemetry：

独立Memzone

Mirror：

独立Memzone

避免污染转发面。

方案三

定期监控Memseg

使用：

dpdk-proc-info --memzones

观察：

Memseg数量

趋势。

方案四

采用1GB Hugepage

而不是：

2MB Hugepage

减少TLB压力。

优化结果

核心知识点总结

1

DPDK性能退化不一定来自流量增长。

也可能来自：

内存布局退化

2

Hugepage不是用了就完事。

长期运行后的：

碎片化

同样重要。

3

CPU 100%不能说明系统健康。

真正指标是：

Cycles Per Packet

4

TLB Miss是DPDK系统最容易被忽略的性能指标之一。

5

长期运行交换机的性能管理，本质上也是：

内存生命周期管理

6

控制面对象频繁创建销毁，可能间接影响数据面。

7

高性能交换机最终优化目标不仅是：

少拷贝 少锁 少Cache Miss

还包括：

保持长期稳定的内存连续性

这个主题与本项目之前涉及的 RSS、ACL、NUMA、FIB、Neighbor、DDIO、PCIe、Flow Affinity、TX Completion 都不同，属于DPDK长期运行稳定性与内存体系设计范畴，也是很多运营商级软件交换机上线数月后才会暴露出来的隐蔽问题。