📚 课程目录第1章课程导入与协同优化全景

1. 课程导入与协同优化全景

在 Intel Xeon 服务器上，网络与存储往往被当作两条独立的优化路径：网络团队调网卡队列、中断亲和性与 RoCE 参数，存储团队调 NVMe 队列深度、文件系统与 RAID 策略。但在真实业务里，二者共享同一颗 CPU 的物理核心、Last Level Cache、内存带宽、PCIe 通道与 NUMA 节点资源。任何一侧的“局部最优”都可能把另一侧拖入瓶颈。本课程要建立的，正是把网络与存储放在同一资源视图下协同优化的方法论。

一、协同优化的目标与边界

协同优化的目标可以概括为一句话：在给定硬件拓扑与业务 SLA 下，让网络 I/O 与存储 I/O 共享的 CPU、内存、PCIe 资源被最有效地利用，使端到端时延、吞吐与 CPU 效率同时达标。它不是追求单项跑分最高，而是追求“木桶最短的那块板”被抬高。

边界同样需要明确。协同优化不负责：应用层协议设计、业务代码逻辑改造、交换机与存储阵列的固件级调优、跨机房网络规划。它负责的是服务器内部：CPU 核与缓存分配、NUMA 亲和性、PCIe 拓扑与带宽、中断与轮询模式、队列深度与批处理、内存与缓冲区管理、以及网络与存储路径之间的资源竞争仲裁。

判断一个优化项是否属于本课程范围，可以问：它是否改变了 Xeon 服务器内部网络与存储对 CPU/内存/PCIe 的争用关系？如果是，就属于协同优化；如果只影响外部设备或应用逻辑，则不属于。

二、关键指标：从单侧指标到协同指标

单侧指标大家都熟悉：网络侧看吞吐（Gbps）、PPS、时延（μs）、重传率；存储侧看 IOPS、带宽（GB/s）、时延（μs）、队列深度。但协同优化需要引入一组“交叉指标”，它们才真正暴露资源争用：

每 Gbps 网络吞吐消耗的 CPU 核数：反映网络路径的 CPU 效率，也间接反映其与存储争抢核心的程度。
每万 IOPS 存储访问消耗的 CPU 核数：反映存储路径的 CPU 开销。
LLC 命中率与内存带宽占用：网络收包与存储数据搬运都吃内存带宽，二者叠加时最容易在此处爆掉。
PCIe 根端口带宽利用率：网卡与 NVMe 若挂在同一 PCIe Switch 或同一 CPU 的根端口下，会互相挤占。
端到端 P99 时延：协同优化最终要守住的是尾时延，而非平均时延。

这些指标的意义在于：当网络吞吐上升导致存储 P99 时延恶化时，单看任何一侧的指标都正常，只有交叉指标能定位到“CPU 核争用”或“内存带宽饱和”。

三、整体方法论：四层协同视图

本课程把协同优化组织为四层，自下而上依次是：硬件拓扑层 → 资源分配层 → 协议与驱动层 → 业务观测层。下层决定上层的可行空间，上层反过来暴露下层的瓶颈。下图给出这四层之间的关系，以及每层最关键的协同对象。

四层视图的价值在于：当出现性能问题时，先判断瓶颈落在哪一层，再决定调整方向。例如，若交叉指标显示“每 Gbps 核数”异常高，问题可能在协议与驱动层（中断过多、未启用轮询）；若 LLC 命中率骤降且内存带宽接近饱和，问题可能在资源分配层（网络与存储缓冲区争抢 LLC）；若 PCIe 根端口利用率已超 80%，则硬件拓扑层已无优化空间，只能改挂载位置或升级拓扑。

四、一个可复现的入门观测示例

下面给出一个用于建立“协同基线”的观测流程，示例参数属于合理假设，用于说明方法而非实测结论。假设一台双路 Xeon 服务器，网卡与 NVMe 分别挂在 CPU0 和 CPU1 的 PCIe 根端口下，业务为“网络收包后写入本地 NVMe”。

# 1. 查看 NUMA 与 PCIe 挂载关系
lspci -tv | grep -E "Ethernet|Non-Volatile"
cat /sys/class/net/ens1f0/device/numa_node
cat /sys/block/nvme0n1/device/numa_node

# 2. 建立网络侧基线（示例：单流 TCP 收包）
sar -n DEV 1 10          # 观察 rxpck/s、rxkB/s
mpstat -P ALL 1 10       # 观察各核 %soft、%sys

# 3. 建立存储侧基线（示例：4K 随机写）
fio --name=w --rw=randwrite --bs=4k --iodepth=32 \
    --numjobs=4 --ioengine=io_uring --time_based --runtime=30

# 4. 同时施加网络与存储负载，观察交叉指标
#    记录：网络 Gbps、存储 IOPS、P99 时延、总 CPU 核数占用

判断依据：若单独跑网络时 P99 为 80μs，单独跑存储时 P99 为 120μs，而同时跑时网络 P99 升至 400μs、存储 P99 升至 900μs，且 mpstat 显示软中断集中在少数几个核上，则说明二者在 CPU 核与中断资源上发生争用。此时协同优化的第一步不是调网卡参数，而是把网络软中断与存储完成中断分散到不同物理核，并检查二者是否跨 NUMA 访问内存。

常见误区：把网络与存储分别调到各自最优后直接叠加，认为整体就会最优。实际上二者共享 LLC 与内存带宽，分别最优往往导致叠加后尾时延显著恶化。协同优化的起点是“同时观测”，而非“分别调优”。

五、本课程的组织方式

后续章节将沿四层视图展开：先讲硬件拓扑与 NUMA 亲和如何决定优化上限，再讲 CPU 核隔离、LLC 与内存带宽分配，然后进入网络侧（RSS、中断、RoCE）与存储侧（NVMe 多队列、io_uring、SPDK）的具体协同手段，最后用端到端案例与排障方法把四层串起来。每一节都会给出可观测的指标、可执行的命令或配置，以及结果判断依据，使读者能够在自己的 Xeon 服务器上复现并验证。

需要始终记住的核心判断：网络与存储的协同优化，本质是对共享资源（CPU 核、LLC、内存带宽、PCIe、NUMA）的分配与仲裁。任何一项调整，都要问它改变了哪一项共享资源的争用关系，以及这种改变是否被交叉指标所验证。