numa 架构下的 mysql,mongodb数据库

本文涉及的产品
云数据库 RDS MySQL,集群系列 2核4GB
推荐场景:
搭建个人博客
云数据库 MongoDB,独享型 2核8GB
推荐场景:
构建全方位客户视图
RDS MySQL Serverless 基础系列,0.5-2RCU 50GB
简介: 从MySQL迁移到MongoDB,在导入旧数据的过程中,遇到了些许波折,犯了不少错误,但同时也学到了不少知识,遂记录下来。

从MySQL迁移到MongoDB,在导入旧数据的过程中,遇到了些许波折,犯了不少错误,但同时也学到了不少知识,遂记录下来。

公司为这个项目专门配备了几台高性能务器,清一色的双路四核超线程CPU,外加32G内存,运维人员安装好MongoDB后,就轮到我了,我习惯于在使用新服务器前先看看相关日志,了解一下基本情况,当我浏览MongoDB日志时,发现一些警告信息:

WARNING: You are running on a NUMA machine.
We suggest launching mongod like this to avoid performance problems:
numactl --interleave=all mongod [other options]

当时我并不太清楚NUMA是什么东西,所以没有处理,只是把问题报告给了运维人员,事实证明运维人员也没有处理,所以问题的序幕就这样拉开了…

迁移工作首先要导入旧数据。开始一切倒还正常,不过几小时之后,我无意中发现不知道什么时候开始数据导入的速度下降了,同时我的PHP脚本开始不停的抛出异常:

cursor timed out (timeout: 30000, time left: 0:0, status: 0)

我一时判断不出问题所在,想想先在PHP脚本里加大Timeout的值应付一下:

MongoCursor::$timeout = -1;

可惜这样并没有解决问题,错误反倒变着花样的出现了:

max number of retries exhausted, couldn't send query
couldn't send query: Broken pipe

无奈之下用strace跟踪了一下PHP脚本:

shell> strace -p <PID>

发现进程卡在了recvfrom操作上:

recvfrom(<FD>,

通过如下命令查询recvfrom操作的含义是:receive a message from a socket

shell> apropos recvfrom

还可以按照下面的方式确认一下:

shell> lsof -p <PID>
shell> ls -l /proc/<PID>/fd/<FD>

此时查询MongoDB当前操作,发现几乎每个操作会消耗大量的时间:

shell> echo "db.currentOp()" | /path/to/mongo

同时运行mongostat显示很高的locked值。

重复做了很多工作,但始终无法找到问题的症结在哪里,只好求助官方论坛,那里的技术支持都很热心,在我描述了问题后,没过多久就有了回复,建议我检查一下是不是索引不佳所致,为了验证这种可能,我激活了Profiler记录慢操作:

mongo> use <DB>
mongo> db.setProfilingLevel(1);

不过结果显示基本都是insert操作(因为我是导入数据为主),本身就不需要索引:

mongo> use <DB>
mongo> db.system.profile.find().sort({$natural:-1})

问题到了这里,似乎已经走投无路了,为了死马当活马医,我又重复了几次迁移旧数据的过程,结果自然是次次都出问题,但幸运的是我发现每当出问题的时候,在top命令的结果中,总有一个名叫irqbalance的进程居高不下,搜索了一下,结果很多介绍irqbalance的文章中都提及了NUMA,让我一下子记起之前在日志中看到的警告信息,于是乎按照信息里介绍的,重新启动了一下MongoDB:

shell> numactl --interleave=all /path/to/mongod

一切都正常了。为了解决这个问题,浪费了很多精神,实在没有力气再解释NUMA到底是什么东西了,有想了解的网友可以参考老外的文章,里面的介绍很翔实。

原文链接:huoding.com

对于罪魁祸首,作者留给大家去学习,NoSQLFan在这里可以给大家做一个简单的描述,先解释几个概念

NUMA:NUMA是多核心CPU架构中的一种,其全称为Non-Uniform Memory Access,简单来说就是在多核心CPU中,机器的物理内存是分配给各个核的,架构简图如下所示:

每个核访问分配给自己的内存会比访问分配给其它核的内存要快,有下面几种访问控制策略:

  • 1.缺省(default):总是在本地节点分配(分配在当前进程运行的节点上);
  • 2.绑定(bind):强制分配到指定节点上;
  • 3.交叉(interleave):在所有节点或者指定的节点上交织分配;
  • 4.优先(preferred):在指定节点上分配,失败则在其他节点上分配。

上面文章中最后使用numactl –interleave命令就是指定其为交叉共享模式。

irqbalance:这是作者在上面提到的一个占用CPU的进程,这个进程的作用是在多核心CPU的操作系统中,分配系统中断信号的。参见:irqbalance.org

概念说完了,下面是上面问题的简单描述:

我们知道虚拟内存机制是通过一个中断信号来通知虚拟内存系统进行内存swap的,所以这个irqbalance进程忙,是一个危险信号,在这里是由于在进行频繁的内存交换。这种频繁交换现象称为swap insanity,在MySQL中经常提到,也就是在NUMA框架中,采用不合适的策略,导致核心只能从指定内存块节点上分配内存,即使总内存还有富余,也会由于当前节点内存不足时产生大量的swap操作。

相对于SMP(又称uniform. memory architecture),NUMA引入了node的概念,每个物理CPU都被视作一个node,而每个node都有一个local memory(访问速度更快),其他node的内存则为remote;

NUMA相关的策略
1、每个进程(或线程)都会从父进程继承NUMA策略,并分配有一个优先node。如果NUMA策略允许的话,进程可以调用其他node上的资源。
2、NUMA的CPU分配策略有cpunodebind、physcpubind。cpunodebind规定进程运行在某几个node之上,而physcpubind可以更加精细地规定运行在哪些核上。
3、NUMA的内存分配策略有localalloc、preferred、membind、interleave。localalloc规定进程从当前node上请求分配内存;而preferred比较宽松地指定了一个推荐的node来获取内存,如果被推荐的node上没有足够内存,进程可以尝试别的node。membind可以指定若干个node,进程只能从这些指定的node上请求分配内存。interleave规定进程从指定的若干个node上以Round-roll算法交织地请求分配内存。

在现有的Redhat Linux中,localalloc是默认的NUMA内存分配策略,这个配置选项导致资源独占程序很容易将某个node的内存用尽。而当某个node的内存耗尽时,Linux又刚好将这个node分配给了某个需要消耗大量内存的进程(或线程),此时即便其他node有空闲内存也无济于事,于是就产生了swap


可通过numactl查看相关信息
numactl --hardware查看
# numactl --hardware
available: 2 nodes (0-1)
node 0 size: 32276 MB
node 0 free: 26856 MB
node 1 size: 32320 MB
node 1 free: 26897 MB
node distances:
node   0   1 
  0:  10  21 
  1:  21  10 

通过/proc/pid/numa-maps可以查看分配给mysqld的numa信息--读取numa-maps会阻塞相应进程,因此不宜频繁调用 
2aaaaad3e000 default anon=13240527 dirty=13223315 
  swapcache=3440324 active=13202235 N0=7865429 N1=5375098

可通过perl脚本格式化输出
N0        :      7983584 ( 30.45 GB)
N1        :      5440464 ( 20.75 GB)
active    :     13406601 ( 51.14 GB)
anon      :     13422697 ( 51.20 GB)
dirty     :     13407242 ( 51.14 GB)
mapmax    :          977 (  0.00 GB)
mapped    :         1377 (  0.01 GB)
swapcache :      3619780 ( 13.81 GB)

Node 0/1各分配32G,但是 node 0已经使用了30多G,所剩无几;
如果继续在node 0请求内存,则需swap,即便此时node 1还有10G空余;
解决方法:
使用interleave,轮询各个node分配内存
修改mysqld_safe,在cmd="$NOHUP_NICENESS"后添加如下信息
cmd="/usr/bin/numactl --interleave all $cmd"
此时NUMA内存分配情况
N0        :      6814756 ( 26.00 GB)
N1        :      6816444 ( 26.00 GB)
anon      :     13629853 ( 51.99 GB)
dirty     :     13629853 ( 51.99 GB)
mapmax    :          296 (  0.00 GB)
mapped    :         1384 (  0.01 GB)

twitter生产库144G内存,innodb buffer pool占用120G;
除了采用numactl --interleave=all
在启动mysqld前调用sysctl -q -w vm.drop_caches=3清空缓存
并且启动mysqld立即分配innodb buffer pool

注:也可在BIOS层面将NUMA改为SUMA,在底层将所有分配策略都设为interleave,但粒度太大不利于分化;
默认innodb buffer pool采用lazy-allocation,可采用--innodb-buffer-pool-populate立即分配,通过使用mmap的MAP_POPULATE位实现;

相关实践学习
MongoDB数据库入门
MongoDB数据库入门实验。
快速掌握 MongoDB 数据库
本课程主要讲解MongoDB数据库的基本知识,包括MongoDB数据库的安装、配置、服务的启动、数据的CRUD操作函数使用、MongoDB索引的使用(唯一索引、地理索引、过期索引、全文索引等)、MapReduce操作实现、用户管理、Java对MongoDB的操作支持(基于2.x驱动与3.x驱动的完全讲解)。 通过学习此课程,读者将具备MongoDB数据库的开发能力,并且能够使用MongoDB进行项目开发。 &nbsp; 相关的阿里云产品:云数据库 MongoDB版 云数据库MongoDB版支持ReplicaSet和Sharding两种部署架构,具备安全审计,时间点备份等多项企业能力。在互联网、物联网、游戏、金融等领域被广泛采用。 云数据库MongoDB版(ApsaraDB for MongoDB)完全兼容MongoDB协议,基于飞天分布式系统和高可靠存储引擎,提供多节点高可用架构、弹性扩容、容灾、备份回滚、性能优化等解决方案。 产品详情: https://www.aliyun.com/product/mongodb
目录
相关文章
|
14天前
|
存储 SQL 关系型数据库
MySQL进阶突击系列(03) MySQL架构原理solo九魂17环连问 | 给大厂面试官的一封信
本文介绍了MySQL架构原理、存储引擎和索引的相关知识点,涵盖查询和更新SQL的执行过程、MySQL各组件的作用、存储引擎的类型及特性、索引的建立和使用原则,以及二叉树、平衡二叉树和B树的区别。通过这些内容,帮助读者深入了解MySQL的工作机制,提高数据库管理和优化能力。
|
1月前
|
存储 SQL 关系型数据库
Mysql高可用架构方案
本文阐述了Mysql高可用架构方案,介绍了 主从模式,MHA模式,MMM模式,MGR模式 方案的实现方式,没有哪个方案是完美的,开发人员在选择何种方案应用到项目中也没有标准答案,合适的才是最好的。
167 3
Mysql高可用架构方案
|
7天前
|
存储 Oracle 关系型数据库
数据库传奇:MySQL创世之父的两千金My、Maria
《数据库传奇:MySQL创世之父的两千金My、Maria》介绍了MySQL的发展历程及其分支MariaDB。MySQL由Michael Widenius等人于1994年创建,现归Oracle所有,广泛应用于阿里巴巴、腾讯等企业。2009年,Widenius因担心Oracle收购影响MySQL的开源性,创建了MariaDB,提供额外功能和改进。维基百科、Google等已逐步替换为MariaDB,以确保更好的性能和社区支持。掌握MariaDB作为备用方案,对未来发展至关重要。
27 3
|
7天前
|
安全 关系型数据库 MySQL
MySQL崩溃保险箱:探秘Redo/Undo日志确保数据库安全无忧!
《MySQL崩溃保险箱:探秘Redo/Undo日志确保数据库安全无忧!》介绍了MySQL中的三种关键日志:二进制日志(Binary Log)、重做日志(Redo Log)和撤销日志(Undo Log)。这些日志确保了数据库的ACID特性,即原子性、一致性、隔离性和持久性。Redo Log记录数据页的物理修改,保证事务持久性;Undo Log记录事务的逆操作,支持回滚和多版本并发控制(MVCC)。文章还详细对比了InnoDB和MyISAM存储引擎在事务支持、锁定机制、并发性等方面的差异,强调了InnoDB在高并发和事务处理中的优势。通过这些机制,MySQL能够在事务执行、崩溃和恢复过程中保持
31 3
|
7天前
|
SQL 关系型数据库 MySQL
数据库灾难应对:MySQL误删除数据的救赎之道,技巧get起来!之binlog
《数据库灾难应对:MySQL误删除数据的救赎之道,技巧get起来!之binlog》介绍了如何利用MySQL的二进制日志(Binlog)恢复误删除的数据。主要内容包括: 1. **启用二进制日志**:在`my.cnf`中配置`log-bin`并重启MySQL服务。 2. **查看二进制日志文件**:使用`SHOW VARIABLES LIKE &#39;log_%&#39;;`和`SHOW MASTER STATUS;`命令获取当前日志文件及位置。 3. **创建数据备份**:确保在恢复前已有备份,以防意外。 4. **导出二进制日志为SQL语句**:使用`mysqlbinlog`
36 2
|
21天前
|
关系型数据库 MySQL 数据库
Python处理数据库:MySQL与SQLite详解 | python小知识
本文详细介绍了如何使用Python操作MySQL和SQLite数据库,包括安装必要的库、连接数据库、执行增删改查等基本操作,适合初学者快速上手。
148 15
|
14天前
|
SQL 关系型数据库 MySQL
数据库数据恢复—Mysql数据库表记录丢失的数据恢复方案
Mysql数据库故障: Mysql数据库表记录丢失。 Mysql数据库故障表现: 1、Mysql数据库表中无任何数据或只有部分数据。 2、客户端无法查询到完整的信息。
|
21天前
|
关系型数据库 MySQL 数据库
数据库数据恢复—MYSQL数据库文件损坏的数据恢复案例
mysql数据库文件ibdata1、MYI、MYD损坏。 故障表现:1、数据库无法进行查询等操作;2、使用mysqlcheck和myisamchk无法修复数据库。
|
25天前
|
SQL 关系型数据库 MySQL
MySQL导入.sql文件后数据库乱码问题
本文分析了导入.sql文件后数据库备注出现乱码的原因,包括字符集不匹配、备注内容编码问题及MySQL版本或配置问题,并提供了详细的解决步骤,如检查和统一字符集设置、修改客户端连接方式、检查MySQL配置等,确保导入过程顺利。
|
1月前
|
SQL 存储 缓存
【赵渝强老师】MySQL的体系架构
本文介绍了MySQL的体系架构,包括Server层的7个主要组件(Connectors、Connection Pool、Management Service & Utilities、SQL Interface、Parser、Optimizer、Query Caches & Buffers)及其作用,以及存储引擎层的支持情况,重点介绍了InnoDB存储引擎。文中还提供了相关图片和视频讲解。
【赵渝强老师】MySQL的体系架构