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，因此采用此种方法