MySQL 内存交换区引起的一场“血案”

        MySQL Performance murder -- SWAP

故事情节：

最近公司上了一个新的项目，关于搜索一块的项目。其程序会调用大量的SQL，包括各种条件的搜索，模糊的匹配，联动的效果，etc。其目的，是提高百度or谷歌的爬虫的量；其效果，确实有了，从上线了，据SEO相关部门的统计爬虫抓取的量大概翻了5倍。各个都Happy，唯独我Happy不起来，因为MySQL的负载极其不稳定。当晚上线时，就发现Slave的负载有点猛，CTO一声令下，再加一台Slave，点头做事就OK了，呵呵。另加了一台Slave，发现Slave的负载，确实都回归正常了，本以为息事宁人呢，，，谁知，大概隔了3,4个小时吧，新添加的Slave的负载暴增，大概160+，么情况？原来的slave到是显得平静无事。大概过了1个小时，新增加的Slave的负载回归正常，大概也就是零点几的样子；隔几个小时，负载又是直接飙升100+。没得说，身为DBA，就是要Troubleshooting。

Troubleshooting的过程：

1：因为是间接性抽风，所以认为肯定和前台的访问的频率，及调用的scope相关；就结合前台的日志，发现确实是这样。都是百度的or谷歌的爬虫疯狂的访问新的项目(搜索)时，新增的Slave的负载就会疯一样的增长。可是为何原来的Slave为何没有太大的波动呢？

2：考虑到新增的server，因为内存，CPU等硬件的配置和原来数据库的server都不一样(其实是新增的Slave比原来的Slave的内存少了一半)，必然配置参数的值也会不同。所以就从MySQl的配置文件查起，如:sort_buffer_size的大小(因为考虑到有许多SQL包含排序)，join_buffer_size(用于连接的缓存的大小)，max_connections(最大连接数，可是通过show processlist;发现也没有超过设置的值)，innodb_buffer_pool_size(确认是否为物理内存的合适比例)等等。实际自己也犯2了，呵呵，身为DBA，这都是基本的配置，按照正常的逻辑判断也不该有多大的问题，只要把这些参数设置在合理的范围内，不会引起负载那么大的波动。那为何呢？考虑到是新装的系统，莫非是系统的参数引起的？

3：于是开始查找关于一些TCP/IP，打开文件最大数等等，按照网友的最优调整，只能说希望越大失望越大吧，不起任何作用。这尼玛到底怎么回事呢？要是两台Slave出现相同的情况，也好解决了，可是就这台新增加的Slave有问题，，，没得选，静下心来，恍然大悟，才考虑到系统的CPU，内存，IO的波动。

4：通过排查，CPU正常，但是问题出来了，发现free -m查看内存时，发现SWAP既然使用了300MB，怎么会使用这么多，所以一口咬定就死SWAP捣的蛋。通过vmsata，发现si和so的值不断的变化，所以更加的肯定是发生了内存交换。既然找到问题了，那就解决吧。

内存交换区：

当操作系统因为没有足够的内存而将一些虚拟内存写到磁盘就会发生内存交换。

内存交换对MySQL性能影响是极其糟糕的。它破坏了缓存在内存的目的，并且相对于使用很小的内存做缓存，使用交换区的性能更差。MySQL和存储引擎有很多算法来区别对待内存中的数据和硬盘上的数据，因为一般都是假设内存数据访问代价更低。

因为内存交换对用户进程不可见，MySQL(或存储引擎)并不知道数据实际上已经移动到磁盘，还会意味在内才能中。

结果会导致很差的性能。例如。若存储引擎认为数据依然在内存，可能觉得为"短暂"的内存操作锁定一个全局互斥变量(例如，InnoDB缓冲池Mutex)是OK的。如果这个操作实际上引起了硬盘I/O，直到I/O操作完成前任何操作都会被挂起。这意味着内存交换比直接做硬盘I/O操作还要糟糕。

在GNU/Linux上，可以用vmstat来监控内存交换。最好查看si和so列报告的内存交换I/O活动，这比看swapd列报告的交换区利用率更重要。我们都喜欢si和so列的值为0，并且一定要保证它们低于每秒10块。

可以通过正确地配置MySQL缓冲来解决大部分内存交换问题，但是有时操作系统的虚拟内存系统还是会决定交换MySQL内存。这通常发生在操作系统看到MySQL发出了大量I/O，因此尝试增加文件缓存来保存更多数据时。如果没有足够的内存，有些东西就必须交换出去，有些可能就是MySQL本身。

有些人主张完全禁用交换文件。这样做是很危险的，因为禁用内存交换就相当于给虚拟内存设置了一个不可动摇的限制。如果MySQL需要临时使用很大一块内存，或者有很耗内存的进程运行在同一台server上(如夜间的批量任务)，MySQL可能会内存溢出，崩溃，或者被操作系统kill掉。

操作系统通常允许对虚拟内存和I/O进行一些控制。最基本的方法就是修改/proc/sys/vm/swappiness为一个很小的值，如0或1。这等同于告诉内核除非虚拟内存完全满了，否则不要使用交换区。下面是如何检查这个值的例子：

这个值显示为60，这是默认的设置(范围是0~100)。对于服务器而言这是个很糟糕的默认值。服务器应该设置为0：

另一个选项是修改存储引擎怎么读取和写入数据。使用innodb_flush_method=O_DIRECT，减轻I/O压力。DIRECT I/O并不缓存，因此操作系统并不能把MySQL视为增加文件缓存的原因。这个参数只对InnoDB有效。你也可以使用大页，不参与换入换出，这对MyISAM和InnoDB都有效。

另一个选择是使用MySQL的memlock配置项，可以把MySQL锁定在内存。这可以避免交换，但是也可能带来危险：如果没有足够的可锁定内存，MySQL在尝试分配更多内存时就会崩溃。

解决问题：

第一种方法：修改系统对虚拟内存的控制

第二种方法：修改innodb_flush_method参数

对于修改memlock配置项，不推荐。

结果：

新增加的server，运行正常，爬虫照常抓，负载很稳定在4以下。swap的使用也降到了8MB的样子。呵呵，终于可以小Happy下了。

总结：

1：troubleshooting的经验不足吧，自我评定。

2：swap对于操作系统，对于MySQL的性能影响很大。

3：要对swap的监控重视起来。

分享虾米米：

可能有的同学对于如何查看那个进程占用swap的大小比较感兴趣，如下方法：

显示的结果图如：

希望这场swap的“血案”，让我们共同成长！！！