重大疑难故障分析日志(已经解决)

来源:互联网 发布:靠谱的网络整合营销 编辑:程序博客网 时间:2024/05/11 20:46

故障现象:

三个不同的应用,每个应用都是N台服务器的集群。从两周前出现一个非常奇怪的现象,每天从11:20开始,

到下面的几个点的20分,如12:20,13:20,14:20,15点20.一直到某个点结束,每个点的20分都是会发生数据库

连接暴涨,把有数据库请求的方法进行拦截,很多方法竟然执行20多秒,最后超时退出(正常的100ms以内)。

不过这样的情况仅持续很短时,不超过一分钟就恢复正常。


分析过程:

我是参与这个故障分析,不是主导。

1.首先怀疑数据库本身是否有定时任务或时间触发器在做什么工作影响了外部的请求,但是数据库方面的排查

一切正常。全国数据库排名前十的其中六人在我们集团,他们对数据库是否异常的认识我们还是相信的。


2.应用本身,如果有定时任务,那么就应该是针对不同应用的定时任务。这样的定时任务一定是受管的,但排

查所有配置,未发现问题。

3.既然不同应用同时发生问题,那么最可能的原因应该来自外部一个全局的环境。网络,共同的数据库或

memcached等。数据库未发现问题,那么网络方面分析,流量分布一切正常。路由,防火墙策略等均发现异常。

我们是和国内其它运营商平行的主干网,维护水平应该比电信级的更高级一些(因为他们是公家的),所以网

络方面原因排查结果也是可信的。


4.分析业务日志,是否有瞬间的攻击,或者特殊的请求比如构造一个32K的字符串让你的数据库查询。日志我们

细分到每分种,请求数也基本和没有发生问题的时间断平均值一致。请求参数也没有异常。


5.在没有其它路径可走的情况下,只能隔离分析(线上环境,不到万不得已不走这样的险招)。首先数据库实例

本身我们认为是可靠的。但是它和应用间的连接质量是否可靠?于是在昨天晚上把数据库所在的小型机的网卡

进行切换,今天11点开始观察。(11点之前一切正常)


11:20,每天如约而至的连结暴涨没有了,方法调用超过500ms的没有了(原来有大量的超过20s).


故障现象已经消失,定位于连结到数据库的网络振荡。已经接近真相的99%。

今天继续分析引起振荡的原因: 1.物理网卡?2.交换机口?3.bond software?

如果是1或2,什么样的物理故障竟然导致定时性的振荡?

最终定位于“定时同步程序导致瞬间流量暴涨”致辞交换机的上联口buffer被打死,每秒1G多的流量同步流量。硬件BUG,目前无解,解决方案是每个应用的

数据同步分开做,不走统一的通道。

原创粉丝点击