转自:http://huoding.com/2012/11/08/198
说个案例:一台Apache服务器,由于其MaxClients参数设置过大,并且恰好又碰到访问量激增,结果内存被耗光,从而引发SWAP,进而负载攀升,最终导致宕机。
正所谓:SWAP,性能之大事,死生之地,存亡之道,不可不察也。
最容易想到的就是free命令了,它指明了当前SWAP的使用情况:
shell> free -m total used free Swap: 34175 11374 22801
另一个常用的是sar命令,它能列出系统在各个时间的SWAP使用情况:
shell> sar -r kbswpfree kbswpused %swpused kbswpcad 23345644 11650572 33.29 4656908 23346452 11649764 33.29 4656216 23346556 11649660 33.29 4650308 23346932 11649284 33.29 4649888 23346992 11649224 33.29 4648848
不过free命令和sar命令显示的都不是实时数据,如果需要,可以使用vmstat命令:
shell> vmstat 1 -----------memory------------- ---swap-- swpd free buff cache si so 11647532 123664 305064 7193168 0 0 11647532 123672 305064 7193172 0 0 11647532 125728 305064 7193468 0 0 11647532 125376 305064 7193476 0 0 11647532 124508 305068 7193624 0 0
每秒刷新一次结果,在SWAP一栏里列出了相关数据,至于si和so的解释,大致如下:
si: Amount of memory swapped in from disk (/s).
so: Amount of memory swapped to disk (/s).
如果它们一直是零当然最好不过了,偶尔不为零也没啥,糟糕的是一直不为零。
前面介绍的方法,看到的都是SWAP的整体情况,可是如果我想查看到底是哪些进程使用了SWAP,应该如何操作呢?这个问题有点棘手,我们来研究一下:
好消息是top命令能提供这个信息,不过缺省并没有显示,我们需要激活一下:
打开top;
按「f」进入选择字段的界面;
按「p」选择「SWAP」字段;
按回车确认。
坏消息是top命令提供的SWAP信息只是一个理论值,或者更直白一点儿来说它根本就是不可信的(在top里SWAP的计算公式是:SWAP=VIRT-RES)。
BTW:相比之下,top里的「nFLT」字段更有价值,它表示PageFault的次数。
那到底我们能不能获取到进程的SWAP情况呢?别着急,看代码:
#!/bin/bash cd /proc for pid in [0-9]*; do command=$(cat /proc/$pid/cmdline) swap=$( awk ' BEGIN { total = 0 } /Swap/ { total += $2 } END { print total } ' /proc/$pid/smaps ) if (( $swap > 0 )); then if [[ "${head}" != "yes" ]]; then echo -e "PID\tSWAP\tCOMMAND" head="yes" fi echo -e "${pid}\t${swap}\t${command}" fi done
说明:请使用root权限来运行此脚本。
内存不足无疑会SWAP,但有些时候,即便看上去内存很充裕,还可能会SWAP,这种现象被称为SWAP Insanity,罪魁祸首主要有以下几点:
Swappiness的迷失
实际上,当可用内存不足时,系统有两个选择:一个是通过SWAP来释放内存,另一个是删除Cache中的Page来释放内存。一个很常见的例子是: 当拷贝大文件的时候,时常会发生SWAP现象。这是因为拷贝文件的时候,系统会把文件内容在Cache中按Page来缓存,此时一旦可用内存不足,系统便 会倾向于通过SWAP来释放内存。
内核中的swappiness参数可以用来控制这种行为,缺省情况下,swappiness的值是60:
shell> sysctl -a | grep swappiness vm.swappiness = 60
它的含义是:如果系统需要内存,有百分之六十的概率执行SWAP。知道了这一点,我们很自然的会想到用下面的方法来降低执行SWAP的概率:
shell> echo "vm.swappiness = 0" >> /etc/sysctl.conf shell> sysctl -p
这样做的确可以降低执行SWAP的概率,但并不意味着永远不会执行SWAP。
NUMA的诅咒
NUMA在MySQL社区有很多讨论,这里不多说了,直击NUMA和SWAP的恩怨纠葛。
大概了解一下NUMA最核心的numactl命令:
shell> numactl --hardware available: 2 nodes (0-1) node 0 size: 16131 MB node 0 free: 100 MB node 1 size: 16160 MB node 1 free: 10 MB node distances: node 0 1 0: 10 20 1: 20 10
以下我们其中一台db服务器的情况
free -m
total used free shared buffers cached
Mem: 48288 33151 15137 0 300 16956
-/+ buffers/cache: 15894 32394
Swap: 16193 13347 2845
执行:numactl --hardware
available: 2 nodes (0-1)
node 0 size: 24240 MB
node 0 free: 221 MB
node 1 size: 24210 MB
node 1 free: 14928 MB
node distances:
node 0 1
0: 10 20
1: 20 10
node1占用了那么多内存不释放
可以看到系统有两个节点(其实就是两个物理CPU),它们各自分了16G内存,其中零号节点还剩100M内存,一号节点还剩10M内存。设想启动了 一个需要11M内存的进程,系统把它分给了一号节点来执行,此时虽然系统总体的可用内存大于该进程需要的内存,但因为一号节点本身剩余的可用内存不足,所 以仍然可能会触发SWAP行为。
需要说明的一点事,numactl命令中看到的各节点剩余内存中时不包括Cache内存的,如果需要知道,我们可以利用drop_caches参数先释放它:
shell> sysctl vm.drop_caches=1
注:这步操作可能会引起系统负载的震荡。
另:如何确定一个进程的节点及内存分配情况?网络上有现成的脚本。
如果要规避NUMA对SWAP的影响,最简单的方法就是在启动进程的时候禁用它:
shell> numactl --interleave=all ...
此外,内核参数zone_reclaim_mode通常也很重要,当某个节点可用内存不足时,如果为0的话,那么系统会倾向于从远程节点分配内存;如果为1的话,那么系统会倾向于从本地节点回收Cache内存。多数时候,Cache对性能很重要,所以0是一个更好的选择。
shell> echo "vm.zone_reclaim_mode = 0" >> /etc/sysctl.conf shell> sysctl -p
另:网络上有一些关于MySQL和SWAP的讨论,对于理解SWAP有一定意义,推荐:
MySQL如何避免使用swap(一)
MySQL如何避免使用swap(二)
MySQL如何避免使用swap(三)
补:Memcached在启动的时候如果带上了k选项,就能避免使用SWAP,但要慎用。
…
早些年,YouTube曾经被SWAP问题困扰过,他们当时的解决方法很极端:删除SWAP!不得不说这真是艺高人胆大,可惜对芸芸众生的我们而言,这实在是太危险了,因为如此一来,一旦内存耗尽,由于没有SWAP的缓冲,系统会立即开始OOM,结果可能会让问题变得更加复杂,所以大家还是安分守己做个老实人吧。
1 关于NUMA
NUMA,即Non-Uniform Memory Access Architecture,非统一内存访问架构。NUMA模式是一种分布式存储器访问方式,处理器可以同时访问不同的存储器地址,大幅度提高并行性。NUMA模式下,处理器被划分成多个"节点"(node),每个节点被分配有的本地存储器空间。所有节点中的处理器都可以访问全部的系统物理存储器,但是访问本节点内的存储器所需要的时间,比访问某些远程节点内的存储器所花的时间要少得多。
NUMA具有多个节点(Node),每个节点可以拥有多个CPU(每个CPU可以具有多个核或线程),节点内使用共有的内存控制器,因此节点的所有内存对于本节点的所有CPU都是等同的,而对于其它节点中的所有CPU都是不同的。节点可分为本地节点(Local Node)、邻居节点(Neighbour Node)和远端节点(Remote Node)三种类型:
本地节点:对于某个节点中的所有CPU,此节点称为本地节点;
邻居节点:与本地节点相邻的节点称为邻居节点;
远端节点:非本地节点或邻居节点的节点,称为远端节点。
邻居节点和远端节点,称作非本地节点(Off Node)。
CPU访问不同类型节点内存的速度是不相同的:本地节点>邻居节点>远端节点。访问本地节点的速度最快,访问远端节点的速度最慢,即访问速度与节点的距离有关,距离越远访问速度越慢,此距离称作Node Distance。常用的NUMA系统中:硬件设计已保证系统中所有的Cache是一致的(Cache Coherent,ccNUMA);不同类型节点间的Cache同步时间不一样,会导致资源竞争不公平,对于某些特殊的应用,可以考虑使用FIFO Spinlock保证公平性。
2 NUMA对MySQL性能的影响
NUMA的内存分配策略有四种:
1.缺省(default):总是在本地节点分配(分配在当前进程运行的节点上)
2.绑定(bind):强制分配到指定节点上
3.交叉(interleave):在所有节点或者指定的节点上交织分配
4.优先(preferred):在指定节点上分配,失败则在其他节点上分配
因为NUMA默认的内存分配策略是优先在进程所在CPU的本地内存中分配,会导致CPU节点之间内存分配不均衡,当某个CPU节点的内存不足时,会导致swap产生,而不是从远程节点分配内存。这就是所谓的swap insanity现象。
MySQL采用了线程模式,对于NUMA特性的支持并不好,如果单机只运行一个MySQL实例,我们可以选择关闭NUMA,关闭的方法有三种:
1.硬件层,在BIOS中设置关闭;
2.OS内核,启动时设置numa=off;
3.可以用numactl命令将内存分配策略修改为interleave(交叉),有些硬件可以在BIOS中设置。
如果单机运行多个MySQL实例,我们可以将MySQL绑定在不同的CPU节点上,并且采用绑定的内存分配策略,强制在本节点内分配内存,这样既可以充分利用硬件的NUMA特性,又避免了单实例MySQL对多核CPU利用率不高的问题。
资源隔离方案
1.CPU,Memory
numactl �C-cpunodebind=0 �C-localalloc,此命令将MySQL绑定在不同的CPU节点上,cpubind是指NUMA概念中的CPU节点,可以用numactl �C-hardware查看,localalloc参数指定内存为本地分配策略。
2.IO
我们在机器中内置了fusionio卡(320G),配合flashcache技术,单机的IO不再成为瓶颈,所以IO我们采用了多实例共享的方式,并没有对IO做资源限制。多个MySQL实例使用相同的物理设备,不同的目录的来进行区分。
3.Network
因为单机运行多个实例,必须对网络进行优化,我们通过多个的IP的方式,将多个MySQL实例绑定在不同的网卡上,从而提高整体的网络能力。还有一种更高级的做法是,将不同网卡的中断与CPU绑定,这样可以大幅度提升网卡的效率。
4.为什么不采用虚拟机
虚拟机会耗费额外的资源,而且MySQL属于IO类型的应用,采用虚拟机会大幅度降低IO的性能,而且虚拟机的管理成本比较高。所以,我们的数据库都不采用虚拟机的方式。