Linux 的 OOM 终结者

现在是早晨6点钟。已经醒来的我正在总结到底是什么事情使得我的起床闹铃提前了这么多。故事刚开始的时候,手机铃声恰好停止。又困又烦躁的我看了下手机,看看是不是我自己疯了把闹钟调得这么早,居然是早晨5点。然而不是,而是我们的监控系统显示,Plumbr服务出故障了。

作为这个领域的经验丰富的老鸟,我打开了咖啡机,这是正确解决问题的第一步。一杯咖啡在手之后,现在我可以开始处理故障了。首先要怀疑的是应用程序本身,因为它在崩溃之前一点异常也没有。应用程序日志中没有错误,没有警告,也没有任何可疑的信息。

我们部署的监控系统发现进程已经挂掉了并重启了服务。由于现在咖啡因已经流淌在我的血液中了,我开始变得信心十足。果然在30分钟后,我在/var/log/kern.log日志中发现了下面的信息:


  1. Jun 4 07:41:59 plumbr kernel: [70667120.897649] Out of memory: Kill process 29957 (java) score 366 or sacrifice child
  2. Jun 4 07:41:59 plumbr kernel: [70667120.897701] Killed process 29957 (java) total-vm:2532680kB, anon-rss:1416508kB, filers:0kB

很明显我们被Linux内核给坑了。你知道的,Linux里面有许多邪恶的怪物(也叫作守护进程)。这些守护进程是由几个内核作业所看管的,其中的一个犹为恶毒。所有的现代Linux内核中都会有一个内存不足终结者(Out of memory Killer, OOM Killer)的内建机制,在内存过低的情况下,它会杀掉你的进程。当探测到这一情况时,这个终结者会被激活,然后挑选出一个进程去终结掉。选择目标进程使用的是一套启发式算法,它会计算所有进程的分数,然后选出那个分数最低的进程。

理解”Out of memory killer“

默认情况下,Linux内核会允许进程请求的内存超出实际可用内存的大小。这在现实世界中是有意义的,因为大多数进程其实并不会用到所有分配给它的内存(注:同一时间内不会全用到)。和这个问题最类似的就是运营商了。他们承诺卖给用户的都是100Mb的带宽,这实际上远远超出了他们的网络容量。他们赌的就是用户实际上并不会同时用完分配给他们的下载上限。一个10Gb的连接可以很轻松地承载100个以上的用户,这里的100是通过简单的数学运算得出的(10G/100M)。

这个做法的一个很明显的副作用就是,万一有一个程序正走上了一条耗尽内存的不归路怎么办。这会导致低可用内存的情况,也就是没有内存页能够再分配给进程了。你可能也碰到过这种情况,没有root帐户你是杀不掉这种顽固的进程的。为了解决这一情况,终结者被激活了,并找出了要终结的进程。

关于"Out of memory killer"参数的调整,可以参考下这篇文章

是谁触发了Out of memory killer?

虽然现在已经知道发生了什么,但还是搞不清楚到底是谁触发了这个终结者,然后在早晨5点钟把我吵醒。进一步的分析后找到了答案:

  • /proc/sys/vm/overcommit_memory中的配置允许内存的超量使用——该值设置为1,这意味着每个malloc()请求都会成功。
  • 应用程序运行在一台EC2 m1.small的实例上。EC2的实例默认是禁用了交换分区的。

这两个因素正好又赶上了我们服务的突然的流量高峰,最终导致应用程序为了支持这些额外的用户而不断请求更多的内存。内存超量使用的配置允许这个贪心的进程不停地申请内存,最后会触发这个内存不足的终结者,它就是来履行它的使命的。去杀掉了我们的程序,然后在大半夜把我给叫醒。

示例

当我把这个情况描述给工程师的时候,有一位工程师觉得很有意思,因此写了个小的测试用例来重现了这个问题。你可以在Linux下编译并运行下面这个代码片段(我是在最新的稳定版Ubuntu上运行的)。


  1. package eu.plumbr.demo;
  2. public class OOM {
  3. public static void main(String[] args){
  4. java.util.List l = new java.util.ArrayList();
  5. for (int i = 10000; i < 100000; i++) {
  6. try {
  7. l.add(new int[100_000_000]);
  8. } catch (Throwable t) {
  9. t.printStackTrace();
  10. }
  11. }
  12. }
  13. }

然后你就会发现同样的一个 Out of memory: Kill process (java) score or sacrifice child信息。

注意的是,你可能得调整下交换分区以及堆的大小,在我这个测试用例中,我通过-Xm2g设置了2G大小的堆,同时交换内存使用的是如下的配置:


  1. swapoff -a
  2. dd if=/dev/zero of=swapfile bs=1024 count=655360
  3. mkswap swapfile
  4. swapon swapfile

解决方案?

这种情况有好几种解决方案。在我们这个例子中,我们只是把系统迁移到了一台内存更大的机器上(裤子都脱了就让我看这个?)我也考虑过激活交换分区,不过咨询了工程师之后我想起来JVM上的GC进程在交换分区下的表现并不是很理想,因此这个选项就作罢了。

还有别的一些方法比如OOM killer的调优,或者将负载水平分布到数个小的实例上,又或者减少应用程序的内存占用量。

原文发布时间为:2015-07-21



本文来自合作伙伴“Linux中国

时间: 2024-09-24 02:39:54

Linux 的 OOM 终结者的相关文章

Linux的OOM终结者

现在是早晨6点钟.已经醒来的我正在总结到底是什么事情使得我的起床闹铃提前了这么多.故事刚开始的时候,手机铃声恰好停止.又困又烦躁的我看了下手机,看看是不是我自己疯了把闹钟调得这么早,居然是早晨5点.然而不是,而是我们的监控系统显示,Plumbr服务出故障了. 作为这个领域的经验丰富的老鸟,我打开了咖啡机,这是正确解决问题的第一步.一杯咖啡在手之后,现在我可以开始处理故障了.首先要怀疑的是应用程序本身,因为它在崩溃之前一点异常也没有.应用程序日志中没有错误,没有警告,也没有任何可疑的信息. 我们部

Linux内核OOM机制的详细分析(转)

Linux 内核 有个机制叫OOM killer(Out-Of-Memory killer),该机制会监控那些占用内存过大,尤其是瞬间很快消耗大量内存的进程,为了 防止内存耗尽而内核会把该进程杀掉.典型的情况是:某天一台机器突然ssh远程登录不了,但能ping通,说明不是网络的故障,原因是sshd进程被 OOM killer杀掉了(多次遇到这样的假死状况).重启机器后查看系统日志/var/log/messages会发现 Out of Memory: Kill process 1865(sshd)

与Linux OOM-killer的第一次亲密接触

受害人口述悲惨的遭遇-- 1.最近一段时间(更换了预发机器后)我负责的一个应用的预发环境(线上稳定得像个婴儿~)特别不稳定,最先是应用频频的过几天就发现提供的接口不工作了,但容器Jetty还在跑得欢,于是jstack/jmap看,发现没有一个线程在跑我的war包中的程序,但是容器里个中间件的sar还跑得很欢(-_-|||),dump出来的对象也没有一点蛛丝马迹,所有日志到04:03就什么也没有了.然后查发现一个中间件的sar(远程接口层)包刚好在那个时候升级了,这玩意用OSGI的CloassLo

深挖android low memory killer

对于PC来说,内存是至关重要.如果某个程序发生了内存泄漏,那么一般情况下系统就会将其进程Kill掉.Linux中使用一种名称为OOM(Out Of Memory,内存不足)的机制来完成这个任务,该机制会在系统内存不足的情况下,选择一个进程并将其Kill掉.Android由于是嵌入式设备的操作系统,则使用了一个新的机制Low Memory Killer来完成同样的任务.下面首先来看看Low Memory Killer机制的原理以及它是如何选择被Kill的进程的.   1.Low Memory Ki

一种提高Android应用进程存活率新方法(上)

基础知识 Android 进程优先级 1 进程优先级等级一般分法 Activte process Visible Process Service process Background process Empty process 2 Service技巧 onStartCommand返回START_STICKY onDestroy中startself Service后台变前置,setForground(true) android:persistent = "true" 3 进程优先级号 P

《Redis官方教程》-FAQ

原文链接   译者:Alexandar Mahone  校对:方腾飞(红体标记重点) 为什么Redis不同于其他的键值存储数据库? 有两个主要原因: Redis发展方向不同与其他键值数据库,它能包含很多复杂数据类型,对这些数据类型操作都是原子的.Redis数据类型与基本数据结构强相关,直接暴露给程序员,没有增加抽象层. Redis是一个内存数据库,而不是持久化在硬盘数据库中,因此为了实现高速读写,数据集大小不能超过内存.内存数据库另一个优点是,内存数据库相对于硬盘数据库非常容易操作复杂数据结构,

Linux系统的OOM Killer处理机制

  最近有位 VPS 客户抱怨 MySQL 无缘无故挂掉,还有位客户抱怨 VPS 经常死机,登陆到终端看了一下,都是常见的 Out of memory 问题.这通常是因为某时刻应用程序大量请求内存导致系统内存不足造成的,这通常会触发 Linux 内核里的 Out of Memory (OOM) killer,OOM killer 会杀掉某个进程以腾出内存留给系统用,不致于让系统立刻崩溃.如果检查相关的日志文件(/var/log/messages)就会看到下面类似的 Out of memory:

理解和配置 Linux 下的 OOM Killer

最近有位 VPS 客户抱怨 MySQL 无缘无故挂掉,还有位客户抱怨 VPS 经常死机,登陆到终端看了一下,都是常见的 Out of memory 问题.这通常是因为某时刻应用程序大量请求内存导致系统内存不足造成的,这通常会触发 Linux 内核里的 Out of Memory (OOM) killer,OOM killer 会杀掉某个进程以腾出内存留给系统用,不致于让系统立刻崩溃.如果检查相关的日志文件(/var/log/messages)就会看到下面类似的 Out of memory: Ki

MySQL OOM 系列一 Linux内存分配_Mysql

RDS(网易云关系数据库服务)上线已经有一段时间,陆续不断有产品迁入到了RDS中,在线上运维的过程中,也遇到了一些曾经没有考虑到,或者考虑的不全的东西.后续有时间可以分享给大家. 今天想提到的是线上一个4G的RDS实例,发生了OOM(out of memory)的问题,MySQL进程被直接Kill掉了.在解释这个问题的时候,我们首先需要从Linux系统内存分配策略讲起.     一般写C语言程序,我们习惯使用malloc动态的申请内存空间(Java由JVM负责内存管理),malloc函数会向操作