ToB企服应用市场:ToB评测及商务社交产业平台

标题: 科普文：软件架构数据库系列之【MySQL：innodb对numa的支持】 [打印本页]
作者: 水军大提督    时间: 2024-11-25 00:55
标题: 科普文：软件架构数据库系列之【MySQL：innodb对numa的支持】
概叙

科普文：软件架构Linux系列之【搞懂计算机架构NUMA（Non-Uniform Memory Access）非一致性内存访问】-CSDN博客
科普文：软件架构服务器系列之【3款CPU架构(SMP, NUMA, MPP)和2款共享存储架构(UMA和NUMA)梳理】_uma 主存架构-CSDN博客
科普文：软件架构服务器系列之【MPP大规模并行处理架构及其应用MPPDB梳理】_mpp架构-CSDN博客
关于numa和其他cpu架构，可以看看上面的文章。
 
在数据库体系中，OLTP（在线事务处理）数据库通常面对着高并发和高吞吐量的要求。
在某些情况下，可以通过启用 NUMA（非统一内存访问）来改善 OLTP 数据库的性能。
NUMA 体系的内存分配计谋与传统的对称多处理 (SMP) 体系差异。在 SMP 体系中，全部 CPU 焦点都可以访问同一个共享的内存。而在 NUMA 体系中，内存访问被限制在特定的节点（或节点聚集），这取决于 CPU 焦点的物理位置。
为了在 OLTP 数据库中利用 NUMA 技术来提拔性能，可以思量以下计谋：
数据库基于NUMA优化实际上目的也是尽大概利用本地内存这点思路。
历程大概线程启动后绑定到某个CPU组中，而且尽大概优先利用本CPU组的本地内存，从而进步数据库的团体性能。对于INTEL CPU的服务器来说，长途内存性能问题还不是很严峻，不过如果我们要利用某些信创CPU，那么这个差异大概对性能的影响就很大了。
因此说数据库针对NUMA做焦点优化照旧很须要的。
只不过现在的绝大多数国产数据库在针对NUMA内存的优化上都只是做了些皮毛，对跑BENCHMARK大概比力有效，但是针对实际的应用场景来说，效果甚微。这是因为数据库内存中，最需要提拔性能的是共享内存的访问性能，而这部门内存针对NUMA架构的优化技术难度照旧很高的。
总之，NUMA是为了解决SMP架构下不断增多的CPU Core导致的性能降落的问题，NUMA调解了CPU和内存的结构和访问关系，NUMA通过将处理器分组到差异的节点，并答应每个节点有本身的内存空间，从而进步了体系的扩展性和性能‌。
说了这么多，numa真的可以进步oracle、postgresql、MySQL、redis、mongodb这些数据库的性能吗？
为啥早期oracle和MySQL数据库服务器上要关闭numa？

对于NUMA架构而言，每个CPU访问其对应的RAM时速率是很快的，但是如果需要访问其它node的RAM，那么就需要通过inter-connect通道访问，速率天然会有低落。但是你大概会烦闷就算这个速率再慢那也比直接从磁盘去访问快吧？
事实的确如此，因为NUMA的重要危害并不在此。真正让各人选择弃用NUMA的缘故原由是经常会出现一个CPU NODE很忙，而其它的CPU NODE都十分空闲。因为在NUMA架构中，默认的内存分配方案就是：优先尝试在哀求线程当前所处的CPU的Local内存上分配空间。如果local内存不足，优先淘汰local内存中无用的Page。
其实NUMA本身并没有问题，乃至这是多CPU发展的肯定趋势，而真正导致出问题的是因为操作体系内存访问不均匀。
下面是关于NUMA性能的一张测试图：

可以看到几乎全部情况下Interleave模式下的步伐性能都要比默认的亲和模式要高，有时乃至能高达30%。究其根本缘故原由是Linux服务器的大多数workload分布都是随机的：即每个线程在处理各个外部哀求对应的逻辑时，所需要访问的内存是在物理上随机分布的。而Interleave模式就恰恰是针对这种特性将内存page随机打散到各个CPU Core上，使得每个CPU的负载和Remote Access的出现频率都均匀分布。相较NUMA默认的内存分配模式，死板的把内存都优先分配在线程所在Core上的做法，显然广泛适用性要强很多。
那么对于Oracle、pg这类数据库应用为什么都要关掉呢？就其缘故原由照旧因为数据库这种大规模内存利用的应用场景，而且外部的毗连大多是随机的，这往往会导致出现大量的Remote Access，当我们是用NUMA避免了BUS的性能瓶颈，而Remote Access又成了新的瓶颈，有点拆了东墙补西墙的感觉。
PostgreSQL、MongoDB启动时，都有提示，如果numa没有被禁用掉。
一样平常情况下就是直接关闭掉，在操作体系启动时利用numa off参数。那如果你发现已经启用了numa，例如：

Oracle相关NUMA特性

Oracle从8i开始支持NUMA特性
如果OS和硬件都支持NUMA，NUMA在10.2.0.4 & 11.1.0.7上将默认启用，不过在之前的版本以及 11.2 之后默认是关闭该特性的。
需要硬件支持NUMA，别的主流 OS上都是支持的，如AIX,HP-UX,Solaris,Linux,Windows

NUMA大概导致的故障:
    ORA-4031
    ORA-600 with argument KSKRECONFIGNUMA2
    ORA-600 with argument KSBASEND_INTERNAL
    ORA-600 with argument KSMHEAP_ALLOC1
    ORA-27302: FAILURE OCCURRED AT: SSKGXPCRE3
    
在Oracle NUMA Usage Recommendation (Doc ID 759565.1)中查询BUG列表    
此中，以10204，11107版本遭遇到的BUG最多，因为这两个版本默认启用了NUMA
所以推荐在新装的体系上关闭掉NUMA，但是如果当前已经启用了NUMA而且运行精良，大概有时间做测试，建议照旧启用NUMA

Disable NUMA on database servers to improve performance of Linux file system utilities (Doc ID 1053332.1)
当启用NUMA后，将对内存分组。
当利用一些OS命令(cp,gzip)普通IO操作一个大的文件时,该命令会恒久占用一个CPU
同时，其会消耗这个CPU所关联的内存，用作文件体系缓存
终极导致在体系另有空闲内存的情况下，发生分页，影响数据库性能

11G on HP Creates 6 Shared Memory Segments [ID 601552.1]
共享内存分段，各个平台均大概遭遇到该问题

Sga can't Fit Into A Single Memory Segment and UDP port usage is exploding [ID 747486.1]
HP各平台，导致内存分段以及run out of UDP ports

Bug 8199533 - NUMA enabled by default can cause high CPU / OERI [ID 8199533.8]
导致高CPU消耗，各个平台均大概遭遇到该问题

Multiple DBWR Not Used Though DB_WRITER_PROCESSES is Set [ID 576888.1]
通过_enable_NUMA_optimization = FALSE关闭NUMA后，大概发生DBWR个数无法指定的问题
需要通过设置情况变量和利用_db_block_numa关闭NUMA
1.setenv DISABLE_NUMA TRUE
2._db_block_numa=1

Oracle Background Processes (Including Parallel Processes) Using Only First 8 CPUs (Half) on 16-CPU Server Under NUMA [ID 760705.1]
启用NUMA导致ORACLE无法利用全部CPU 10204

关闭NUMA的步调：
1.安装PATCH 8199533，该补丁可以滚动安装。其针对的版本为10203，10204，11107.
2.10205版本，在硬件OS都支持NUMA的情况上，默认也不会启用NUMA
3.不推荐利用_enable_NUMA_optimization关闭NUMA
4.如果ASM HOME和RDBMS HOME分离，该补丁不需要在ASM HOME上安装
5.在安装PATCH 8199533后启用NUMA：_enable_NUMA_optimization=true
6.启用后，alert日志中会表现 "NUMA PG = 2, CPUs = 48" 此中，PG要大于1才表示ORACLE利用了NUMA特性

11gR2版本如何启用NUMA：
1._enable_NUMA_support=TRUE
2._enable_NUMA_optimization参数已经被废弃
3.如果启用OK，在alert日志中将看到如下信息：
  ...NUMA system found and support enabled (8 domains - 6,6,6,6,6,6,6,6)...
Oracle19c相关NUMA特性

Oracle 19c数据库引入了NUMA (Non-Uniform Memory Access) 相关的特性，这些特性旨在改善在NUMA 体系上的内存访问性能。
以下是一个简单的例子，演示如何在PDB中设置主动NUMA内存管理：
  1. -- 登录到PDB
  2. ALTER SESSION SET CONTAINER=your_pdb;
  4. -- 启用自动NUMA内存管理
  5. ALTER SYSTEM SET memory_max_target=10G SCOPE=SPFILE;
  6. ALTER SYSTEM SET memory_target=10G SCOPE=SPFILE;
  7. ALTER SYSTEM SET sga_target=0 SCOPE=SPFILE;
  8. ALTER SYSTEM SET pga_aggregate_target=0 SCOPE=SPFILE;
  10. -- 重启数据库以使配置生效
复制代码
在实际操作中，你需要根据你的体系设置和工作负载来调解这些参数。始终建议在专业的数据库管理员的引导下举行这些更改，并在生产情况中举行测试。
备注：Oracle集群管理-19C集群禁用numa和大页内存特性
MySQL相关NUMA特性

MySQL 5.7.9开始引入支持numa的参数：innodb_numa_interleave。
 MySQL5.7.9版本+，新增了参数innodb_numa_interleave。根据官方文档的描述：当设置innodb_numa_interleave=1的时候，对于mysqld历程的numa内存分配计谋设置为MPOL_INTERLEAVE，而一旦Innodb buffer pool分配完毕，则计谋重新设置回MPOL_DEFAULT。固然这个参数是否生效，必须创建在mysql是在支持numa特性的linux体系上编译的基础上。
        在MySQL5.7.17版本+， CMake编译软件新增了WITH_NUMA参数，可以在支持numa特性的linux体系上编译mysql。                            
        注：innodb_numa_interleave现在在mysql5.7.17的二进制包是不支持的，详细的bug信息：https://bugs.mysql.com/bug.php?id=80288 。如果需要规避这种情况，建议下载源码包，直接在体系上举行mysql编译。

 

MySQL二进制安装的时候，需要加上“-DWITH_NUMA=ON,”参数，才气支持numa。
    各人都知道，在运行mysql服务的服务器上，linux体系的内存numa特性是强烈建议关闭的。因为这种特性很轻易引起内存泄漏的情况：即发现物理内存另有剩余，但是体系已经开始利用swap内存。
        numa内存特性：比如一台呆板是有2个处理器，有4个内存块。我们将1个处理器和两个内存块合起来，称为一个NUMA node，这样这个呆板就会有两个NUMA node。在物理分布上，NUMA node的处理器和内存块的物理距离更小，因此访问也更快。比如这台呆板会分左右两个处理器（cpu1, cpu2），在每个处理器两边放两个内存块(memory1.1, memory1.2, memory2.1,memory2.2)，这样NUMA node1的cpu1访问memory1.1和memory1.2就比访问memory2.1和memory2.2更快。所以利用NUMA的模式如果能尽量包管本node内的CPU只访问本node内的内存块，那这样的效率就是最高的。
        其实由于mysql数据库服务器一样平常只会部署mysql一种服务在运行，而不会部署若干应用在运行。所以一样平常是希望mysql是独占整个服务器的资源（剔除留给操作体系运行的资源）。所以根据这种业务特性，mysql服务器上是不建议开启numa内存特性。

 PostgreSQL相关NUMA特性

NUMA（Non-Uniform Memory Access）是一种内存访问计谋，通常用于多处理器计算体系。在PostgreSQL中，可以通过设置来启用或禁用NUMA特性，以优化性能。
要启用或禁用PostgreSQL的NUMA特性，可以在postgresql.conf设置文件中设置numa_enabled参数：

请留意，启用或禁用NUMA特性大概会影响体系性能，因此在调解此设置前应充实了解体系的内存架构和PostgreSQL的NUMA设置选项。
此外，另有其他NUMA相关的参数，如numa_memory_contexts，可以用来指定在NUMA架构下PostgreSQL历程应当利用的内存上下文数目。
示例设置：
  1. # 启用NUMA特性
  2. numa_enabled = on
  4. # 指定内存上下文数量
  5. numa_memory_contexts = 16
复制代码
在修改设置后，需要重启PostgreSQL服务以使更改生效。
在服务器的BIOS上，我们可以通过启用 memory interleaving来确保服务器启用NUMA节点之间的内存互访。在LINUX体系启动的时候，我们需要利用numa off参数，确保LINUX启用时关闭NUMA。
如果你没有在BIOS和OS启动时接纳上面的措施，你还可以通过下面的方式启动PG来达到类似的效果。


接纳了上述措施后，你的PG数据库在NUMA下一样平常情况下就能够很好的运行了。如果你的一台数据库服务器上运行了多个PG数据库，那么让每个PG数据库实例利用差异的CPUSET是一个比力好的方法。固然，如果你的数据库都较小，访问并发量不大，那么不做这样的处理也是没有问题的。如果你的多个数据库的负载都很大，而且经常出现SYS CPU很高，大概部门CPU核十分繁忙，数据库的性能也有降落的情况，那么你就应该思量CPUSET了。


如果你的PG数据库遇到了类似上图的情况，那么，那么我们首先要怀疑的就是NUMA引起了这个问题。为什么NUMA架构下，PG数据库会遇到此类问题呢？这种情况往往会出现在LINUX 7之前的OLTP体系中。如果我们的PG数据库并发访问量十分大，而且数据库中存在部门十分热的数据，这种情况就很大概出现。因为分配shared buffer的时候，有大概因为buffer巨细与NUMA节点的分配计谋重合，那么shared buffer大概大多数分配在同一个NUMA节点内存中，这些BUFFER如果特别热，那么PG数据库在访问长途内存的时候，需要通过SPIN lightlock来做串行化处理。因为访问这些十分热的BUFFER会导致部门CPU十分繁忙，同时SPIN轻量级锁的开销十分大。
要解决这些问题也不难，因为在LINUX 7之后，OS对这方面的性能有了相当大的提拔，升级OS大概就会解决这个问题。如果暂时你无法升级OS，那么调解SHARED BUFFER的巨细，将内存分配打散到多个numa节点上也可以缓解这个问题。别的调解PG利用的CPUSET也可以改善这个问题。
总之，在绝大多数情况下，PG和NUMA的矛盾并不突出，而且当NUMA问题出现的时候，照旧有相应的措施的，各人也不必过度担心NUMA的问题。在一样平常情况下，利用PG数据库的时候，接纳在BIOS和OS启动参数上做设置是最为简单的方法。如果你的数据库比力大，负载比力高，那么照旧建议不要忽视这个问题。
NUMA导致的数据库问题

NUMA导致的MySQL服务器SWAP问题分析-CSDN博客
numa 架构下的 mysql，mongodb数据库-阿里云开辟者社区
https://zhuanlan.zhihu.com/p/387117470
 MySQL--NUMA与MySQL - TeyGao - 博客园
NUMA 与 MySQL​ - 墨天轮
技术分享 | 浅谈 NUMA 与 MySQL-腾讯云开辟者社区-腾讯云
极致性能（1）：以NUMA为出发点-腾讯云开辟者社区-腾讯云

免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。



欢迎光临 ToB企服应用市场:ToB评测及商务社交产业平台 (https://dis.qidao123.com/) Powered by Discuz! X3.4