记录一次线上服务器崩溃的排查过程

大晚上八点多，正在逛街的我，接到领导电话，告知线上出现问题，让我处理一下。领导说可能是数据库挂了。。。有人可能会说了你们数据库都没有做集群，主备，高可用吗？竟然还会挂，我淡淡一笑。。

回到正题，登录服务器ps -ef|grep mysql 查看了一下，果然mysql死翘翘了。不管三七二十一，启动了再说呗。启动之后，领导又发话了，为什么挂了啊。我邪魅一笑，待我查查。。。。

然后就开始撸起了mysql的错误日志，没有发现异常。再使用show variables like '%_log%'看了一下mysql异常退出的数据日志存放地址，再查了一下，还是没发现异常。好像一切都正常。

没办法了，找不到问题，我把思路切换到了系统日志中去，到/var/log 下使用grep -rn “mysql” 。果然发现异常了
内存不足给系统杀死了。。。再free -mh一下 发现内存很好啊

这下没法交差了，领导是个技术大牛，不好忽悠啊，这下犯难了，怎么办？？？
但是从之前的日志说明，的的确确是因为内存不足给杀死了。。。

欲知后事如何，且听下回分解。。。。

最近比较忙，今天终于回来了，我们接着唠嗑。上回说到我进入了死胡同，日志显示mysql数据库由于内存不足被杀死了，可是系统又没有显示内存不足。问题到底出在哪里呢？

就在我百思不得姐的情况下，服务器突然崩了，对没错，服务器直接卡死，连客户端界面都动不了，ssh也登录不上去，无法查看任何情况了。发消息给领导，说服务器崩了，让领导看一下监控，出了什么情况。说到这个监控，本人也是可以搭建一个的，但是公司已经购买了阿里云的监控，那我就不去费那个事情，没有权限，只能让领导看。后来领导查看了监控，发了几张截图给我。


通过监控图片发现，好像什么指标都高。服务器完全承载不过来啊。难道是用户访问量真的太大导致的？
加机器？是不可能加机器的，这辈子都不可能加机器的。。。于是乎想到了高并发三大招：缓存，限流，降级。缓存是来不及优化了，而且目前来看缓存也基本做的差不多的，降级也不太能用，因为本身也没有很多业务线。就只剩下限流这个办法了。于是乎。。。
在nginx的http配置中加入：

在nginx的server中加入

加入这两个配置之后就可以起到限制某些恶意ip的频繁请求，返回503。但是如果针对大量真是不同ip的用户，服务器还是无法抗住的。也有想过把服务器的连接数配低，这样当连接数过多的时候，就会限制某些用户，返回500。但这就会导致一些用户无法使用。后来领导直接把nginx的keepalive_timeout设置了8秒，说监控中的无用tcp连接数太多了，可能连接超时时间设置太长了。

经过这一轮的修改之后，服务器恢复了一阵的平静。但是本着有多年工作经验，潜意识在告诉我事情没有那么简单。。。因为设置这个keepalive_timeout虽然可以把连接超时时间变短。但是本质问题还是没有解决。是什么原因导致的有这么多连接没有断开，还这样存留有这么多呢。。。

内事不明问百度，所以随手搜了一下，得到了这么一个答案：

说明了原因了，也找到问题了，但是还是没办法解决问题。如果把这些连接快速释放掉呢。

皇天不负有心人，果然在服务器再一次进入宕机状态时候，我top了一下，查看了一下服务器状态，负载达到了上百的恐怖数值，内存几乎耗尽。。。sleep进程非常的多。

这时候仿佛就是参透了一般，我顿悟了。我明白问题出在什么地方了。打开php的配置文件看到如下配置的值：

进一步验证了我的猜想，果然是你们闹的。啪啪啪，按着服务器的配置情况，把这些参数做了调整，整个世界终于安静下来了。可能有的博友还不明白为什么，再来两个截图：

写在最后的总结：其实网上的很多教程写的很多的提高并发能力的配置，比如什么nginx配置优化，php配置优化等，这些都是一些理论上的数据，而且针对的也是单机情况下，装一个服务的时候的配置情况。那那些配置就是为了尽量的能够使用全部的服务器资源，不让服务器资源浪费掉。但是很多小公司，或者说绝大多数的公司，并不是就是一台服务器就装一个服务的，很多情况下是一台服务器装了很多的服务。每个服务都需要服务器的资源，如果按照那些配置来改，而不是按照自己服务器的资源的具体情况来调配，就会出现当用户量大的时候，某一个不合适的配置就会导致把你的服务器资源全部耗尽。最终导致你的服务器宕机，无法响应。所以合理的调配给服务的服务器资源，达到一个临界的平衡，不至于使服务器宕机。这就是服务器的最优化和最大化配置，而不是一味的最求所谓的高并发能力。

欢迎关注本人的公众号，不定期推送问答模式技术问题，并可随机参与抽奖