来自Killer内核配置改变的威胁–Swappiness

咱们受到非******，是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是更好的配置。

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