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

运维单位调研

除了业务部门调研和开发商调研之外,还有一个十分重要的调研运维调研。实际上,在大多数优化项目中,运维调研是最重要的环节,因为大多数优化需求都会汇总到运维部门。不过这个项目有些特殊,大多数业务部门的需求是交给开发商在本地的运维团队的,只有少数和IT基础设施有关的服务请求交给了运维部门。这种模式在很多IT运维还没有集中的企事业单位中普遍存在。甚至在金融机构、运营商等IT运维管理十分成熟的企业中,应用运维还没有集中,大多数应用软件系统还采用谁开发谁运维的模式。在政府、医疗等行业中,甚至存在很多系统的IT基础设施都由开发商运维的情况。

在本项目中,客户采用的是IT基础设施统一运维,应用软件由开发商运维的方式。网络、存储、数据库、中间件分别按照专业设置运维岗位,就像铁路警察一样,各管一段。在由于这种运维模式很难对每个系统都有深入的覆盖,因此开发商也安排了DBA与中间件管理员,处理日常一些客户IT部门覆盖不够全面的业务。

在运维单位调研时,我们拿到了整个财务系统的“运行方式”。“运行方式”是一套系统运行的完整的资料,包括部署架构、设备资产表、日常运维作业规范等内容,对于做系统优化来说十分有价值。通过运行方式我们了解到了这个系统的应用服务器集群由六台IBM 7998-61X刀片组成,每个刀片配备4CPU16G内存,操作系统是AIX 6.1,上面运行两个WEBLOGIC 9.2.3.0的实例,共有12个应用服务器实例。

       

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

                   

数据库服务器由两台IBM P750组成,每台服务器都是半配的,配有有16CPU128G内存,操作系统是AIX 5.3 TL08

运维部门反馈这套系统最为不稳定的是WEBLOGIC中间件和数据库,存储是财务部独立采购的存储,并没有和其他系统共用存储,而且存储的配置较高,不存在明显的性能问题。中间件方面出现问题主要反映在实例宕机、有时候GC十分慢,导致大量的会话积压,特别是月底高峰期的时候,基本上每个月都会出现应用服务器宕机的问题。运维部门认为这主要是开发商的应用写的太烂,已经多次提出让开发商优化应用,不过效果不佳。

优化项目组对于JVM设置为2G表示不理解,每个刀片有16G内存,只跑两个WLS实例,而且JVM经常出现OOM现象,GC也十分慢,为什么不加大JVM的大小呢。运维部门指着运行方式中的一个配置项说“WEBLOGIC32位的,我们已经调到最大了,调的再大会出现操作系统内存溢出”。这个信息把问题串了起来,以前我们对应用服务器为什么会出现OOM IN NATIVE CODE感到疑惑。因为一般的JVM内存溢出是OOM,而NATIVE CODE是操作系统出现内存溢出。由于32位应用的内存寻址问题,单进程最多可寻址的内存是4GB,除掉堆栈等公共资源,如果再分配超过2GBJVM,那确实很容易出现内存溢出了。而AIX操作系统中也存在BUG,当32位应用使用的物理内存接近4GB的时候,会出现进程异常中断的可能。

对于数据库,运维部门反馈的问题就更多了。这套系统的数据库是一套两节点的RAC系统,数据库版本是10.2.0.4,从日常运维的情况看,系统出问题主要还不是系统资源不足的问题,这套系统的数据库服务器的CPU使用率往往都在20%左右。系统出现的大多数的较为严重的问题都和共享池有关。最为典型的是ORA-4031row cache lock等。在不久前还有一次较为严重的row cache lock引起的宕机。从日志上看

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

当时开发商的DBA团队分析认为这是由于oracle BUG导致,建议客户升级数据库到10.2.0.5

结合开发商和运维单位调研的结果,我们对系统的整体情况有了一个初步的了解,WEBLOGICOracle数据库的主要问题大体产生的原因也有了一个初步的判断。因为WEBLOGIC使用了32位版本,因此JVM无法设置的更大,导致目前JVM虽然有点不够用,但是又服务扩大JVM。那么我们后续的优化可以通过两条路线推进,一条是升级WEBLOGIC64位,解决内存瓶颈;另外一条是分析为什么2GJVM还不够用。两方面任何一方面有成果,都可以有效的解决大部分应用服务器的问题。

数据库方面由于开发商使用了VPD和临时表这种应用架构,共享池出现问题也十分正常,我们如果顺着这条线,能够解决共享池的问题,那么也可以大大改善系统的整体性能。

这个异常复杂的系统的优化工作,似乎又看到了一线希望。不过后续的工作依然十分艰巨,优化项目组的心仍然无法完全放下来。

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