mysql踢下线_记一次博客Mysql周期性下线的故障排查

最近考完研了，就开始写博客，记录和提炼自己的技术心得，当然也是借助写文章这种方法来督促自己思考，最近写博客总是隔几天mysql好像就挂了，导致总是每次登陆博客就需要上服务器启动数据库。今天终于狠下心来要把这个问题排查清楚。

故障现象

故障的现象是Mysql服务器周期性(隔几天)下线，每次上博客都需要手动启动mysql服务器。

日志排查

由于是Mysql下线，因此在日志中被下线的原因应该也会在日志中有所体现，笔者先看Mysql中日志，发现并没有任何错误相关的信息，怀疑有可能mysql相关服务被kill掉了，所以没来得及进行日志记录，于是再查阅了mysql的systemd的日志，如下显示：

systemd日志

发现由于systemd托管的自启动的mysql果然被杀掉了，第一时间想到的可能就是oom killer。然后去syslog中查询相关日志信息：

syslog中相关oom killer日志

果然，不出意外，mysqld是被oom killer杀掉了，可是为啥会oom呢？此时笔者疑惑为啥这里面会有这么多apache进程？大量的apache进程会占用大量的内存，因此我们的mysql不幸遇难了。于是笔者查阅了此时的apache访问日志和错误日志。查阅到如下的记录：

啊这，原来在这个时间点，有大量的并发访问，导致apache疯狂开进程处理请求，进而导致了内存暴涨，进而导致了oom的触发。

缓解措施

通过日志排查，发现是由于并发访问过多导致内存暴涨的问题，所以这里我们如何解决这个问题呢，就是限制apache的fork数量，并且限制服务器的并发数量来减轻并发访问对服务器的影响。具体的措施如下，通过在这apache中里面设置即可

StartServers 2

MinSpareServers 2

MaxSpareServers 5

MaxClients 30

MaxRequestsPerChild 0

通过降低apache同时服务器的请求数量，降低对服务器的负载。避免使用大量的内存导致了mysqld被oom杀掉。