本文转载自：https://www.jianshu.com/p/0607c5f62c51
导读
本文适合知道NUMA这个词但想进一步了解的新手。
以下的文章内容包括：NUMA的产生背景，NUMA的架构细节和几个上机演示的例子。
NUMA的诞生背景
在NUMA出现之前，CPU朝着高频率的方向发展遇到了天花板，转而向着多核心的方向发展。
在一开始，内存控制器还在北桥中，所有CPU对内存的访问都要通过北桥来完成。此时所有CPU访问内存都是“一致的”，如下图所示：
UMA
这样的架构称为UMA(Uniform Memory Access)，直译为“统一内存访问”，这样的架构对软件层面来说非常容易，总线模型保证所有的内存访问是一致的，即每个处理器核心共享相同的内存地址空间。但随着CPU核心数的增加，这样的架构难免遇到问题，比如对总线的带宽带来挑战、访问同一块内存的冲突问题。为了解决这些问题，有人搞出了
NUMA。
NUMA构架细节
NUMA 全称 Non-Uniform Memory Access，译为“非一致性内存访问”。这种构架下，不同的内存器件和CPU核心从属不同的 Node，每个 Node 都有自己的集成内存控制器（IMC，Integrated Memory Controller）。
在 Node 内部，架构类似SMP，使用 IMC Bus 进行不同核心间的通信；不同的 Node 间通过QPI（Quick Path Interconnect）进行通信，如下图所示：
NUMA
一般来说，一个内存插槽对应一个 Node。需要注意的一个特点是，QPI的延迟要高于IMC Bus，也就是说CPU访问内存有了远近（remote/local）之别，而且实验分析来看，这个差别非常明显。
在Linux中，对于NUMA有以下几个需要注意的地方：
- 默认情况下，内核不会将内存页面从一个 NUMA Node 迁移到另外一个 NUMA Node；
- 但是有现成的工具可以实现将冷页面迁移到远程（Remote）的节点：NUMA Balancing；
- 关于不同 NUMA Node 上内存页面迁移的规则，社区中有依然有不少争论。
对于初次了解NUMA的人来说，了解到这里就足够了，本文的细节探讨也止步于此，如果想进一步深挖，可以参考开源小站这篇文章。
上机演示
NUMA Node 分配
numactl --hardware
NUMA Node 分配
作者使用的机器中，有两个 NUMA Node，每个节点管理32GB内存。
查看指定进程NUMA使用情况
numastat -p `ps -aux | grep 'top' | grep -v 'grep' | awk '{print $2}'`
TOP 进程 NUMA Node 使用情况
NUMA 状态
numastat
NUMA 状态
设置进程在指定的CPU核心上运行
numactl --physcpubind=1 top
其中，physcpubind后面的数字只能是`numactl --show`中的physcpubind字段，否咋无效
设置进程在指定的Node上运行
numactl --cpunodebind=0 top
其中，cpunodebind后面的数字只能是`numactl --show`中的nodebind字段，否则无效。
执行以上命令的结果，如果CPU核心0、2、6、8在Node0上，则top进程会在CPU核心0、2、6、8上运行。
设置进程在指定的Node上分配内存
numactl --membind=0 top
其中，membind选项对new分配的内存和shm分配(如果shm文件已存在，必须先删除)的内存有效。
可以时候用`numastat –p $pid`命令查看进程内存使用情况。
其他参考：