早期的计算机系统一直处于硬件资源匮乏的阶段，CPU，内存都是十分稀缺的资源，因此在发展SMP架构的系统的时候，早期都是使用UMA（统一内存架构）的架构的，所有的CPU访问内存的时候都是通过北桥的总线控制器统一访问内存。
内存上的数据通过总线可以以相同的延时传输给任何一颗CPU。在只有一两颗CPU，几百M内存的服务器上，这一切都不是问题。不过随着计算机技术的发展，服务器上的CPU越来越多，内存也越来越多，总线无法支撑这种UMA架构了。于是NUMA出现了。
在NUMA架构下，CPU被分为多个node,内存也被划分到不同的Node，于是本地内存，本地共享内存，远程内存等概念就出现了（不同的厂商在实现NUMA上有不同，内存的划分也会有所不同）。从图上我们也可以看出，如果CPU1要访问memory 0，那么是无法直接访问的，需要通过CPU0来访问。这种远程访问的速度肯定是比本地访问要低的多的。我们来看看一个实际的案例。这是老白的一台服务器，INTEL E8 两路服务器，每颗CPU有18核。
从上面的数据我们可以看到，这个服务器上有两个node 0/1，node distances就是node上内存访问的距离，距离越远访问性能越差，这个指标是线性的，我们可以看到，0-0/1-1的访问距离是10，0-1/10的访问距离是21，也就是说远程访问的延时是本地访问的2.1倍。另外一个我们可以看到的是，这台服务器有64G内存，每个NODE分配了32G，不过NODE 0的FREE内存已经使用的差不多了，而NODE 1才分配了不到一半。从这里我们可以看出，NUMA对于内存的分配不是均匀的，或者说NUMA架构可能会导致内存分配在NODE之间的不均衡。在没有仔细研究NUMA之前，老白作为一个DBA，遵从官方文档，尽可能在操作系统层和数据库层关闭NUMA，认为只要关闭了NUMA，就可以万事大吉了。直到真正认真的研究了NUMA，才发现以前的认知是错误的。在OS层和RDBMS层关闭NUMA，只是避免了一些RDBMS的BUG，实际上并没有本质上解决NUMA的问题。因此NUMA是一个物理的存在，并不能在软件层面上去解决它。最主要的问题就是我们在上面所看到的两个问题，一个是远程内存访问性能，一个是节点间的内存分配不均衡。第一个问题比较清晰，我们就不做深入的讨论了，对于内存分配不均衡的问题。这是怎么产生的呢？实际上对于NUMA架构，操作系统已经做了一定的优化，比如当我们的某个线程在CPU上运行时，OS总是尽可能的分配LOCAL内存给这个线程，从而确保其访问的性能。如果某个NUMA NODE上的内存不足的时候，那么就要尽可能的将部分本节点上的内存SWAP了，然后腾出内存给需要在本节点分配内存的其他线程使用。这就导致了我们看到物理内存还有很多的FREE，但是SWAP的使用率也很高了。这种SWAP就会导致部分应用的性能下降。这也是我们可以在一台1路或者2路服务器上很轻松的把CPU使用率压得很高，但是在一台8路服务器上，我们再怎么优化也很难把CPU压满的一个原因。对于普通的大量的可均匀分配的主要访问本地内存的应用，比如WEB访问，NUMA架构还是能够很好的发挥其效果的。而对于数据库这样的大量使用大规模共享内存的应用来说，就不可避免在运行过程中去访问远程内存了。
这是Oracle 的一个后台进程的numa map，可以看到很多内存是在多个Node上分配的，而且分配还十分不均衡。MYSQL也是类似的：
Mysql的innodb buffer如果设置的比较大，那么不可避免的需要在多个Node上分配，访问这些BUFFER的性能也会因为本地内存与远程内存的不同而存在差异。说实在的，NUMA的这些问题对于绝大多数的系统来说带来的问题不明显，或者说我们的应用可以承受NUMA带来的缺点，对于有些极端的现象，我们可以通过调整内存分配的策略来调整NUMA的标准行为。最为重要的参数是vm.zone_reclaim_mode。Oracle官方的建议是在大多数环境中，将这个参数设置为6，也就是禁止本地节点分配远程内存。这种做法似乎也不是万能的，一旦真的物理内存出现严重不足，那么SWAP风险也是不小的。不过在一些Mysql社区里，主流的意见是将这个参数设置为0，也就是关闭这个功能，当本地无法分配内存时，首先分配远程内存，而不要做SWAP。实际上，从NUMA的基本原理上来看，这种做法也的作用也是正负各半，并不会有十分明显的效果。
NUMA大大加大了多路服务器的性能优化的复杂性。还好，一般情况下我们还比较穷，8路甚至32路服务器还不是我们的主流配置。因此对于Oracle数据库来说，我们还可以用两台4路组成的RAC来替代一台昂贵的8路服务器。当然RAC的CACHE FUSION带来的开销和NUMA带来的负面作用哪个更大并无定论，这个和应用场景关系极大。不过记住一点，8路甚至8路以上的服务器来跑ORACLE数据库，你的钱不一定花对地方了，一台40万的服务器可能不如两台8万的服务器能做的更好。
