记一次服务器宕机原因排查（oom内存溢出）

一、背景

国庆期间，公司上线了一个投票活动，八号回来中午投票结束。一切风平浪静，就在投票快结束前十几分钟页面突然进不去了。

二、猜测

按照我的猜测，推测有以下几种可能性：
1.页面BUG，导致活动出错。
2.页面高并发，网络拥挤导致页面进不去
3.人为操作失误
4.内存问题。服务器宕机

三、排查

1.首先简单的测试了一下页面是否正常，发现不管用户端还是管理后台都无法进入
2.因为活动快结束了，很多人在刷票，所以猜测是服务器并发导致的，登录服务器查看了一下服务器并发，但是目前并发只有几百（宕机一段时间了），这次活动使用的是备用机器，但是不至于几百并发就挂掉，排除并发导致。
3.紧急处理直接重启Http服务，重启后发现后台恢复正常可以进入，但是用户端依然不行，说明通过维护可以使服务器回归正常，初步排除BUG原因。
4.思考为何手机端还是进不去，猜测是因为用户端大量使用缓存redis，查看redis状态，如下：

发现redis状态出错，因此重启redis服务，至此活动已经恢复正常。
5.询问了其他人，都没有登陆过服务器，也没有进行多余操作，排除人为原因
6.怀疑是服务器内存保护机制在内存较少的情况下主动kill掉了相关进程
7.

可以看到，oom killer在47分前后杀死了httpd和redis的进程，时间上和活动出问题的时间点相符合




内存不足，杀死httpd

redis相关内核信息，47分前后失效

当Out of memory时，系统会自动找到内存分配最大的“最犯”，显然redis.service被盯上了，所以被关闭了

四、oom

关于oom，直接在网上抄了一段比较简单易懂的文字：

Linux内核根据应用程序的要求分配内存，通常来说应用程序分配了内存但是并没有实际全部使用，为了提高性能，这部分没用的内存可以留作它用，这部分内存是属于每个进程的，内核直接回收利用的话比较麻烦，所以内核采用一种过度分配内存（over-commit memory）的办法来间接利用这部分“空闲”的内存，提高整体内存的使用效率。一般来说这样做没有问题，但当大多数应用程序都消耗完自己的内存的时候麻烦就来了，因为这些应用程序的内存需求加起来超出了物理内存（包括swap）的容量，内核（OOM killer）必须杀掉一些进程才能腾出空间保障系统正常运行。用银行的例子来讲可能更容易懂一些，部分人取钱的时候银行不怕，银行有足够的存款应付，当全国人民（或者绝大多数）都取钱而且每个人都想把自己钱取完的时候银行的麻烦就来了，银行实际上是没有这么多钱给大家取的。

五、总结

本次服务器问题，主要是由于内存溢出造成的，当时大量的机器请求访问活动进行刷票，一时间占满了这台机器的内存，导致oom killer进程，也将redis和httpd关闭了。