MySQL server has gone away (2006) 排查

一、现象

     原先一直运行比较稳定的实时日志统计系统,由A机器迁移至B机器,第二天发现统计数据异常,查看日志注意到分析程序经常产生MySQL server has gone away (2006)异常退出,守护进程重新启动分析程序导致


二、问题推测

根据前后系统之间差异进行推测

1. 数据库授权,因为系统能连接上,首先排除这个因素

2. 日志收集器问题,跟这个关系不是很大,也排除除外

3. A和B机器之前的差异,注意到A机器的CPU一般5%不到,B机器CPU 一直30%~40%,最有可能此因素导致


二、问题定位

1. 查看导致MySQL server has gone away (2006)集中出现的时间正是访问高峰时期,在访问量很低的时候没有出现问题

2. 应该是高峰期超过一定时间没有和数据库交互,然后服务器主动断开连接


三、疑惑点

1. 由于日志分析的内部处理特性,应该高峰时期跟数据库交互更加频繁,没什么量时和数据库交互很少才对,而现在的想象正好反过来了


四、查出真相

1. 再次仔细查看日志,发现抛异常MySQL server has gone away (2006)主要发生在更新日志处理进度,豁然开朗

2. 我们的分析程序首先从日志中读取日志,进行处理,一直读取到EOF标识,更新处理进度,然后sleep(1),再次循环

3. 平时由于处理速度远超过日志写入速度,因为经常sleep(1),更新处理进度,相当于和数据库保持心跳,没有超过数据库超时时间

4. 而高峰时间,日志量非常大,处理能力接近日志产生能力,CPU接近90%,理论上也会定期和数据库交互,但是由于sleep的问题,日志处理能力接近极限,再加上linux 内核中文件缓存的原因,导致每个日志处理周期加长,日志处理时间就会大于10秒,没有与数据库交互,数据库主动断开连接,然后缓存在进程内存中数据丢失

5. 找OPS询问,发现A机器是32核的,B机器是4核的, 这才解释为啥B机器和A机器处理能力差距这么大


五、解决办法

1. 修改数据库配置,由于数据库由DBA统一管理,很难找出说服他修改的理由,而已即使加上超时时间,没有本质解决问题

2. 加大CPU处理能力,因为性能的瓶颈在CPU,因此采用此种方法

你可能感兴趣的:(MySQL server has gone away (2006) 排查)