mongodb的NUMA问题

??问题:

在mongodb登录时日志显示如下:

[[email protected]_180 ~]$ mongo -u root -p xxxxx --authenticationDatabase admin
MongoDB shell version: 2.6.4
connecting to: test
Server has startup warnings:
2015-07-16T04:35:34.694+0800 [initandlisten]
2015-07-16T04:35:34.694+0800 [initandlisten] ** WARNING: You are running on a NUMA machine.
2015-07-16T04:35:34.694+0800 [initandlisten] **          We suggest launching mongod like this to avoid performance problems:
2015-07-16T04:35:34.694+0800 [initandlisten] **              numactl --interleave=all mongod [other options]
2015-07-16T04:35:34.694+0800 [initandlisten]

解决方案:

1.在原启动命令前面加numactl –interleave=all

如# numactl –interleave=all ${MONGODB_HOME}/bin/mongod –config conf/mongodb.conf

2.修改内核参数

echo 0 > /proc/sys/vm/zone_reclaim_mode

http://www.mongodb.org/display/DOCS/NUMA

下面是NUMA简介:

一、NUMA和SMP

NUMA和SMP是两种CPU相关的硬件架构。在SMP架构里面,所有的CPU争用一个总线来访问所有内存,优点是资源共享,而缺点是总线争用激烈。随着PC服务器上的CPU数量变多(不仅仅是CPU核数),总线争用的弊端慢慢越来越明显,于是Intel在Nehalem CPU上推出了NUMA架构,而AMD也推出了基于相同架构的Opteron CPU。

NUMA最大的特点是引入了node和distance的概念。对于CPU和内存这两种最宝贵的硬件资源,NUMA用近乎严格的方式划分了所属的资源组(node),而每个资源组内的CPU和内存是几乎相等。资源组的数量取决于物理CPU的个数(现有的PC server大多数有两个物理CPU,每个CPU有4个核);distance这个概念是用来定义各个node之间调用资源的开销,为资源调度优化算法提供数据支持。

二、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上以RR算法交织地请求分配内存。

三、NUMA和swap的关系

可能大家已经发现了,NUMA的内存分配策略对于进程(或线程)之间来说,并不是公平的。在现有的Redhat Linux中,localalloc是默认的NUMA内存分配策略,这个配置选项导致资源独占程序很容易将某个node的内存用尽。而当某个node的内存耗尽时,Linux又刚好将这个node分配给了某个需要消耗大量内存的进程(或线程),swap就妥妥地产生了。尽管此时还有很多page cache可以释放,甚至还有很多的free内存。

四、解决swap问题

虽然NUMA的原理相对复杂,实际上解决swap却很简单:只要在启动MySQL之前使用numactl –interleave来修改NUMA策略即可。

值得注意的是,numactl这个命令不仅仅可以调整NUMA策略,也可以用来查看当前各个node的资源是用情况,是一个很值得研究的命令。

时间: 2024-12-10 02:00:26

mongodb的NUMA问题的相关文章

(转) 线上环境部署MongoDB的官方建议

本文主要内容来自MongoDB官方文档http://docs.mongodb.org/manual/administration/production-notes/.并结合了实际工作情况进行分享. 1)软件包的选择 确保使用最新的稳定版本.目前我们线上使用的版本是2.4.6.MongoDB软件包下载页面http://www.mongodb.org/downloads. 确保线上环境总是使用64位版本.32位版本只能用于测试和开发使用,因为32位版本最大只能存储2GB的数据.启动MongoDB的时

(转)部署MongoDB时需要注意的调参

部署MongoDB的生产服务器,给出如下相关建议: 使用虚拟化环境: 系统配置 1)推荐RAID配置 RAID(Redundant Array of Independent Disk,独立磁盘冗余阵列)是一种可以让我们把多块磁盘当做单独一块磁盘来使用的技术.可使用它来提高磁盘的可靠性或者性能,或二者兼有.一组使用RAID技术的磁盘被称作RAID磁盘阵列. RAID根据性能的不同,存在着多种配置方式,通常兼顾了速度与容错性.下列是几种最常见的配置方式: RAID0 使用磁盘分割技术(disk st

mongodb由浅入深(50+文章)

博客2011年就上线了,可是没有打理,从2013年开始六七月份开始用心打理,开始和漠北业余时间写点文章,nginx.zabbix.mms都已经整理了部分,漠北日理万机没有时间汇总mongodb,罢了,让我这个做小弟的来汇总一次吧,对运维技术有兴趣的加群:qq群①39514058,qq群②6690706 mongodb入门(必备) 1. ttlsa教程系列之mongodb-(一)mongodb介绍 2. ttlsa教程系列之mongodb--(二)mongodb安装 3. ttlsa教程系列之mo

部署mongodb中需要注意的调参

部署mongodb的生产服务器,给出如下相关建议: 使用虚拟化环境: 系统配置 1)推荐RAID配置 RAID(Redundant Array of Independent Disk,独立磁盘冗余阵列)是一种可以让我们把多块磁盘当做单独一块磁盘来使用的技术.可使用它来提高磁盘的可靠性或者性能,或二者兼有.一组使用RAID技术的磁盘被称作RAID磁盘阵列. RAID根据性能的不同,存在着多种配置方式,通常兼顾了速度与容错性.下列是几种最常见的配置方式: RAID0 使用磁盘分割技术(disk st

NUMA的取舍与优化设置

在os层numa关闭时,打开bios层的numa会影响性能,QPS会下降15-30%; 在bios层面numa关闭时,无论os层面的numa是否打开,都不会影响性能. 安装numactl:        #yum install numactl -y      #numastat      等同于 cat /sys/devices/system/node/node0/numastat ,在/sys/devices/system/node/文件夹中记录系统中的所有内存节点的相关详细信息.     

MongoDB numa系列问题二:WARNING: You are running on a NUMA machine.

1:Mongod日志warning: 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] 2:解决方案: 在原启动命令前面加numactl –interleave=all #numactl --inte

MongoDB numa系列问题一:[initandlisten] connection refused because too many open connections:

1:Mongod日志有很多这样的报错: [initandlisten] connection refused because too many open connections: 2:查看系统的限制 core file size (blocks, -c) 0 data seg size (kbytes, -d) unlimited scheduling priority (-e) 0 file size (blocks, -f) unlimited pending signals (-i) 25

MongoDB numa系列问题三:overcommit_memory和zone_reclaim_mode

内核参数overcommit_memory : 它是 内存分配策略 可选值:0.1.2.0:表示内核将检查是否有足够的可用内存供应用进程使用:如果有足够的可用内存,内存申请允许:否则,内存申请失败,并把错误返回给应用进程.1:表示内核允许分配所有的物理内存,而不管当前的内存状态如何.2:表示内核允许分配超过所有物理内存和交换空间总和的内存 内核参数zone_reclaim_mode: 可选值0.1a.当某个节点可用内存不足时:1.如果为0的话,那么系统会倾向于从其他节点分配内存2.如果为1的话,

MongoDB性能优化

MongoDB是一个高性能可扩展基于文档的NoSQL数据库,高性能也需要在多个关键维度的配置,包括硬件.应用模式.模式设计.索引.磁盘I/O等. 存储引擎 WiredTiger是3.0以后的默认存储引擎,细粒度的并发控制和数据压缩提供了更高的性能和存储效率.3.0以前默认的MMAPv1也提高了性能.在MongoDB复制集中可以组合多钟存储引擎,各个实例实现不同的应用需求. 硬件 MongoDB初衷是采用水平扩展构建集群,而不是价格更高的硬件升级.采用复制保证高可用,自动分片使数据均匀分布在各节点