1. NUMA架构与多核网络性能优化导论

当一台服务器从单路四核演进到双路64核、128线程时，很多工程师会直觉地认为网络吞吐量应当线性增长。但真实压测中经常出现相反的现象：CPU利用率还没到70%，网卡收包速率却已经上不去，或者单流吞吐量比单核时代还低。这类问题的根源，往往不在网卡驱动本身，而在于CPU与内存之间的访问距离——这正是NUMA（Non-Uniform Memory Access，非统一内存访问）架构带来的核心矛盾。

一、NUMA基本概念：内存访问为什么"不均匀"

在早期的SMP（对称多处理）架构中，所有CPU通过一条前端总线访问同一块内存，任意核心访问任意内存地址的延迟基本一致，这就是UMA（统一内存访问）。但随着核心数量增加，共享总线成为瓶颈，于是硬件厂商把内存控制器分散到各个CPU插槽旁，形成多个"节点"（Node）。每个节点包含一组CPU核心、本地内存控制器和本地内存条，节点之间通过高速互连（如Intel的UPI、AMD的Infinity Fabric）通信。

关键差异在于：核心访问本地节点内存（Local Access）只需经过本地内存控制器，延迟通常在80～100纳秒；而访问远端节点内存（Remote Access）需要跨互连跳转，延迟可能达到140～200纳秒，带宽也明显下降。这种"本地快、远端慢"的特性，就是NUMA的本质。Linux用numactl --hardware可以查看节点拓扑，典型双路服务器输出如下：

available: 2 nodes (0-1)
node 0 cpus: 0 1 2 ... 31
node 0 size: 128000 MB
node 1 cpus: 32 33 ... 63
node 1 size: 128000 MB
node distances:
node   0   1
  0:  10  21
  1:  21  10

其中distance矩阵的"10"表示本地访问相对代价，"21"表示跨节点访问代价约为本地的2.1倍。这个数字不是装饰，它直接决定了网络数据包处理时内存拷贝、描述符读取、缓冲区分配的真实开销。

二、多核网络性能瓶颈：NUMA如何拖慢数据包处理

网络收包路径对内存延迟极其敏感。以典型的NAPI收包为例，网卡通过DMA把数据包写入内存中的RX Ring缓冲区，然后触发中断，CPU核心读取描述符、分配skb、拷贝数据、走协议栈。这条路径上至少有三处会踩到NUMA陷阱：

• 缓冲区分配错位：如果处理中断的CPU核心属于Node 1，但RX Ring缓冲区当初是在Node 0上分配的，那么每次DMA写入和CPU读取都要跨节点，延迟翻倍。
• 中断与核心不匹配：网卡中断默认可能被路由到任意核心，若中断落在远端节点，处理线程访问本地网卡队列描述符时反而变成远端访问。
• 跨节点锁竞争：多队列网卡配合RSS时，若多个队列的中断集中到同一节点，该节点内存带宽和缓存会被争抢，而另一节点空闲。

一个可观察的示例：在双路服务器上用iperf3做单流TCP测试，若把服务端进程绑定到Node 0核心，但网卡队列中断却落在Node 1，常见结果是吞吐量比正确绑定时低20%～40%，同时perf stat会显示LLC-miss和远端内存访问比例显著上升。这说明瓶颈不在网卡线速，而在内存访问路径。

三、课程目标与学习路径

本课程的目标不是背诵NUMA定义，而是建立一套"从拓扑观察到性能调优"的完整能力：能读懂节点距离矩阵，能把网卡队列、中断、进程、内存四者的归属关系对齐到同一节点，能用工具验证优化前后远端访问比例和吞吐量的变化。

学习路径按"认知—观测—干预—验证"推进：先理解NUMA拓扑与网络数据通路的关系；再掌握numactl、numastat、perf、ethtool等观测手段；然后进入中断亲和性设置、RSS/RPS调优、内存绑定与本地分配等干预手段；最后通过对照压测确认收益，并识别过度绑核导致的负载不均等反效果。后续章节会围绕这条主线，逐层展开从单机到多队列、从内核态到用户态（如DPDK）的NUMA优化实践。