[计算机]中间件产品系统维护作业计划.doc

Oracle中间件产品系统维护手册中间件产品维护手册文档变更记录版本日期变更人备注1 每日监控内容：1.1 监控WebLogic Server实例性能指标WebLogic81的Admin Conole提供了一个server性能监控面板。在日常的系统维护监控中，可以通过该面板了解当前Server的工作状态，并根据具体情况采取必要的处理措施。使用方法为：登录admin console ，导航至yourDomain Servers yourServerName Monitoring Performance。如图15：图15. 监控WebLogic Server实例性能指标界面（8.1版本） 空闲线程数是当前server工作线程中处于空闲的线程数量； 吞吐量是单位时间完成的任务请求数，这个值的变化情况可以作为衡量server服务处理效率和压力的参考；同等情况下，吞吐量越高，说明server处理业务的效率越高。(需要了解的是这个请求数与业务请求并非一一对应；一个业务请求可能在wls内部产生多个任务请求)； 队列长度说明当前等待处理的任务请求数； 内存使用情况是当前JVM Heap 内存的使用情况。由于JVM 内存垃圾回收的活动，往往表现出程度不同，规律或不规律的锯齿变化。正常情况下 idle threads 0 ，queue Length为0，Throughput呈不规则变化曲线，Memory Usage呈适度频度的锯齿变化曲线。一般来说，对于正常配置的生产环境（线程数50200），如果idle threads 0 ，则 queue length =0 ；2) 反之，如果queue length0 ，则空闲线程数=0 ；在系统运行中，比较常见的是server响应慢的情况。此时，由中间件角度而言，我们首先需要确认空闲线程数与队列值。队列值可以直接看到，但空闲线程数可能需要刷新页面才能得到当前值，可以通过两者关系判断大致情况：如果Idle =0 ，说明此时server无空闲线程处理请求，队列中将会有请求排队；此时再看吞吐量变化情况:1) 吞吐量0 并且与正常运行情况下的变化趋势类似，说明当前请求压力超出系统并发能力，因此，如果cpu资源富余，增加线程数；如果cpu资源紧张，应考虑增加主机容量或添加其他主机，分担压力；2) 吞吐量=0 或者有较少的变化，说明目前线程的业务处理上一定程度上出现 了问题，一般是出现了挂起(server hang)；此时单纯增加线程数可能缓解状况，无法解决根本问题，此时需要采用其他手段来获取线程信息（unix下使用kill -3 来产生thread dump），并分析出故障的真正原因。如果Idle0，说明当前请求处理处理较慢，通常也需要获取线程信息(thread dump)来了解当前线程工作状态，如正在进行的业务操作等等，来作为改善应用实现的参考依据。内存使用曲线则反应了JVM Heap内存使用的变化情况，可以结合其他三个值的变化情况来判断server工作情况；比较理想的状态是适当频度的各种锯齿变化，由于JVM GC多采用“stop the world”机制，也就是垃圾回收时其他处理将暂停，过度频繁的GC将明显降低server工作效率和性能表现。如果发现内存曲线呈现大幅度、密集的锯齿，说明当前应用在内存使用上存在一定的问题，也不排除JVM GC本身出现故障，对于此时的问题应归类到内存故障，此处暂不做详细讨论。从WebLogic 9.0版本开始，缺省情况下在WebLogic Admin Console上不提供上述图形化的监控页面，如图16：图16. 监控WebLogic Server实例性能指标界面（9.x/10.x版本） 如果需要类似8.1版本中图形化的监控页面，请使用JVM的jconsole或者是WLFD Console Extention方式。1.2 监控Deployments及Service运行状态Deployment（部署件）及Service（服务）是Weblogic的重要资源。在weblogic console中对这些资源进行监控，也是诊断系统性能瓶颈的重要手段。1.2.1 监控Deployments部署件监控通常来说包括Web应用及EJB应用两部分。这两种部署件的监控方法为：登录admin console ，导航至yourDomain Deployments，选中欲监控的应用，然后在右侧面板切换至Monitoring标签。1.2.1.1 监控web应用图17. 监控web应用界面（8.1版本）图18. 监控web应用界面（8.1版本）图19. 监控web应用界面（9.x/10.x版本）图20. 监控web应用界面（9.x/10.x版本）如图17、18、19、20所示，我们可以在Monitoring标签页监控到web应用的当前会话数。并获得所有servlet及jsp的调用总数、平均执行时长等指标。1.2.1.2 监控ejb应用图21. 监控EJB应用界面（8.1版本）图22. 监控EJB应用界面（9.x/10.x版本）如图21、22，EJB 容器提供了大量的运行时统计信息，用于监控 EJB 应用程序。 WebLogic Server 管理控制台使用这些统计信息来计算特定的比率，然后用于调整池参数。 这其中，我们可以获取到以下关键指标：池失败率（Pool Miss Ratio），该数值按照（失败总数 / 访问总数） *100 进行计算。其结果说明了当无 bean 可用时，从池中获得一个 bean 所需发出请求的次数。Bean 销毁率（Destroyed Bean Ratio），该数值按照 （销毁总数 / 访问总数） *100 来 计算。当上述两个ratio较高时，则需要执行负载测试，通过监控 Beans In Use Current Count 参数查找峰值负载。调整 max-beans-in-free-pool 大小为负载测试期间该参数可以达到的最大值。空闲池中的 Bean 占用内存，因此在调整该参数的时候也应考虑内存的可用性。池超时率（Pool Timeout Ratio），该数值按照 （池超时总数 / 访问总数） *100 来计算。池超时率过高意味着池没有根据调用数量对ejb配置进行恰当调整。随着请求数量不断增加， EJB 容器创建更多的实例，直到其达到 maximum-beans-in-free-pool 值。如果所有的实例都处于活动状态，并且已经达到最大空闲池大小，则新的方法请求必须等待，直到实例返回到池中。对于这种情况，作为一种选择，可以考虑增大ejb部署描述符中的max-beans-in-free-pool 参数。1.2.2 监控ServicesService监控包含很多类型，此处我们以JDBC池监控及JMS资源监控为主进行讨论。1.2.2.1 监控JDBC池JDBC池的监控方法为：登录console ，导航至yourDomain Services JDBC Connection Pools，选中欲监控的JDBC池，然后在右侧面板切换至Monitoring标签。图23. 监控JDBC连接池界面（8.1版本）图24. 监控JDBC连接池界面（9.x/10.x版本）图23、24为JDBC池的监控表，黄色高亮部分为我们通常需要关注的池运行时参数，几个关键参数释义如下： ConnectionsNumber of physical database connections from this instance of the connection pool that are currently in use. Connections HighHighest number of active database connections in this instance of the connection pool since the connection pool was instantiated. Active connections are connections in use by an application. Curr CapacityCurrent number of database connections in this instance of the connection pool. The number includes available connections， connections in use by applications， and connections unavailable for testing.如果connections字段长期保持一个较高的值，甚至等于max capacity，则可能JDBC池生产压力较大，需要择机对池的设置进行调整。一个通常的调整原则为，设置JDBC池的max capacity略大于默认执行线程数，并等于initial capacity。1.2.2.2 监控JMSJMS监控主要包括JMS Server监控、destination监控等两部分。JMS的监控方法为：登录console ，导航至yourDomain Services JMS Servers，选中欲监控的JMS Server，然后在右侧面板切换至Monitoring标签。图25. 监控JMS Server界面（8.1版本）图26. 监控JMS Destination界面（8.1版本）图27. 监控JMS Server界面（9.x/10.x版本）对于JMS Server而言，需要重点监控Messages， Messages High和Messages Pending等数值。如果Messages Pending和Messages的数据过大，系统的响应速度会明显减小。关键运行参数释义如下： Consumers（Active Destinations） Current number of registered message consumers accessing the destination. Note: For a JMS topic that has a message-driven bean (MDB) listening on it， the number of consumers will always equal one. This is because each message to the topic is either processed by a single MDB or by multiple MDB instances in the pool that share the same consumer， which allows multiple messages to be processed in parallel. Consumers High Greatest number of registered message consumers accessing the destination since the last time the server was booted. Messages Current number of messages stored in the destination. This does not include pending bytes Messages High Greatest number of messages stored in the destination since the last time the server was booted. Messages Pending The number of messages that are stored in the system but which are not visible， and therefore cannot be received. Message visibility is affected by various delivery options including， but not limited to， transactions， message delivery and redelivery time， message expiration， and receipt without acknowledgement. Pending messages are over and above the current number of messages.1.3 WebLogic9.x/10.x中查看WTC连接情况图28. 监控WTC界面（9.x/10.x版本）图29. 监控WTC界面（9.x/10.x版本）如图28、29，在WebLogic 9.x/10.x的Admin Console中能监控WTC 连接情况；监控方法为：登录console ，导航至InteroperabilityWTC Servers ，显示图28；选中欲监控的WTC Server，然后在右侧面板切换至Control标签，显示同图29。2 每年检查内容：2.1 查看WebLogic配置以及JVM参数Weblogic domain的核心配置参数的查看方法有两种：(1) 直接查看域目录下的config.xml文件(2) 通过WebLogic Admin console查看。 JVM参数对weblogic运行期健壮性有着至关重要的影响，JVM参数的查看也有两种手段：(1) 查看weblogic启动脚本，该脚本一般位于域目录下(2) 通过命令行获取：ps -ef|grep java|grep -i weblogic，确认WebLogic进程所用的JDK及内存参数，并进一步通过java -version确认版本。如果通过GC日志或WebLogic Admin Console观察到WebLogic内存使用异常，则需要根据实际情况对内存参数进行调整，甚至需要通过压力测试来得到最优的内存参数设置值