转自：http://huoding.com/2012/11/08/198

说个案例：一台Apache服务器，由于其MaxClients参数设置过大，并且恰好又碰到访问量激增，结果内存被耗光，从而引发SWAP，进而负载攀升，最终导致宕机。

 

正所谓：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命令能提供这个信息，不过缺省并没有显示，我们需要激活一下：

  1. 打开top；

  2. 按「f」进入选择字段的界面；

  3. 按「p」选择「SWAP」字段；

  4. 按回车确认。

坏消息是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，这种现象被称为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有一定意义，推荐：

补：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 –-cpunodebind=0 –-localalloc，此命令将MySQL绑定在不同的CPU节点上，cpubind是指NUMA概念中的CPU节点，可以用numactl –-hardware查看，localalloc参数指定内存为本地分配策略。


2.IO

我们在机器中内置了fusionio卡(320G)，配合flashcache技术，单机的IO不再成为瓶颈，所以IO我们采用了多实例共享的方式，并没有对IO做资源限制。多个MySQL实例使用相同的物理设备，不同的目录的来进行区分。


3.Network

因为单机运行多个实例，必须对网络进行优化，我们通过多个的IP的方式，将多个MySQL实例绑定在不同的网卡上，从而提高整体的网络能力。还有一种更高级的做法是，将不同网卡的中断与CPU绑定，这样可以大幅度提升网卡的效率。


4.为什么不采用虚拟机

虚拟机会耗费额外的资源，而且MySQL属于IO类型的应用，采用虚拟机会大幅度降低IO的性能，而且虚拟机的管理成本比较高。所以，我们的数据库都不采用虚拟机的方式。