oom和oom-killer实例简介（内存用完和进程杀死）------顺便说说linux下的两个重要目录：/proc/kmsg和/var/log/messages

        oom就是out of memory,  意思就是内存用完了（内存泄漏可能导致这种现象）。 在linux中， 如果linux机器的内存用完了， 会怎样呢？ 很显然， 系统肯定无法正常工作。 linux当然要考虑这种问题， linux会杀死占用内存很大的进程（这些进程后续可能被重新拉取）， 从而释放出一些内存， 来保证整个系统的的正常运行, 这就是linux oom-killer的机制。

        在oom期间， 系统经常会遇到一些莫名其妙的异常， 这是能理解的， 因为内存吃紧啊。  过一会儿， 经历oom-killer后， 系统又暂时恢复正常了， 待到下次内存泄漏积累到一定阶段， 再次出现oom时， 系统又异常。 这种现象是很常见的， 如果不了解oom和oom-killer,  则不太容易查到问题的原因， 那么这种每周偶尔出现一次异常， 过会又自动好了的问题，非常蛋疼。

        我以前也很少直接处理oom问题， 最近遇到了， 所以来学习和总结一下。

         那么， 怎么查看oom信息呢？ 我们可以查看/proc/kmsg这个内核信息， 如下： cat /proc/kmsg

......

<3>[892868.841317] Out of memory: Kill process 19174 (vidc_static_age) score 10 or sacrifice child
<3>[892868.841320] Killed process 19174 (vidc_static_age) total-vm:306876kB, anon-rss:169200kB, file-rss:0kB
<4>[892874.892970] xxxxxx invoked oom-killer: gfp_mask=0x201da, order=0, oom_score_adj=0

......

        可以看到， 有out of memory信息了， 内核kill掉了对应的进程， 而且是业务的xxxxxx进程invoke了oom-killer

        我们继续来看/var/log/messages,  这里面主要是系统的一些错误日志，如下：

Mar 10 23:40:13 ...... kernel: xxx invoked oom-killer: gfp_mask=0x201da, order=0, oom_score_adj=0
Mar 10 23:40:13 ...... kernel: [] oom_kill_process+0x241/0x390
Mar 10 23:40:13 ...... kernel: [] ? oom_unkillable_task+0xcd/0x120
Mar 10 23:40:13 ...... kernel: [ pid ]   uid  tgid total_vm      rss nr_ptes swapents oom_score_adj 

        可以看到， 这里会有oom和oom-killer的具体时间。 经我对比发现， 上述时间， 与系统发生异常报警的时间一致。 所以， 系统发生异常确实是由oom引起的。

        既然我们知道了oom和oom-killer的大致原理和查看方法， 那怎么定位哪里的代码产生了内存泄漏呢？  我会在后续博客中进行介绍！