MySQL OOM 系统二 OOM Killer

在Linux操作系统中，内存分配策略是核心组件之一。为了防止内存超售风险，Linux采用了一种称为OOM Killer的机制。当系统可用内存（包括Swap）即将耗尽时，OOM Killer会启动，选择性地结束一些进程以释放内存。那么，问题来了，到底应该结束哪个进程呢？

对于那些对Linux内核稍有了解的人，可能会认为应该结束占用内存最多的进程。虽然这是一个考虑因素，但实际情况并非如此简单。在Linux系统中，决定哪个进程应该被结束的实际上是/proc//oom_score的值，这个值由Linux内核的oom_badness()函数计算得出。

让我们深入了解一下badness()函数。从其注释部分，我们可以了解到该函数的主要处理思路：

1. 我们希望失去的工作量最小。

2. 我们希望回收大量的内存。

3. 我们不希望无辜地结束那些消耗大量内存的进程。

4. 我们希望结束的进程数量最少（即一个）。

5. 我们试图结束用户期望我们结束的进程。此算法已经过精心调整，以满足最少惊讶原则（当你改变它时要小心）。

其中，进程的内存大小是badness的基础。进程的RAM内存使用量越高，其得分就越高，因此越容易被选为OOM Killer的目标。值得注意的是，OOM Killer主要关注物理内存，与Swap空间无关。

如果某个进程创建了大量的子进程，这些子进程占用的内存也会计算到父进程上。这意味着，如果某个父进程创建了多个子进程并且这些子进程占用了大量内存，那么这个父进程更有可能被OOM Killer选中。

进程的CPU使用时间以及运行时间也会影响其被选中的可能性。占用CPU时间越长或运行时间越长的进程，得分越低，越不容易被OOM Killer选中。

进程优先级与内存管理的奥秘：一个实验小程序的

在计算机系统管理中，进程优先级与内存分配策略是关键要素，它们共同决定了哪些进程可以优先运行，以及在内存紧张时哪些进程会被终止。最近，我对一个关于此主题的小程序进行了实验，并对其代码进行了深入解读。

我们来理解一下这个小程序的核心逻辑。它首先申请一块巨大的内存空间，然后逐步填充这些空间。通过观察这个程序的运行，我们可以了解到系统如何处理高优先级和低优先级的进程，以及特殊权限（如超级用户权限）的影响。这对于我们理解系统资源分配机制是非常有帮助的。

当进程优先级较低时（nice值为正），这些进程的“坏点”会加倍。这是因为低优先级的进程在资源紧张时更可能被终止，因此我们需要对它们的“坏点”进行惩罚，使其在资源分配中处于不利地位。相反，对于超级用户的进程，由于它们通常具有更高的重要性和权限，我们在处理这些进程时通常会采取更谨慎的态度，减少终止这些进程的可能性。也就是说，对于超级用户进程或者具有特殊权限的进程，我们会将其优先级调高。对于那些可以直接访问原始设备的进程，我们同样会提高其优先级，因为这些进程通常对用户来说非常重要。每个进程都有一个名为oomkilladj的参数，可以用来设置该进程被终止的优先级。这个参数通过移位运算影响进程的优先级，值越大，越容易被终止。需要注意的是，这个参数对进程优先级的影响非常大。这个程序的实验部分在真实的机器上运行了三个这样的进程，帮助我们直观地观察到这些策略的实际效果。这个机器拥有2G的内存和M的Swap空间。通过这个实验，我们可以更深入地理解系统如何处理内存分配和进程优先级的问题。至于程序本身，它首先分配了一个巨大的内存块（这里是1GB），然后以100MB为单位逐步填充这些内存。通过这种方式，我们可以观察到系统如何处理大块内存的分配和使用。这个实验让我们对系统内存管理和进程优先级的处理有了更深入的了解，帮助我们优化系统的性能和管理策略。至于狼蚁网站SEO优化的部分，虽然暂时不在我们的讨论范围内，但我们可以从这个实验中汲取的经验和教训同样可以应用到其他领域，包括网站优化等。通过理解和应用这些原则，我们可以提高系统的效率，提供更好的用户体验。在虚拟内存的舞台上，test1、test2和test3这三位舞者分别申请了宏大的1G虚拟舞台空间（VIRT）。他们并非真正的节俭主义者，每隔短暂的时间间隔，他们的实际内存占用（RES）就会迅速增长，每隔十秒便膨胀出惊人的100M。这如同在现实中申请了一块土地，却不断地在其上堆砌建筑，直至土地无法承受之重。

当物理内存的舞台空间告急时，操作系统开始施展Swap技巧，如同舞台工作人员调整布景，试图为这些占用者提供更多的空间。可用的Swap空间如同沙漏中的沙子，迅速减少。在这样紧张的环境下，那些未能控制内存使用的进程可能面临被系统清理的风险。

在这紧张而激烈的演出中，当内存空间告罄，test1进程未能幸免，被操作系统的OOM_Killer无情地请离了舞台。我们可以通过dmesg查看这一场景，OOM_Killer以高分oom_score将其请离舞台时留下的信息。这三位进程的oom_adj都是默认设置，他们并未提前做好准备应对这一挑战。为了验证这一切是否可以通过调整而避免，我们重新开始了实验。这次实验中我们将设置oom_adj参数的影响。重新启动三位舞者后，我们将目光聚焦在test2的进程上。我们用狼蚁网站SEO优化的命令语句为它设置了新的oom_adj值：echo 15 > /proc/12640/oom_adj。这如同给这个进程穿上了防护服。然而一段时间后，我们看到Swap空间的短缺已经达到了紧张的地步，似乎OOM_Killer即将再度登台表演。果不其然，测试中的进程PID为12640的test2被OOM_Killer选中并请离舞台。因此为了避免自己需要的进程被意外淘汰，我们可以通过调整进程的oom_adj来为其穿上保护伞。有的人可能会说这一切都是因为超售引起的，Linux提供了overmit_memory功能来禁用超售特性。然而禁用它是一把双刃剑。一旦禁用overmit特性，MySQL将无法申请超过实际内存的空间。在MySQL这个动态申请内存的舞台上，如果无法申请到足够的空间可能导致其崩溃的风险增加。这也是Linux设计overmit特性的初衷所在。经过上面的分析我们可以清晰地看到如果不进行特定的设置如调整oom_adj值那么MySQL往往会成为OOM_Killer的首选目标因为它往往是内存的最大占用者之一。那么作为MySQL我们应该如何避免被Kill的风险呢？下一章我们将站在MySQL的角度深入分析如何规避OOM的风险确保数据库的稳定运行。