MySQL OOM 系列一 Linux内存分配(mysql m1)

编辑：rootadmin

推荐整理分享MySQL OOM 系列一 Linux内存分配(mysql m1)，希望有所帮助，仅作参考，欢迎阅读内容。

文章相关热门搜索词:mysql01,mysqlor,mysql m1,mysqlone,mysqlone,mysqlor,mysql01,mysql omm,内容如对您有帮助，希望把文章链接给更多的朋友！

RDS（网易云关系数据库服务）上线已经有一段时间，陆续不断有产品迁入到了RDS中，在线上运维的过程中，也遇到了一些曾经没有考虑到，或者考虑的不全的东西。后续有时间可以分享给大家。

今天想提到的是线上一个4G的RDS实例，发生了OOM（out of memory）的问题，MySQL进程被直接Kill掉了。在解释这个问题的时候，我们首先需要从Linux系统内存分配策略讲起。一般写C语言程序，我们习惯使用malloc动态的申请内存空间（Java由JVM负责内存管理），malloc函数会向操作系统申请一段连续的内存单元，然后返回这段空间的起始地址。如果malloc函数返回为null则表示系统没有可分配的内存空间。这是我们的一般思维，当然这在某些操作系统中确实也是正确的（Solaris）。但是Linux不是这样的，Linux的内存分配采取的是一种更加积极的分配策略，它假设应用申请了内存空间后并不会立即去使用它，所以允许一定量的超售，当应用真的需要使用它的时候，操作系统可能已经通过回收了其他应用的内存空间而变得有能力去满足这个应用的需求，简单的说，就是允许应用申请比实际可分配空间（包括物理内存和Swap）更多的内存，这个特性称为OverCommit。这个特性在Linux操作系统里面也是可配的，可以通过设置/proc/sys/overcommit_memory为不同的值来调整OverCommit策略。 overcommit_memory可以取3个值：0：默认值，由Linux内核通过一些启发式算法来决定是否超售和超售的大小，一般允许轻微的超售，拒绝一些明显不可能提供的请求，同时做一些规则限制，比如不同用户overcommit的大小也不一样。 1：允许，不做限制的超售，当然这个也不是无限大，还受到寻址空间的限制，位系统最大可能只有4G，位系统大概T左右。 2：禁止，禁止超售，系统能够分配的内存不会超过swap+实际物理内存*overcommit_ratio，该值可以通过/proc/sys/vm/overcommit_ratio设置，默认%。

为了验证Linux的内存分配，我们用个小程序来测试一下：

前者再通过malloc()申请了内存空间以后，并没有立即去使用它，而后者相反，每次申请完都立即用1去填充。我们来看看两个程序运行的结果。

这是在1G的RAM，M Swap的虚拟机上运行的结果，前者申请了远远超过实际内存的空间，后者并没有超过实际内存可用空间。这就验证了前面叙述的Linux的内存分配策略。本身这是一个系统的优化，无可厚非。但是我们知道，但凡“超售”都是基于不会有大量程序同时使用资源的假设，这显然也是有风险的。所以Linux又使用了一种OOM Killer(Out Of Memory killer)的机制，在系统可用内存（包括Swap）即将使用完之前，选择性的Kill掉一些进程以求释放一些内存。下一章我们重点讨论一下Linux OOM Killer的机制。

MySQL OOM 系统二 OOM Killer 这里就涉及到一个问题，到底Kill掉谁呢？一般稍微了解一些Linux内核的同学第一反应是谁用的最多，就Kill掉谁。这当然是Linux内核首先考虑的一种重要

MySQL OOM 系列三摆脱MySQL被Kill的厄运前面两章，我们分析了Linux内存分配的策略以及Linux通过使用OOM_Killer的机制解决了超售引起的风险，MySQL同其他的应用程序一样，在操作系统允许的范围

MySQL Slave 触发 oom-killer解决方法最近经常有收到MySQL实例类似内存不足的报警信息，登陆到服务器上一看发现MySQL吃掉了%的内存，God！有时候没有及时处理，内核就会自己帮我们重启