4. 内存层次与延迟带宽特性

在容量规划中，如果只统计“总内存够不够”，往往会得出错误结论。内存密集型业务的性能瓶颈，通常不在容量本身，而在访问路径的延迟与带宽。Intel Xeon 平台的内存层次从寄存器、L1/L2/L3 缓存，到本地 DDR 内存，再到跨 UPI 链路访问的远程内存，每一层的延迟和带宽差异可达一个数量级以上。理解这些差异，是判断“该扩内存、该调 NUMA、还是该换平台”的前提。

一、内存层次的延迟与带宽量级

先建立量级概念。以下数值为 Intel Xeon 平台的典型参考范围，用于教学对比，实际值随具体型号、频率、BIOS 配置和负载变化：

关键结论有三点。第一，缓存命中与内存访问之间存在数量级差距，因此“工作集能否装进 L3”直接决定性能档位。第二，本地内存与远程内存的延迟差距约 1.5–2 倍，看似不大，但在高并发、指针追逐、锁竞争场景下会被放大。第三，远程访问不仅延迟高，还会占用 UPI 带宽，形成“延迟+带宽”双重损耗。

二、NUMA 架构如何放大差异

双路 Intel Xeon 是典型的 NUMA 架构：每个 socket 有自己的内存控制器和本地 DDR，两个 socket 之间通过 UPI 互联。CPU 访问本地内存走本地控制器，访问另一个 socket 的内存则要经过 UPI 链路。操作系统把物理内存划分为多个 NUMA 节点，默认策略通常是“本地优先分配”，但线程迁移、内存首次触碰位置、容器绑核不当都会导致远程访问比例上升。

对内存密集型业务，NUMA 影响体现在三个层面：

• 延迟敏感型：如内存数据库索引查找、实时风控，远程访问比例每上升 10%，尾延迟可能明显恶化。
• 带宽敏感型：如流式分析、大页扫描，跨 socket 流量会挤占 UPI，导致整体吞吐下降。
• 缓存一致性：跨 socket 共享数据的缓存行会在 UPI 上反复同步，产生额外开销。

三、从延迟带宽到容量规划的换算

容量规划不能只看 GB，还要看“有效带宽”和“并发延迟预算”。一个实用估算方法是：先测出单次访问延迟 L，再结合业务并发度 C，估算所需内存带宽 B ≈ 数据量 × 访问频率。若远程访问比例为 r，则有效延迟约为 L_local × (1−r) + L_remote × r。举例说明（以下为教学示例，非实测）：某业务本地延迟 90 ns，远程延迟 160 ns，远程占比 30%，则有效延迟约 111 ns，比纯本地高约 23%。若该业务对延迟敏感，就应优先通过绑核、NUMA 绑定把远程占比压到 10% 以内，而不是盲目加内存。

带宽侧同理。假设单 socket 本地内存带宽约 200 GB/s，UPI 双向带宽约 100 GB/s 量级。若业务跨 socket 流量达到 60 GB/s，UPI 就会成为瓶颈，此时增加本地内存容量并不能提升吞吐，反而可能因远程访问比例上升而恶化。

四、容量规划中的实操判断

把上述特性落到规划动作上，可按以下顺序排查：

1. 先看工作集大小：若热数据能装进 L3，容量规划重点在缓存争用而非内存容量；若远超 L3，则进入内存带宽与 NUMA 优化区间。
2. 再看远程访问比例：用 numastat -p <pid> 观察进程各 NUMA 节点的本地/远程分配。远程占比高时，优先用 numactl --cpunodebind=0 --membind=0 绑定，或调整容器 cpuset。
3. 然后看带宽余量：用 pcm-memory 或 perf stat -e uncore_imc/data_reads/ 观察内存控制器吞吐。若本地带宽接近上限，增加容量无用，应减少跨 socket 流量或升级平台。
4. 最后才考虑加内存：只有当工作集确实超出物理容量、且已排除 NUMA 与带宽瓶颈时，扩容才是有效手段。