MySQL中InnoDB存储引擎在NUMA系统上的优化
开篇：润墨网以专业的文秘视角，为您筛选了一篇MySQL中InnoDB存储引擎在NUMA系统上的优化范文，如需获取更多写作素材，在线客服老师一对一协助。欢迎您的阅读与分享！
摘要 本文对InnoDB引擎进行了代码级的深入研究，详细剖析了NUMA系统中软件优化的要点并将InnoDB针对NUMA特性进行了优化，有效减小系统中的内存访问开销。在Intel的最新Xeon7500系列处理器上进行了性能评测，结果显示该方案取得了一定的成果。
中图分类号TP311 文献标识码A 文章编号 1674-6708（2011）34-0155-02
0 引言
InnoDB 是 MySQL 上一个性能非常优秀的存储引擎，其设计目标是高效处理大容量数据。除了提供外键、事务处理特性外，InnoDB还借鉴了很多Oracle上的特性，如支持行锁，不加锁读取等。InnoDB也有很多自己的特点诸如Insert buffering、Double write等。凭借这些优点，InnoDB引擎已经具备了一个大型数据库所需的基本性能，内嵌InnoDB引擎的MySQL应用越来越广。Intel在最近的处理器中使用了NUMA技术[1]，这对现有的应用程序是一个新的机遇和挑战。然而著名数据库厂商Oracle推荐关闭处理器的NUMA特性，以保证系统性能不会出现下降。这就出现了数据库引擎是否能够充分利用NUMA系统特性的问题。
本文对InnoDB引擎进行了代码级的深入研究，详细剖析了NUMA系统中软件优化的要点并将InnoDB针对NUMA特性进行了优化，有效减小系统中的内存访问开销。在Intel的最新Xeon7500系列处理器上进行了性能评测，结果显示该方案取得了一定的成果。
1 NUMA技术
随着目前应用程序对计算机性能要求不断提高，传统的SMP处理器系统应用越来越广，规模越来越大，但由于传统的SMP系统中，公用系统总线的同一时间只能被一个处理器占用。当处理器越来越多时，其系统总线的竞争冲突加大，必然成为性能瓶颈。所以目前商用服务器中SMP系统的处理器数目一般只有10个左右，其扩展能力大大收到限制。NUMA技术较好解决了SMP系统的可扩展性问题，已成为当今高性能服务器的主流体系结构之一。目前，国外著名的服务器厂商都先后推出了基于NUMA架构的高性能服务器，如早期HP的Superdome、SGI的Altix 3000、IBM的 x440、NEC的TX7、AMD的Opteron等，Intel最新一代的基于Nehalem架构的CPU（如Xeon7500系列）也采用了NUMA技术[2]。
利用NUMA技术，可以把多个CPU组合在一台服务器内。其系统拓扑结构示意图如图1所示：
NUMA服务器的基本特征是具有多个CPU节点，其中每个CPU节点由多个CPU（如图1中的node0中有4个）组成。类似于一个SMP系统，每个节点具有独立的本地内存、I/O控制器等。由于其节点之间可以通过互联模块进行连接和信息交互，因此每个CPU都可以访问整个系统的内存。访问本节点内存的速度（本地访问）将远远高于访问邻节点内存（远端访问）的速度，如Node1中的CPU访问Node3上的CPU需要经过互联模块（如图1中所示的QPI（Quick path Interconnect）一次，不同的NUMA实现在这方面的代价不同。由于这个特性，为更好地发挥系统性能，在NUMA系统中开发应用程序时需要特别注意内存分配、访问过程，尽量减少不同节点之间的信息交互。NUMA技术的这个缺陷导致当CPU数量增加时，系统性能无法线性增加。如HP公司Superdome服务器时，曾公布了它与HP其它UNIX服务器的相对性能值，结果发现，64路CPU的Superdome（NUMA结构）的相对性能值是20，而8路N4000（共享的SMP结构）的相对性能值是6.3。从这个结果可以看到，随着CPU数量的增加其性能提升有限。
各个厂商不同的NUMA实现带来不同的系统架构，大致可分成以下3类：
1）NUMA原型
第一个商用的CC-NUMA系统是NUMAQ-2000。随后的几年，DG、DEG、SGI、UNISYS等各自了相差悬殊的基于自身硬件的NUMA（如内联技术，NUMA的级别等方面）。但这些实现有一个共同的特点，即其远端访问与本地访问的速度差距非常大，大约为50:1的程度，这些系统在当时的优势在于它们提供了很大的带宽。
2）早期NUMA
相比于早期的NUMA原型，现代的NUMA系统在远端和本地访问内存的速度差别上有所改进，大约能达到2:1的程度。
3）现代NUMA
目前正在使用的NUMA技术主要是Intel的Quick path Interconnect（QPI）与AMD的HyperTransport（HT），其特点主要如下：
（1）更好的内存访问速度，Intel公布的数据表明其Nehalem架构的CPU中远端访问与本地访问的速度比例约为1.4：1；
（2）目前的NUMA系统的BIOS可以控制是否开启NUMA，当系统NUMA被关闭时，其内存体系架构类似于SMP，通常被称为SUMA或者SUMO[2]。
2INNODB缓存系统
MySQL是最受欢迎的开源SQL数据库管理系统，在中小型网站中使用广泛。MySQL的存储引擎有MyISAM，INNODB，BDB，NDB，Memory等[3]，而InnoDB是处理大容量数据时的首选[4]。
我们主要关注InnoDB引擎中与内存相关的缓存控制部分[5-7]：其中缓冲池（buf_pool）是整个引擎缓存部分的核心数据结构，数据库中所有对文件的操作本质上都是当对内存块的操作。我们可以在配置文件中（innodb_buffer_pool_size）指定该缓冲池的大小。在buf_pool中，包含了内存控制块结构（block），每个block分别包含page和frame，其中page就是用来缓存硬盘上数据文件的结构。整个缓存系统的结构如图2所示：
缓存系统的主要调用流程[5]如下：
1）启用InnoDB存储引擎后，MySQL启动时将创建缓存池，其中包含一定数量的block结构，用以缓存文件系统上的数据，同时初始化空闲块链表buf_pool->free，最近使用的内存块buf_pool->LRU等控制相关的数据结构；
2）当用户连接请求一个内存块时，从buf_pool->free链表中获取一个内存块，如空闲块不足则从最近使用的内存块链表buf_pool->LRU中取最远使用的一块；
3）系统内部的监控线程将根据目前系统的负载定时地从buf_pool->flush_list中取数据写回到磁盘上，并将释放的内存块重新加入buf_pool->free链表中。
Innodb在设计之初并未考虑到其在SMP和NUMA系统上的扩展性，系统中存在很多共享变量，导致系统中锁竞争非常多；且其只有一个内存池，故在NUMA系统上的运行时，跨节点的远端内存访问很多，影响到其性能。
3 MySQL中InnoDB存储引擎在NUMA系统上的优化
要想充分利用NUMA处理器的特性，首先硬件层要支持；其次操作系统也需要支持，如进行进程调度须对NUMA特性加以考虑，尽量将相关进程放在同一节点上，不在节点间迁移进程；最后应用软件层也必须利用NUMA的特性，尽量减少远端内存访问，多线程程序则需考虑进程间相关性。
本文为全文原貌 未安装PDF浏览器用户请先下载安装 原版全文
从降低远端内存访问、提高同一节点上进程相关性的角度出发，设计优化方案如下：
1）将内存池按节点平均划分，进程优先访问本节点上的内存，若没有找到数据再到远端节点上查找，尽量减少远端访问；
2）在数据库创建连接时，将各个连接线程绑定到不同的节点上，使其以后对内存的操作优先从本节点上发生。
我们利用MySQL和InnoDB的现有数据结构实施了该方案，为更好地进行性能分析，我们设计了如下实验。
实验所用的机器是一台Dell服务器，其处理器为两枚Intel Xeon x7540，共有两个节点，每节点上有八个核，每个节点内存大小为12G，共24G，其处理器拓扑关系如图3所示：
操作系统是RHEL5.4，内核版本为2.6.18，调度程序为默认的O（1）。
在系统空闲的情况下，我们利用DBT2（OLTP）[8]的测试程序来进行评测。实验中使用的数据大小为10 warehouse，同时用16个连接进行评测，其中Innodb的缓存池大小为16G。这样的配置的目的是使得数据可以被全部装载进内存，磁盘的IO很小，不会影响测试结果。
在Linux的启动参数中加入numa=off可以关闭NUMA特性。我们分别在NUMA打开和NUMA关闭的情况下，利用原生的MySQL运行该测试，测试结果如图4所示：
由图4测试结果可见，原生的程序未能充分利用NUMA的特性，在NUMA关闭时，其性能大约有7%的上升。更换MySQL为改进的版本后运行同样配置的测试，由于远端访问大幅减少，可以发现性能有较大的提升。
参考文献
[1]Intel® Micro architecture Codename Nehalem.?Open.
[3]Sasba Pachev，Understanding MySQL Internals， O’REALLY Media Inc，2007.
[4]Baron Schwartz etc，High Performance MySQL， O’REALLY Media Inc，2008.
[5]InnoDB Plugin 1.0 for MySQL 5.1 User’s Guide.dev.省略/doc/innodb-plugin/1.0/en/.
[6]Heikki Tuuri CEO Innobase，Calvin Sun Principal Engineer，Oracle Corporation，InnoDB Internals: InnoDB File Formats and Source Code Structure，MySQL Conference，April 2009.
[7]Ken Jacobs，VP Product Strategy，Oracle Corporation，Innovative Technologies for Performance and Data Protection，MySQL Conference，April 2009.
[8]Database Test Suit.osdldbt.省略/.
本文为全文原貌 未安装PDF浏览器用户请先下载安装 原版全文