我们受到非黑客攻击,是Linux内核版本3.5-rc1以及RedHat backport补丁应对swappiness=0。这是一种真实的威胁,我们一名客户受到影响,被利用OOM机制使得MySQL主数据库服务器崩溃。这个对内核的“微小”改变导致系统不能适当进行Swap,直接导致OOM机制杀掉MySQL进程。这就对如下解释产生怀疑:系统已拥有128GB内存,很多内存处于空闲状态,同时拥有128GB的空闲虚拟内存,所以在任何情况下都不该启动OOM机制。

我们本以为原因是NUMA(以前写过关于NUMA的文章),但是如果是这样的话,由于intra-node 我们就会看到一些过度的Swapping。我们通过安装numctl,配置mysql-safe,以便使用NUMA交互 模式,但是最终还是崩溃。

原来,该服务器拥有一个RHEL/Centos 6.4的新内核2.6.32-358,发布于2013年2月。此版本内核及以后版本均拥有backport补丁,系统可升级到6.4以及更高,我们期望在这一关键领域能出现很多问题。

这很令人沮丧,因为RedHat本不该去改变backport中或像RHEL6的一个生命周期中的一些行为,他们的目的很明确,像这样的事情不会发生,例如在系统5-10年生命中行为是一致的。因此当在一个产品生命周期中像这样的一个主要问题出现时,情况就很糟,诸如强制升级、配置改变、默认安装升级、监控以及审计改变等。大部分最新的Debian/Ubuntu 系统也将会有这些问题,因为他们也有更新内核,也许同样的backport.

关于swappiness,通常被工程师们所误解。它可以设置为从0-100的值,以通知内核哪个更重要,是pagecache(file cache)还是application memory。默认值为60,表示可以较多使用pagecache内存,但是这个对服务器是一个非常错误的配置。从虚拟化的角度来说,所有的服务器均需要application memory,更甚于file cache,因此我们一直设置为0,表示在swap任何application memory 之前会一直释放 file cache。但是现在,这个bug导致更少的swapping,以致大幅增加在内存压力下OOM机制起作用的机会,这个问题确实不是我们所想要的。 能够快速解决的技术方案又是怎样的?幸运的是,我们有很简单的方案。设置swappiness为1,这和0几乎是相同的优先权,以保护application memory,但是不会触发内核的改变。如此说来,1比0是更好的配置。

一如既往地,我们会为客户监控和管理这些类型问题,不断升级默认安装配置,并循环升级以影响系统。