杨建荣的学习笔记

每天坚持一点点,个人微信公众号: jianrong-notes, 个人邮箱:jeanrock@126.com

  • 博客访问: 12590595
  • 博文数量: 1324
  • 用 户 组: 普通用户
  • 注册时间: 2012-05-14 23:24
  • 认证徽章:
个人简介

每日发文,或技术、或总结,偶有日间小事也以为记,谓之学习笔记,成年累月1200多天,中间几乎没有间断,要旨只有一个:学习交流,共同进步 。 学习笔记精华整理,个人新书《Oracle DBA工作笔记》已开售,在京东,当当,亚马逊,淘宝,天猫均有售,欢迎选购。

ITPUB论坛APP

ITPUB论坛APP



APP发帖 享双倍积分

文章分类

全部博文(1324)

文章存档

2017年(250)

2016年(358)

2015年(360)

2014年(278)

2013年(48)

2012年(21)

微信关注

IT168企业级官微



微信号:IT168qiye



系统架构师大会



微信号:SACC2013

订阅
热词专题
今日说法和现身说法 2017-08-06 23:43:08

分类: IT生活

   记得在我初中高中的时候,中午还能回家吃饭,每天12:38左右的《今日说法》就是我们必看的节目,看完节目,一点刚过点,稍微睡一会就开始下午的课了。所以法制节目伴随了我的很多时光。看到了各色案件也看到了人生百态,有些当时看不明白,现在再来看是完全不同的感受。

     法制节目确实很有意义,一线的干警非常能吃苦。在分析问题方面,我有时候都会有一种错觉,感觉DBA处理很多问题,排查的思路和警方破解一个谜题,侦破案件很相似,很多时候思路都是相通的,都是在有限的信息和资源的情况下,抽丝剥茧,逐步还原事情的真相。

    我看在各大网站论坛中,曾经的一批法制迷们发起了一个话题,那就是选出自己印象最深刻的一个案件,有些同学很有心,都整理了出来,我看到很多人都在说一个盲区监控50米的案例,是在2014年8月的一个节目,那个时候我在干吗呢,我查了下,当时还在用脚本分析足彩。

   我们来简单说下这个案件背景:

2012年年底的一天,一个年轻的女子李红在福建厦门街头,一条前后都有摄像探头的马路上突然神秘的消失了;消失之后,李红的银行账户却被人用手机查询过。报警人是李红的弟弟,因为他姐姐的两个手机都关机了。民警花费了大量的时间和精力做了地毯式的走访和调查,但是这个盲区内压根找不到任何李红的信息,警方甚至找来了环卫工人,对附近的下水井盖都做了摸排,还是没有任何证据发现。

    所以这个案件就可以反向推理一下,这样一个监控盲区,李红从商场换表离开后,就近的商业区,路口都没有出现,很可能是被绑架到车里离开了。而一旦是绑架,在一个商业区很可能会听到喊叫或者挣扎的声音,但是经过仔细的排查,没有任何的报警信息,没有任何的异常信息。

    但是案件的方向是基本明确的,李红很可能是被绑架,通过其他的车辆离开了现场,那么车辆就会分为出租车和私家车,出租车在下午两点的时间段里,总共有20辆左右,很快排查完毕。而私家车就相当难以排查了,因为那个时间点附近,路口有近1000多辆车经过,这个排查难度就相当大了。

   警方尝试从几个电话入手,虽然发现了一些嫌疑人,但是经过确认和本案无关,由此一来,整个案件进入了一种山穷水尽的地步。

    在这一点上,民警耐心,缜密的思维让人佩服,他们的分析很在理,根据这个商业区的路况情况,只有一个方向走向,而且50米的盲区没有公交车站,所以可以排查李红乘坐公交车离开的可能性,再者这里是双向12车道,中间有高架桥,有护栏,在盲区50米内没有可供掉头的路口,所以是一个单行车道。

    到了这里,如果你是负责这个案子的警察,你该怎么分析,你知道这个时间段里的1000辆车里很可能就有一个是嫌疑车辆,但是这个分析难度极大,有什么好的办法能够甄别出嫌疑车辆。

     这个不是靠外观,而是靠时间。警察的这个分析思路虽然听起来比较土,但是绝对有说服力。

    他们和交管部门做过确认,这个时间段里没有任何交通事故,所以道理是通畅的,而假设车辆的速度为60km/h,那么经过这个路口(两个探头的距离)需要花费的时间大概是30秒左右,如果这个时间段里有车辆停下来,肯定会额外花费更多的时间,所以警方就逐个开始落实这方面的信息,很快就锁定了一个车辆。发现这个车辆比其它的车辆多出来了近20秒。

   有了这些信息,能够定位到更具体的信息,处理问题就会顺利很多,后面的案件处理虽然也是多了些周折,但是也是惊心动魄。

   我们在处理数据库的问题的时候,如果碰到类似的问题,其实思路也是相通的。

   我来举一个真实的例子,一个数据库宕机的问题分析,在一套X86平台的数据库服务器,配置了64G内存,SGA配置了40G,平时的负载也比较平稳,但是有一天凌晨突然发生了宕机事故,整个问题影响范围也很大,涉及到一些活动的拉收情况,但是发现的时候还是有些晚了。整个问题后期的处理和分析中,我们都有很大的压力,而且我个人也很内疚。

    但是问题后期的分析已经过去了很多天,数据库的快照保留期限已经超过期限,也就意味着被系统删除了,我们无法得到那个时候数据库层面具体的信息。而系统日志层面,我们能够看到的就是一个oom的报错,然后就没有然后了。

     对此我做了一些分析,排查了当时的一些日志,当时的数据库连接信息在OOM崩溃前会在系统日志中打印出来,我可以清晰的看到有1000多个数据库连接,作为DBA,我对这套环境的连接情况还是比较熟悉的,以前的连接数大概是200个左右,但是近期的连接数暴增,翻了近5倍。这是不是造成整个宕机的原因呢,要说是还是很牵强,因为很多应用中1000个连接其实还是很正常的。那么问题出在哪里,如果是连接数的问题,为什么再早几天就没问题。

    这种问题我相信我自己也会问自己,怎么能够解释得通呢。首先来说说宕库的原因,Oracle的5大必备进程,SMON,PMON,DBWR,LGWR,CKPT,如果任何一个出了问题,一定会自动停掉实例。所以初步的方向很明确,是PMON被kill了,而造成的原因是MMON进程。

    再进一步,我分析了这段时间内这个数据库启动的日志,终于发现在上一次启动的时候HugePage没有能够正常开启,但是通过 /proc/mem|grep Huge查看大页的分配,却能够看到大页应开启了。

    所以问题的初步结论就很明显了,由于Hugepage没有生效导致系统性能变差,大量的短小连接频繁调用导致产生了阻塞,内存使用率变高,SWAP争用更加严重,最后PMON进程被清理掉,导致数据库实例宕机,这样下来,一个配置问题最终变为了性能问题,最终变为了监控问题,逐步上升变为了业务问题。

   虽然排查的过程信息非常有限,但是能够得到一个较为清晰,切可信的症结真是难上加难。运维无小事,事事小心用心,细节决定成败。

    这一点上,还是深深的佩服这些一线的民警英雄。





    

阅读(96) | 评论(0) | 转发(0) |
给主人留下些什么吧!~~
评论热议
请登录后评论。

登录 注册