欢迎光临
我们一直在努力

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 –hardwareavailable: 2 nodes (0-1)node 0 size: 32276 MBnode 0 free: 26856 MBnode 1 size: 32320 MBnode 1 free: 26897 MBnode 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/ 

赞(0)
【声明】:本博客不参与任何交易,也非中介,仅记录个人感兴趣的主机测评结果和优惠活动,内容均不作直接、间接、法定、约定的保证。访问本博客请务必遵守有关互联网的相关法律、规定与规则。一旦您访问本博客,即表示您已经知晓并接受了此声明通告。