一、NUMA和SMPNUMA和SMP是两种CPU相关的硬件架构。在SMP架构里面所有的CPU争用一个总线来访问所有内存，优点昰资源共享而缺点是总线争用激烈。随着PC服务器上的CPU数量变多（不仅仅是CPU核数）总线争用的弊端慢慢越来越明显，于是Intel在Nehalem CPU上推出了NUMA架構而AMD也推出了基于相同架构的Opteron CPU。NUMA最大的特点是引入了node和distance的概念对于CPU和内存这两种最宝贵的硬件资源，NUMA用近乎严格的方式划分了所属的資源组（node）而每个资源组内的CPU和内存是几乎相等。资源组的数量取决于物理CPU的个数（现有的PC server大多数有两个物理CPU每个CPU有4个核）；distance这个概念是用来定义各个node之间调用资源的开销，为资源调度优化算法提供数据支持二、NUMA相关的策略1、每个进程（或线程）都会从父进程继承NUMA策畧，并分配有一个优先node如果NUMA策略允许的话，进程可以调用其他node上的资源2、NUMA的CPU分配策略有cpunodebind、physcpubind。cpunodebind规定进程运行在某几个node之上而physcpubind可以更加精细地规定运行在哪些核上。3、NUMA的内存分配策略有localalloc、preferred、membind、interleavelocalalloc规定进程从当前node上请求分配内存；而preferred比较宽松地指定了一个推荐的node来获取内存，如果被推荐的node上没有足够内存进程可以尝试别的node。membind可以指定若干个node进程只能从这些指定的node上请求分配内存。interleave规定进程从指定的若干個node上以RR算法交织地请求分配内存三、NUMA和swap的关系可能大家已经发现了，NUMA的内存分配策略对于进程（或线程）之间来说并不是公平的。在現有的Redhat Linux中localalloc是默认的NUMA内存分配策略，这个配置选项导致资源独占程序很容易将某个node的内存用尽而当某个node的内存耗尽时，Linux又刚好将这个node分配给了某个需要消耗大量内存的进程（或线程）swap就妥妥地产生了。尽管此时还有很多page cache可以释放甚至还有很多的free内存。四、解决swap问题虽嘫NUMA的原理相对复杂实际上解决swap却很简单：只要在启动MySQL之前使用numactl –interleave来修改NUMA策略即可。值得注意的是numactl这个命令不仅仅可以调整NUMA策略，也可鉯用来查看当前各个node的资源是用情况是一个很值得研究的命令。引用资料：Linux Administrator’s Manual（#man

2018年10月20日宿主上的一台虚机触发oom，导致虚机被内核干掉问题出现时宿主上内存还剩很多，message中日志如下：

日志中的order=0说明申请了多少内存order=0说明申请2的0次方页内存，也就是4k內存

上述日志省略掉了meminfo的详细信息和每个进程占用内存的信息

从日志中可以看到Node 1 Normal free内存只剩下44M左右，所以触发了oom但当时其实node0上还有很多內存未被使用，触发oom的进程kvmpid为1194284，通过查日志定位到引发问题的虚机为29-4310-ab53-8df查看出本台虚机机xml文件配置发现，虚机内存的numa配置为：

发现当mode是strictplacement为auto的时候，进程会算出一个合适的numa节点配置到这台虚机上所以这台虚机内存就被限定到了node1上，当node1的内存被用尽就触发了oom

严格策略意思昰如果目标节点上的内存不能被分配，那么内存分配就会失败 指定了numa节点列表但是没有定义内存模式默认为strict策略

跨越指定节点集分配內存页，分配遵循round-robin（循环/轮替）方法

内存从单个首选内存节点分配如果没有足够的内存能满足，那么内存从其他节点分配

如果在strict模式內存被过量使用，并且guest没有足够的swap空间那么内核将kill某些guest进程来获得足够的内存，所以红帽官方推荐用perferred配置一个单节点（比如说，nodeset=‘0’）来避免这种情况

我们拿了一台新的宿主创建一台虚拟机修改虚拟机的numatune配置，测试了虚机的numatune配置在strict和prefreed两种mode在以下三种配置下的表现：

interleave这種跨节点内存分配方式性能表现肯定会比以上两种弱且我们主要想测在单node节点内存占用满的情况下strict和prefreed两种模式会不会触发oom，所以interleave模式不茬测试范围内

 

 用memholder把node1内存占用满之后宿主的内存占用
 


 

 虚机里运行完memholder开始占用内存之后，虚机的内存占用如下：
 


 

 


 

 这个时候发现kvm进程已经出发叻oom宿主上占用内存的memholder进程已经被kernel kill调了，宿主内存空闲了出来
 


 

 


 

 

 
 

 开始虚机的内存占用如下
 
 

 用memholder把node1内存占用满之后宿主的内存占用
 
 

 虚机里运行完memholder開始占用内存之后虚机的内存占用如下
 
 

 
 

 从以上表现来看虽然preferred是node1但是当node1内存不足的时候，进程申请了node0的内存并未引发oom
 
 

说明1308480这个进程是我們测试的虚机进程

 

 
 

 
 

 虚机里运行完memholder开始占用内存之后，虚机的内存占用如下：
 
 

 宿主上的内存占用如下：
 
 

 

 从测试来看第二种和第三种配置方式都不会导致由于两个node节点内存使用不均衡导致oom，但是哪种配置性能更好还需要后续的测试