# 阶段 5：深入 NUMA 架构（Day 13-16）

> **撞上的问题**：RSS + IRQ 优化后 8 核都用上了，但运行一段时间后发现：同一台机器上两个 4 核组的延迟明显不同，进程所在的内存访问延迟也不稳定。

## 背景

到这里你还没注意到 NUMA 的存在。前 4 个阶段的所有优化都在"把整台机器当一块均匀资源"的假设下进行。现在 CPU 均衡了，性能层级的差异才开始暴露。

## 每日概览

| 天 | 主题 | 关键实验 | 对比维度 |
|:--:|------|------|------|
| Day 13 | [发现 NUMA 拓扑](/demos/echo/day-13/README.md) | `lscpu` 看到 2 个 NUMA 节点，`numactl --hardware` 看到每节点 4 核 + 16G 内存 | NUMA 拓扑可视化 |
| Day 14 | [进程 CPU 绑定实验](/demos/echo/day-14/README.md) | `taskset -c 0-3` vs `taskset -c 4-7` vs 不绑核，对比 QPS/P99 | 三种模式的性能差异 |
| Day 15 | [跨 NUMA 内存访问](/demos/echo/day-15/README.md) | 进程跑在 Node0，内存分配在 Node1 vs Node0，测延迟差异 | `numa_miss` 计数、P99 延迟 1.5-2 倍恶化 |
| Day 16 | [双 NUMA 多进程拆分](/demos/echo/day-16/README.md) | 单 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 拆分可获得接近翻倍的吞吐。