MySQLOOM系列三摆脱被杀的厄运，MySQL

在第二章中，我们分析了Linux内存分配策略和Linux解决超售机构使用oom_killer造成风险，MySQL和其他应用程序，但也可以出售的超级操作系统允许的范围内，一般的理解，innodb_buffer_pool必须小于实际的物理内存，否则MySQL将无法启动的。事实上，这是一种误解。这不受MySQL级别的控制。它由操作系统（OS）级别控制。这是 /程序/系统/ overcommit_memory控制之前，是否允许超售操作系统。如果超售是允许的，这innodb_buffer_pool可以远远超过实际内存空间，但这部分空间是没有用的。我们可以做一个小实验，看看下面的：
MySQL的innodb_buffer_pool开启5G，但实际内存只有3G网络。

讲了这么多，现在回到我们最早提到的RDS OS杀死审出了问题，我们也提到，一旦有足够的内存数据库通常是oom_killer.there首选的目标涉及到两个问题：

1。为什么内存不足

2。如何让MySQL摆脱杀人的厄运

首先，让我们看看第一个问题一看。有内存不足的原因很多，但主要有两个方面，第一个是MySQL自身记忆的规划是有问题的。二是MySQL服务器的总体部署，将部署大量的监控或定时任务脚本，这些脚本通常缺乏必要的内存限制，在高峰时间占用大量内存，Linux oom_killer触发机制，MySQL是无辜的牺牲。

那么MySQL怎么能摆脱杀人的厄运呢MySQL是杀的内存分配机制，这是植根于Linux超售。如前所述，只要有这种机制的超售，也不可能完全避免应用程序被杀死的危险。这使得MySQL不能被杀死，只能禁止操作系统内存分配超出实际存储空间。但我们也提到，对于MySQL服务器的部署，我们不推荐，因为很多记忆MySQL仅仅是应用的开始，而不是立即使用，操作系统一旦被禁止销售，这不仅提出了更严格的要求，对MySQL的存储规划，也不能充分利用内存的问题，同时，MySQL中每个连接的私有内存动态分配。如果没有分配，它将直接导致服务器崩溃，这也会增加MySQL崩溃的风险。

由于它仅限于操作系统，不能完全避免被杀死，它只能最小化MySQL被杀死的概率。我认为我们至少可以做以下3件事：
1）MySQL内存使用的合理规划。

2）调整oom_adj参数降低MySQL优先被oom_killer锁定。

3）加强对内存的监控和报警，一旦报警，DBA应迅速介入，杀掉占用较多内存的多个链接。