文档介绍：蒀修炼之路罿袆最近在朋友的推荐下看了热播剧集《prisonbreak》,确实精彩,片中无处不在的细节让人不得不佩服男主人公的schedule实在是做得完美。感慨之余想起到相关论坛上看看大家的评论,这才发现很多我捕捉到的细节和心领神会的method居然没几个人看懂了。不由得让我凭空多了一层念想,是自己也能够适应foxriver那样的牢狱生活,还是多年来AIXservice的工作经历让我已与往日不同。嘿嘿,我情愿相信是后者。,安装配置很方便,在实际使用中可处理常见的系统单点故障,从而提高整套系统的可用性。但是使用hacmp的环境常常出现一些奇怪的现象,从而让维护的技术人员头疼不已,我们称之为“灵异现象”……芇2002年的夏天,湖南长沙,XX医院,hacmp互备。莃这个医院的财务系统用的是IBMH85的双机,hacmp互备模式,DB2数据库,2台机器分管住院部和门诊部的财务系统。不知道从哪一天开始,这套系统也碰上了让人头疼的“灵异”。医院的系统管理员说他们在正常使用中发现住院部的财务系统运行突然变慢了,经检查才发现住院部那台机器已经宕机,住院部业务已经由门诊部那台顺利接管,只不过看起来由于系统资源紧张,所以才让窗口的业务人员发现速度有异。接下来,系管重新开机,重新启动hacmp,一套流程走下来,住院部主机重新担负起了自己的任务,业务窗口速度也恢复了正常。节看上去一切都挺好,系统环境又恢复了正常,只不过……聿三天以后,住院部主机又挂了。再来一次恢复流程,住院部主机起死回生……莄三天以后,“挂”就一个字……膅如此反复,这家医院的系管已经可以掐指算出住院部主机即将到来的“死亡时间”,误差不超过3小时。在这家医院信息部领导精神全面崩溃之前,他们找到了我所在的公司。肁老板给我交代任务的时候,附带告诉我在此之前已经有资深的软硬件工程师到现场全面检查过了,每个人都是拍拍胸脯告诉可怜的系管自己这一块绝对没问题然后以尽可能快的速度离开了现场,留下系管一人绝望的面对即将到来的宕机时间……死亡无法避免。膈说实话,这附带信息对当时只有一年AIX经验的我来说不是什么很有用的消息,除了凭空多出许多压力之外。螅到了现场,我一直在想一个问题——系管的头发是一直这么少,还是这段时间才发生了变化。问题没有答案,我只希望自己能够帮到这个可怜的同行,看上去他虽然很热情,但是和遍访名医的重症病人家属一样,眼神中已经失去了“求生”的信念。薃排除杂念,对着住院部的主机我砍出三板斧——df,errpt,diag。无效。一切看上去都很正常。细想想,这也正常,这三斧头是个人就会砍。想必在我之前来的那些资深已经都砍过三十几斧头了。,顿时有了点不敢相信自己眼睛的感觉——已经生成了近50MB的文本文件。原本想从里面找点信息的想法一瞬间也去了大洋对岸。难怪资深们都闪人了,我似乎有点明白了。袀口中默念着高中班主任留给我的名人名言——“人啊!不能在一棵树上吊死,让我们一起来换棵树吧!”——我杀向门诊部主机。芈系管有些惊讶,但还是尽量委婉的告诉我:“严工,这台机器是好的”。膆“知道”,回应:“我看看”芅同样无效的三斧头过后,,,虽然也过分的达到了11MB的大小。袃在“尽量”,我开始深刻理解资深们的难处了。巨量的事件脚本记录给“阅读”带来了麻烦,2个小时的仔细阅读之后,除了感觉眼睛有点疼,我暂时没有别的新见解。莈无奈中,我开始快速翻屏,现在回想起来,当时这么做可能是潜意识中的什么元素起了作用。如《骇客帝国》中飞快滚动的黑底绿字由下至上的掠过屏幕,除了更加不可阅读之外,似乎没有别的什么好处了。薇等等……这是什么……螃由于快速翻屏和每个事件纪录长度大致相等的2个重要因素,加上视觉暂留效应,我在屏幕上的特定位置看到了近乎稳定的事件名称fail_standby_adapter和join_standby_adapter。这两个事件记录名称如此显眼的出现在我面前,确实让我精神为之一振。这样的情况下我还能看到这两个事件,只能说明这两个事件出现的次数特别多。详细检查了这两个事件发生的时间点,得到了让我开始感觉兴奋的消息——每秒钟要发生4到5次的fail_standby和join_standby。这说明有块standby的网卡不断的退出和加入到standby状态。顺着思路往下想,,,同时也会占用相当大空间的filebuffer且由于不