美创科技技术社区

注册

 

发新话题 回复该主题

从几个简单案例说起 [复制链接]

1#

    本来这部分内容应该安排在最前面,作为抛砖引玉的,不过在这里给出,会更加容易理解。

           案例一、某银行网上银行系统每月或者每几月会出现一次或者几次业务性能快速下跌,响应迟缓。具体表现为CPU利用率居高不下,在大多数情况下,重新启动之 后业务性能就恢复了。即使偶尔几次启动之后依然缓慢,但只要多启动几次就不会有问题。前线工程师检查AWR发现CPU大量消耗,Waiting的影响很 小,检查Top SQL发现其中一条SQL消耗了大部分的CPU资源,通过PLSQL Explain该语句的执行计划,似乎感觉是正确的,手工执行该语句,反映极为迅速,似乎感觉没有问题。性能优化到此陷入迷局。请问读者,你会怎么办?
          事实上,即使你没有任何材料,在上述描述之后基本可以判断出来,只有可能是以下两种情况: (1)、网上银行系统具有不可预期的并发性,可能会出现超出预期的突发高峰,而业务系统没有做足够的缓冲或者队列机制导致数据库系统超出负载运行。 (2)、虽然感觉执行计划正确,运行速度也很快,还是应该是执行了错误的执行计划。当然猜测性的东西用户不会认可,这个时候只要看看正常时候的AWR和问 题时候的AWR比较一下就可以了:
          检查了两份发过来的AWR报告,前线工程师由于时间紧张感觉似乎没有太大差异。但依据我们的判断,我们只要检查两点:(1)、该语句的每秒执行数量是否远 远超过正常值  (2)、该语句的每次buffer gets是否发生明显的变化。当然我们看到了两份awr报告揭示了类似的每秒执行次数,但每次执行的buffer gets具有明显的变化,一个是4,一个是30左右,虽然每次仅仅30个buffer gets也是很不错的,但明显比较基准还是发生了很大的变化。这个时候可以断言执行计划发生了变化,SQL并不需要优化,只要恢复执行计划即可。当然这个 结论用户是不会接受的,凭什么说执行计划变化了?PLSQL Explain是正确的,我没有检查Explain的执行计划,我们这个时候只要列出前后的执行计划即可,我让前线工程师通过wrh$_sql_plan 寻找该SQL_ID的执行计划变化,自然就发现了两个执行计划,一个正常的,一个错误的。两者的执行效率都很好,只不过一个执行计划的索引效率更高而已。
         不知道各位看出来什么没有? 基线,基线,只要你具备基线,以上问题可以轻松解决,否则会陷入SQL优化的迷局,而且很难说服用户。

           案例二、某运营商的CRM系统似乎感觉1天比1天慢,但很不明显,不过最近几天发生突变,在高峰期性能迅速变差。AWR报告显示其他一切都感觉不错,只是 每个IO的响应时间有所延迟,IO的等待量偏高,操作系统IOStat也显示avwait偏高,disk queue的设置在256。比较基线数据,一切都表现类似,只是压力比较以前在渐渐增大。业务规模的增长,即使业务规模没有增长,数据总是在增长的,这种 现象应该是正常的。检查Top SQL,即使最大的TOP SQL才区区百分之一不到IO比例,而且从一只运行来看,SQL优化应该没有多少前途。检查每秒IO数量,已经高达35000个IO,达到了2块HBA卡 的极限值,简单增加2块HBA卡,所有业务恢复正常。
          大家都知道资源瓶颈的分析方法,资源瓶颈的分析首先要确认资源的吞吐量曲线图,几乎任意设备在达到极限值的时候性能会发生突变。优秀的设备会一直平稳到突 变,差些的会到一定阶段就会发生缓慢变异,到达极限值之后会发生剧烈变异。任何性能优化者都需要了解资源的吞吐量曲线,并大致了解其极限值所在。就这个案 例而言,增加HBA卡是一种最为简单可行的方案,成本也不高,比较漫天满地都降低PIO要来的实在,当然另外的途径就是对于大量PIO的表格进行缓存,不 过这个需要大量的内存支持。

          案例三、某工商局的业务系统,在业务压力稍微大些就性能不佳。AWR报告显示即使在所谓的高负载期间也是几乎没有负载,AWR显示一切正常,CPU不 高,Wait不高 。似乎从AWR报告看陷入迷局,让人发了AWR报告给我,看了之后告诉他们应该是虚拟内存配置不当,SGA配置过大或者交换区配置太小。同事登陆上业务系 统查看,果然存在大量的交换,SGA内存配置过高,把SGA降低了所有都恢复了。类似的问题在那些小业务量的系统中很多,配置不当引起性能不当。
        如何从AWR报告中发现内存配置不当?  buffer gets的CPU消耗和消逝时间,在这个系统中,buffer gets的速度明显偏慢,一般来说CPU不会出现问题,内存本身也不太会出现问题,那只能是虚拟内存了。这个案例事实上和案例二是一致的,只不过资料偏 少,只有一个AWR报告。在没有基线数据的前提下,经验数据就成为性能优化者需要掌握的了。

          案例四、某运营商的业务系统,电话描述说很奇怪,在省分和杭州的用户访问速度很快,但是绍兴的用户访问速度很慢。我问两者之间有什么区别,回答说一个是 100M网络,一个是10M网络。我再问是否只有特定业务有问题,回答说是的,只有一笔查询业务比较慢。我说这个查询是否返回大量的数据,回答说大约是 4000条数据。OK,到了这里问题就很明显了,网络速度的差异导致了特定操作的性能差异,网络升级到100M?那显然要被人敲脑袋的。解决方案很简单: 增加array fetch size,减少网络间交互,让开发商修改下代码就可以了。

         在我处理性能优化的过程中,相当多的案例都是不登录系统,不看AWR报告的,简单沟通就可以完成看起来很复杂的性能优化,这里最重要的在于沟通,一个性能 优化者要学会基于性能的沟通,沟通可以很好的发现性能差异前后的上下文。就以上的案例四,我相信即使有AWR报告,也未必可以扑捉到这个异常行为,毕竟 AWR是全局性系统快照分析。

分享 转发
TOP
发新话题 回复该主题