mongodb的NUMA问题

mongodb的NUMA问题

mongodb日志显示如下:文章源自运维生存时间-https://www.ttlsa.com/mongodb/mongodb-numa/

WARNING: You are running on a NUMA machine.文章源自运维生存时间-https://www.ttlsa.com/mongodb/mongodb-numa/

We suggest launching mongod like this to avoid performance problems:文章源自运维生存时间-https://www.ttlsa.com/mongodb/mongodb-numa/

numactl –interleave=all mongod [other options]文章源自运维生存时间-https://www.ttlsa.com/mongodb/mongodb-numa/

解决方案：文章源自运维生存时间-https://www.ttlsa.com/mongodb/mongodb-numa/

1.在原启动命令前面加numactl –interleave=all文章源自运维生存时间-https://www.ttlsa.com/mongodb/mongodb-numa/

如# numactl --interleave=all ${MONGODB_HOME}/bin/mongod --config conf/mongodb.conf文章源自运维生存时间-https://www.ttlsa.com/mongodb/mongodb-numa/

2.修改内核参数文章源自运维生存时间-https://www.ttlsa.com/mongodb/mongodb-numa/

echo 0 > /proc/sys/vm/zone_reclaim_mode文章源自运维生存时间-https://www.ttlsa.com/mongodb/mongodb-numa/

http://www.mongodb.org/display/DOCS/NUMA文章源自运维生存时间-https://www.ttlsa.com/mongodb/mongodb-numa/

下面注释转自网络文章源自运维生存时间-https://www.ttlsa.com/mongodb/mongodb-numa/

一、NUMA和SMP文章源自运维生存时间-https://www.ttlsa.com/mongodb/mongodb-numa/

NUMA和SMP是两种CPU相关的硬件架构。在SMP架构里面，所有的CPU争用一个总线来访问所有内存，优点是资源共享，而缺点是总线争用激烈。随着PC服务器上的CPU数量变多（不仅仅是CPU核数），总线争用的弊端慢慢越来越明显，于是Intel在Nehalem CPU上推出了NUMA架构，而AMD也推出了基于相同架构的Opteron CPU。文章源自运维生存时间-https://www.ttlsa.com/mongodb/mongodb-numa/

NUMA最大的特点是引入了node和distance的概念。对于CPU和内存这两种最宝贵的硬件资源，NUMA用近乎严格的方式划分了所属的资源组（node），而每个资源组内的CPU和内存是几乎相等。资源组的数量取决于物理CPU的个数（现有的PC server大多数有两个物理CPU，每个CPU有4个核）；distance这个概念是用来定义各个node之间调用资源的开销，为资源调度优化算法提供数据支持。文章源自运维生存时间-https://www.ttlsa.com/mongodb/mongodb-numa/

二、NUMA相关的策略文章源自运维生存时间-https://www.ttlsa.com/mongodb/mongodb-numa/

1、每个进程（或线程）都会从父进程继承NUMA策略，并分配有一个优先node。如果NUMA策略允许的话，进程可以调用其他node上的资源。文章源自运维生存时间-https://www.ttlsa.com/mongodb/mongodb-numa/

2、NUMA的CPU分配策略有cpunodebind、physcpubind。cpunodebind规定进程运行在某几个node之上，而physcpubind可以更加精细地规定运行在哪些核上。文章源自运维生存时间-https://www.ttlsa.com/mongodb/mongodb-numa/

3、NUMA的内存分配策略有localalloc、preferred、membind、interleave。localalloc规定进程从当前node上请求分配内存；而preferred比较宽松地指定了一个推荐的node来获取内存，如果被推荐的node上没有足够内存，进程可以尝试别的node。membind可以指定若干个node，进程只能从这些指定的node上请求分配内存。interleave规定进程从指定的若干个node上以RR算法交织地请求分配内存。文章源自运维生存时间-https://www.ttlsa.com/mongodb/mongodb-numa/

三、NUMA和swap的关系文章源自运维生存时间-https://www.ttlsa.com/mongodb/mongodb-numa/

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

四、解决swap问题

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

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

mongodb的NUMA故障一例connection refused because too many open connections: 819 of 819  https://www.ttlsa.com/html/2180.html

如需转载请注明出处：mongodb的NUMA问题 https://www.ttlsa.com/html/1211.html