我们受到非黑客攻击，是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是更好的配置。
一如既往地，我们会为客户监控和管理这些类型问题，不断升级默认安装配置，并循环升级以影响系统。