numa架构下mysql可能遭遇的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位实现；

参考资料

http://blog.wl0.org/2012/09/checking-procnuma_maps-can-be-dangerous-for-mysql-client-connections/

http://blog.jcole.us/2010/09/28/mysql-swap-insanity-and-the-numa-architecture/

http://www.realzyy.com/?p=1245#more-1245

http://kevinclosson.wordpress.com/2009/05/14/you-buy-a-numa-system-oracle-says-disable-numa-what-gives-part-ii/

网页标题：numa架构下mysql可能遭遇的swap问题
本文来源：http://cqcxhl.cn/article/isjjos.html

重庆分公司，新征程启航

numa架构下mysql可能遭遇的swap问题

其他资讯