阶段 5：深入 NUMA 架构（Day 13-16）
⏳ 状态：规划中。
撞上的问题：RSS + IRQ 优化后 8 核都用上了，但运行一段时间后发现：同一台机器上两个 4 核组的延迟明显不同，进程所在的内存访问延迟也不稳定。
背景
到这里你还没注意到 NUMA 的存在。前 4 个阶段的所有优化都在"把整台机器当一块均匀资源"的假设下进行。现在 CPU 均衡了，性能层级的差异才开始暴露。
每日概览
| 天 | 主题 | 关键实验 | 对比维度 |
|---|---|---|---|
| Day 13 | 发现 NUMA 拓扑 | lscpu 看到 2 个 NUMA 节点，numactl --hardware 看到每节点 4 核 + 16G 内存 | NUMA 拓扑可视化 |
| Day 14 | 进程 CPU 绑定实验 | taskset -c 0-3 vs taskset -c 4-7 vs 不绑核，对比 QPS/P99 | 三种模式的性能差异 |
| Day 15 | 跨 NUMA 内存访问 | 进程跑在 Node0，内存分配在 Node1 vs Node0，测延迟差异 | numa_miss 计数、P99 延迟 1.5-2 倍恶化 |
| Day 16 | 双 NUMA 多进程拆分 | 单 NUMA 8 进程 vs 双 NUMA 各 4 进程 + IRQ 对齐 | QPS 接近翻倍 |
核心发现
| 配置 | QPS | P99 | numa_miss/s |
|---|---|---|---|
| 无绑定（基线） | 基准 | 基准 | 轻微 |
| CPU + 内存同节点 | ▲ 略高 | ▼ 略低 | ≈ 0 |
| CPU + 内存跨节点 | ▼▼ 显著低 | ▲▲ 显著高 | 大量 |
| 双 NUMA 拆分 + IRQ 对齐 | ▲▲ 最高 | ▼▼ 最低 | ≈ 0 |
关键产出脚本：
numa-bind-server.sh、numa-split-server.sh、numa-benchmark.sh、numa-check.sh
完工验证清单
- [ ] 能画出机器 NUMA 拓扑图
- [ ] 能复现跨节点内存访问的延迟惩罚
- [ ] 能通过
numastat观测 numa_miss - [ ] 双 NUMA 拆分后 QPS 对比基线有明确提升
一句话总结：NUMA 不是需要"预先配置"的东西——它是你在 CPU 均衡后仍然发现性能差异时才会遇上的深层概念，就近原则（进程-内存-中断同节点）是核心，双 NUMA 拆分可获得接近翻倍的吞吐。