连载-从一个项目看系统优化工程(2)

摸底分析会

总部确定了优化项目后,客户就希望优化项目组立即到现场开展工作。于是我们立即派前期人员飞往客户现场进行数据采集和简况调查。前期调研人员首先到运维单位采集了一下系统的运行数据,和运维人员做了简单的沟通。由于客户的运维自动化建设还处于初级阶段,因此生产系统上部署的采集工具十分有限,因此可以采集达到的数据只有AWR报告之类的数据库的运行数据。一般来说大多数客户在生产环境上的监控工具都存在不足的问题,因此我们的前期人员到达现场后还有一个安装部署采集工具的工作。对于一个大型优化项目来说,提前安装监控采集工具是十分必要的。当大部队到达客户现场的时候,采集工具已经采集了一定时间的数据,分析工作可以加速。否则大量的专家到达现场后还在等业务高峰的到来就会造成巨大的浪费。

完成了工具部署和初步数据采集工作后,前期人员带着数据回到项目组,这时候就有一个十分重要的会议要召开了,这个会就是摸底分析会。摸底分析会是我们在十多年优化工作中总结出的一个十分有效的会议,参会的除了即将参加优化工作的小组,还有一些业务与技术领域方面的专家。通过分析前期采集的数据对系统进行一个初步的摸底,不仅仅可以让即将奔赴现场的优化工作小组的人心里有个底,也可以让后端支持的专家对系统有一个总体了解,同时也可以让后端专家与现场工作小组的人员形成一定的沟通默契。今后这个项目的成败就取决于前端工作组与后端专家之间能否形成合力。一般来说,专家是稀缺资源,不可能每个项目都有专家到现场坐镇,一个优化项目组里也不可能囊括了所有领域的技术专家,因此专家在总部坐镇,支撑所有的优化项目是一种十分高效的工作方法,对于专业的优化团队同时实施多个优化项目至关重要。这个项目是一个试点项目,并没有全面铺开,但是也安排了两个现场同时开工,因此子衿优化团队的专家也要分成两个小组,每个小组负责一个现场,同时兼顾另外一个现场。

从现场采集回来的数据来看,这个系统存在的问题主要在应用系统的质量不高,导致部分业务模块太慢;另外在应用服务器方面也存在一定的性能问题,当应用较慢的时候,应用服务器的线程池被活跃的会话占满,导致部分请求无法响应;第三个方面就是数据库的SQL语句响应性能存在较为严重的性能问题。由于前期能够拿到的数据十分有限,因此在会上我们重点分析了nmon数据和AWR报告。

   

连载-从一个项目看系统优化工程(2)

                       

nmon的数据上看,系统的负载并不高。CPU使用率不超过40%IOPS不超过700

连载-从一个项目看系统优化工程(2)

IO吞吐量上看,也基本上没有超过40M/秒,主要的业务高峰集中在每天的830-12001400-1730这段时间,和用户的上班时间基本上是吻合的。

在内存方面也比较平稳,使用率在52%左右。不存在较为严重的波动情况,而且物理资源的空闲比例也很高。这为今后加大SGA等操作提供了基础。

网络IO方面的情况也十分类似,高峰期和CPU高峰基本上吻合,而且没有什么明显网络负载过高的情况。

TOP数据看,主要的大开销进程都是Oracle的进程,因此也可以排除其他业务对Oracle数据库的影响。

从数据库服务器操作系统监控数据上看不出有太大的问题。从AWR报告上看,系统的负载并不太高,每秒2790次的执行,19.87个事务,逻辑读才不到14万每秒,物理读5855,大约每秒47M,和NMON看到的情况类似。

从命中率上看,LIBRARY HIT问题比较严重,命中率只有88.16%,软解析的比例只有63%%NON-PARSE CPU不到95%,从这些现象看,本系统的共享池的性能不佳。

TOP EVENT看,各种等待数量并不多,而且平均等待时间也都比较正常,系统的全表扫描有点多,不过并未看出全表扫描对系统性能有较大的影响。

WAIT CLASS上看,USER/IO占据第一位,不过平均等待和总等待都不算太高。从这里面确实看不出这套系统有什么大问题问题。

通过对数据库服务器的分析,大家一致认为,数据库服务器的硬件资源不存在任何瓶颈,总体负载较低,同时共享池存在一定的性能问题,但是这些问题都不是特别致命的问题。应该不是该系统出现如此严重的性能问题的关键。看样子具体的问题定位必须到现场去深入分析才行了。

于是大家转向对WEBLOGIC的分析。从前期人员采集的日志情况看,WEBLOGIC服务器部署在IBM小型机上,操作系统是AIX 6.1 TL03,这些服务器是IBM P系列高端小型机上的分区,每个分区配置4CPU16G内存。6台服务器上,每个部署2WEBLOGIC实例,版本是9.2.3

WEBLOGIC的日志上看,存在大量的执行存储过程的ORA-0612报错和执行SQL时的ORA-04030报错。从这些情况来看,由于存在大量的WELBOIC执行报错,肯定有很多应用模块经常出错,这方面在做使用单位调研的时候需要进一步确认。

摸底分析会结束了,大家都认为本系统存在特别严重的问题,但是问题严重到何种程度,主要集中在哪些方面,解决这个系统性能问题的关键点还是一头雾水。这也是这些年来我们摸底分析会后最不托底的一次。看样子后面的优化工作将会面临巨大的困难。

连载-从一个项目看系统优化工程(2)》来自互联网,仅为收藏学习,如侵权请联系删除。本文URL:http://www.hashtobe.com/145.html