我们受到非* * * * * *,是Linux内核版本3.5 rc1以及RedHat补丁补丁应对swappiness=0。这是一种真实的威胁,我们一名客户受到影响,被利用伯父机制使得MySQL主数据库服务器崩溃。这个对内核的“微”小改变导致系统不能适当进行交换,直接导致伯父机制杀掉MySQL进程。这就对如下解释产生怀疑:系统已拥有128 gb内存,很多内存处于空闲状态,同时拥有128 gb的空闲虚拟内存,所以在任何情况下都不该启动伯父机制。
我们本以为原因是NUMA(以前写过关于NUMA的文章),但是如果是这样的话,由于intra-node我们就会看到一些过度的交换。我们通过安装numctl,配置mysql-safe,以便使用NUMA交互模式,但是最终还是崩溃。
原来,该服务器拥有一个RHEL/Centos 6.4的新内核2.6.32-358,发布于2013年2月。此版本内核及以后版本均拥有补丁补丁,系统可升级到6.4以及更高,我们期望在这一关键领域能出现很多问题。
这很令人沮丧,因为RedHat本不该去改变补丁中或像RHEL6的一个生命周期中的一些行为,他们的目的很明确,像这样的事情不会发生,例如在系统5 - 10年生命中行为是一致的。因此当在一个产品生命周期中像这样的一个主要问题出现时,情况就很糟,诸如强制升级,配置改变,默认安装升级,监控以及审计改变等。大部分最新的Debian/Ubuntu系统也将会有这些问题,因为他们也有更新内核,也许同样的补丁。,
关于swappiness,通常被工程师们所误解。它可以设置为从0到100的值,以通知内核哪个更重要,是pagecache(文件缓存)还是应用程序内存。默认值为60,表示可以较多使用pagecache内存,但是这个对服务器是一个非常错误的配置。从虚拟化的角度来说,所有的服务器均需要的应用程序内存,更甚于文件缓存,因此我们一直设置为0,表示在交换任何应用程序内存之前会一直释放文件缓存。但是现在,这个错误导致更少的交换,以致大幅增加在内存压力下伯父机制起作用的机会,这个问题确实不是我们所想要的。能够快速解决的技术方案又是怎样的?幸运的是,我们有很简单的方案。设置swappiness为1,这和0几乎是相同的优先权,以保护的应用程序内存,但是不会触发内核的改变。如此说来,1比0是更好的配置。
一如既往地,我们会为客户监控和管理这些类型问题,不断升级默认安装配置,并循环升级以影响系统。
