numa节点_社区投稿 | NUMA架构与数据库的一些思考

前言 在很久之前，笔者被约稿希望能够分享一下关于 SequoiaDB 和操作系统 kernel 参数之间的关系，以及官网介绍的 Linux 优化参数的含义和对数据库的作用。去年整理发布过一篇实践分享，详见《常见问题参数调优实践(一) 》，但是这个方面的内容一直由于别的事情，被耽误了。近期笔者又被催稿了，所以这次会认真记录一下自己的心得，希望能够为广大“色块er”提供一些有益的帮助。 SequoiaDB 对 NUMA 的建议 通常来说，我们在使用SequoiaDB时，关于 NUMA 架构的设置建议，是直接将 NUMA 特性关闭，以避免操作系统因为 NUMA 的特性而造成数据库有较大的性能影响。 关闭 NUMA 特性的设置建议，很多初次接触 SequoiaDB 的用户都没有注意到这个关键的设置。实际上 NUMA 对操作系统的影响是巨大的，今天就让我们来好好针对 NUMA 相关内容进行介绍。 CPU 架构的故事

关于 CPU 的多核架构，常见的有三种主要的架构：SMP、MPP、NUMA，其设计的目的，都是为了能够让服务器或者集群拥有更好的处理性能。

1. SMP SMP(Symmetric multiprocessing)，一般被翻译为“对称多处理”架构，有时候也会被称为“均衡多处理”架构。在现代的服务器中，拥有超过一个处理器，并且所有处理器通过一个系统总线连接资源，每个处理器对资源的使用权限均等。 这种架构最大的优势在于“均等”，在操作系统的支持下，无论进程是处于用户空间，或是核心空间，都可以分配到任何一个处理器上运行。因此，进程可以在不同的处理器间移动，达到负载平衡，使系统的效率提升。 但是其缺点也非常明显，就是由于多处理器都共同使用一个系统总线，而系统总线的带宽是有限的，故服务器的处理器数目受限，且性能受限。

2. MPP

MPP(Massively Parallel Processor)，一般被称为“大规模并行处理机”，也是大家日常所说的“并行计算技术”。它的表现形态就是通过多台服务器组成一个物理分布逻辑统一的超强处理器，一个复杂计算被拆分成多个进程在多个服务器上运行，每个进程均拥有独立的资源，多个进程通过消息传递的方式进行互相通信。 MPP 这个名词被 Hadoop 大数据技术所带火，其实它的设计思路非常的朴素，就是因为SMP 架构下的服务器无法集成更多的CPU 算力，所以人们就通过“堆”机器的形式，将集群中总的 CPU 算力增加到一个单服务器无法抗衡的规模，从而取得更加强大的计算能力。

3. NUMA

NUMA(Non-Uniform Memory Access)架构，中文翻译为“非统一内存访问架构”，是站在前人的肩膀上做出的优化设计。它融合了 SMP 和 MPP 架构的特点，能够让服务器提供更加出色的 CPU 计算能力。

随着摩尔定律的持续发挥作用，服务器 CPU 主频越来越高，并且开始往多核架构的方向狂奔。但是在 SMP 架构下，多处理器共用北桥来读取内存的设计，已经成为限制多处理器性能的瓶颈。

天才的设计师们于是就想到：如果将内存访问器也做拆分，问题不就迎刃而解吗？每个处理器分配独立的内存，就不会再有 SMP 架构下受北桥读取内存的性能影响。

NUMA 的影响与优化

1. NUMA 对系统的影响

在 NUMA 架构下，内存是直接 attach 到各个 CPU 上，CPU 访问自身内存资源的性能是访问别的 CPU 的内存资源的三倍。

在这种特性的表现下，操作系统肯定要出来搞事情。 例如在 Linux 操作系统下，如果系统识别到了 NUMA 架构，默认的内存分配方案就是：优先尝试在请求线程当前所处的 CPU 的 Loc