重大疑难故障分析日志(已经解决)
来源:互联网 发布:靠谱的网络整合营销 编辑:程序博客网 时间: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,目前无解,解决方案是每个应用的
数据同步分开做,不走统一的通道。
- 重大疑难故障分析日志(已经解决)
- oracle故障解决日志
- 如何快速解决IT系统中的疑难故障问题
- 如何快速解决IT系统中的疑难故障问题
- 故障分析与解决
- 生产环境重大故障
- 局域网资源共享故障分析解决
- 内存故障分析与解决
- 电脑自动重启故障的分析解决(二)
- [Oracle]Redo log日志组故障分析
- Oracle Redo log日志组故障分析
- 某生产系统RAC故障分析日志
- Redo log日志组故障分析
- 轻松定位硬件故障方法-日志分析
- 实例分析:局域网资源共享故障分析解决
- j2ee疑难解决实例
- ubuntu 疑难解决<新手>
- PPP学习疑难解决
- 上海买房缴税
- QT中DLL的生成和调用(查了些资料在同事的帮助下完成)
- 部署到AIX系统乱码问题
- misc.properties文件的一些配置的实例
- InnoDB引擎表的主键选型
- 重大疑难故障分析日志(已经解决)
- Java中x=x+y与x+=y的区别,体现强制类型转换
- HeadFirst学习笔记2:抽象工厂模式
- 我的python学习之路----转换位串到utf-8字符串
- 商务局 存储过程
- 03-05 创建和编辑AutoCAD实体(五) 使用图层、颜色和线型(2)使用颜色
- 下面程序的输出结果是多少?
- 自然语言理解双重路径
- Linux操作系统常用命令