一个典型业务系统卡顿故障分析

             

• 背景提要：

今年在一家客户单位驻场，遇到了一个很是经典的业务系统故障。首先是客户反馈的信息成扩大化和添油化，某日下午17点接到前台的一个科室故障反馈，第二天又反馈已经有一周了，第三天又反馈全单位都有系统使用卡顿情况，同时有反馈情况出现有半个月了。其次是无法测试定位，因为出现这种情况随机测试并无发现卡顿情况，爆发卡顿情况的时间和情况比较笼统，当前台反馈后，后端直接测试访问无异常。最后是时间，由于客户单位负责人性格直率，发现问题要求立刻解决，对于问题产生的情况原因漠不关心，急促的要求快速排插定位，武断的判断方向要求按他的思路进行排查。

• 情况分析

一个优秀的运维人员必须有一个能够冷静的内心。对于雪片飞来的催促电话和不断反馈的情况，感觉是山雨欲来，其实我们冷静分析会发现更多的柳暗花明。

1.首先业务没有中断，反馈期间没有任何人说中断导致业务系统无法运行，反馈的情况只有一个字卡

2.卡的定义：客户机卡，网络卡，系统卡。整个系统无非分为四块：硬件、网络及系统、数据库、程序系统。而且反馈的是在登录系统中提取数据的时候卡。

3.根据反馈信息不断调整排查方向，首先反馈的是一个科室，那么第一排错方向应该是看这个科室的网络，反馈情况是所有PC客户机都卡，继续排查发现只有一根网络进线。这是就需要询问本单位信息化工作人员，是否是这一个局部地方还是有其他地方。反馈是还有其他地方。不断反馈发现卡顿的时间往前推移，意味着网络汇聚层出现异常的问题不大，应将重点方向针对核心交换机，数据库

• 故障排查

核心交换机：首先查看流量有无异常情况，客户机ping大包打印，利用抓包工具进行抓包。(因考虑客户单位信息，所以这里不防截图，只讲诉过程)。没有异常。

数据库：根据反馈情况，业务系统已经登陆，数据调取的时候会出现卡顿，所以数据库是我们重点排查的区域。首先客户单位使用的是Oracle 11C ，同时还搭建了RAC和Dataguard。11g已经是非常成熟的产品，所以一开始先对磁盘空间，表空间，归档日志，内存CPU使用率进行排查，查看库的健康状态，构建oracle em控制台，进行性能分析，对SGA扩容，对所有查索引进行统计分析达到最优，并做加压测试，发现接到故障报告的当日，下午15-17点之间有大量未优化的sql语句查询，导致当时CPU占有率过高，联系软件开发人员。

    软件人员还原至之前正常的运行时期的程序环境，第二天运行后发现仍然有卡顿情况，查看CPU内存，应该没有昨天出现的过高占用情况。

当一系列的排查出来后，故障仍然存在。根据之前分析，导致卡的原因无非为硬件故障，网络及系统故障，数据库，业务程序。既然已经排除了硬件、网络、数据库、程序。那么问题方向指向系统。这时候二线支援的工程师提供一个思路就是之前他遇到过类似情况，应该是光速率传输的问题。根据以上情况立刻正对RAC系统进行排查，首先RAC的硬件都是双机环境，其中光纤交换机和存储网关是双机主备模式，存储和系统服务器是双机热备模式。将光纤交换机和存储网关切换到备机上运行。同时排查存储读取写入有无异常和数据库服务器。这时候发现存储的读写IO和数据库传输IO之间不同步，有延迟情况。手动处理同步之后，第二天继续测试。

• 故障解决

第二天在上午10:43的时候继续卡顿，下午14:15的时候又出现第二次卡顿，这时候发现在早上业务量上升的时候没有出现卡顿，即早上8点上班之后，整个早上的高峰线应该是从8点开始到11点，明显说明磁盘IO和网络IO在昨日优化之后出现了明显的改善，继续排查两边IO发现又不一致，说明导致卡顿的问题就是两边IO的不一致。导致这种情况的只能出现两个节点上，即光纤交换机和存储网关，但之前同事的经验说明光纤在此问题上出现的概率大，所以登陆在运行的光纤交换机，一条switchshow命令发现所有的光纤无异常，继续排查光衰发现也是正常。同时存储网关排查也反馈正常。因为是主备模式，工作的都是主机，理论上备机应该不对此系统有影响，但是想到现在运行的是之前的备机，是否有业务没有切换过来，所以继续排查备机。

果然在备机的第八口发现运行的传输速率是8GB，而其他口都是16GB，8GB连接的就是RAC1。因为都是双路，所以不会出现掉线情况，但是由于业务量的不断增加，传输速率的不一致引起两边IO的不一致导致此类卡顿情况。

• 结论和反思

整个处理过程中，运维一致遵循排查逻辑，无任何不当操作，对于可能导致业务中断的情况全部放在晚上操作，即保证的业务使用也给运维恢复提供充足时间。当遇到处理之后仍然不行的情况也会苦恼，被客户的不理解的指责也是愤愤不平。这次故障处理我总结了一下；

1.自己必须足够的冷静和有一套排查方向;如果像没头苍蝇的一通乱撞，是根本没有办法排查出具体原因的。

2.不要被场外的因素干扰自己的排查，在业务的第二天晚上，支援我的二线工程师已经反馈这种情况与之前在外运维的情况类似，让排查一下光纤交换机。但当时还在排查数据库，网络都未排查完成，虽然后面证明支援的同事判断是正确的，但是我个人建议坚持自己的思路来。这是一个由浅入深的过程，好比治病，没有上来就开刀做切片检查的。当然这也是一个思路问题，可以根据自己的情况来抉择。至于客户的不断催促，我个人建议是看人；如果客户懂技术，直接反馈真实情况和操作步奏。如果客户什么也不懂，就反馈排查的方向和整个操作计划。如果客户懂一半，那你直接把排查方向和他说一遍说一遍说一遍.........