资源管理系统应用优化方案

资源管理系统应用优化方案

作者：周安琳

来源：《科学与财富》2016年第01期

摘要：本文结合实际工程，详细介绍了C/S架构的系统使用群集负载机制存在性能问题时，可以采取的解决方案即F5负载均衡在实际工程中的应用。

关键词：C/S架构；群集； F5负载均衡

一. F5负载均衡

负载均衡，英文名称为Load Balance，其意思就是将负载（工作任务）进行平衡、分摊到多个操作单元上进行执行，例如Web服务器、FTP服务器、企业关键应用服务器和其它关键任务服务器等，从而共同完成工作任务。当某台SERVER设备发生故障，F5 将自动发现并不再把流量发送到这台故障的SERVER上，从而实现SERVER的高可用。

二.优化测试与方案实施中发现与解决的问题

第一阶段：调整Weblogic配置参数

资源管理系统出现异常时最大的特点为：单个SERVER异常时，影响其它SERVER上的在用用户与用户的登录操作。在前期过程中，一直致力于单SERVER的参数的调整与优化，以避免单个SERVER的异常，其中包括 -Xmx2048m（最大堆内存）、-Xp8196K（堆碎片）、-Xloratio0.3 （大对象区比率），经反复的调整优化测试，相应的参数能够使系统相对平稳安全运行，但因大业务使用的需求，系统异常情况并未得到有效解决。因此又对针对Weblogic 的Cluster集群机制进行了研究。

根据已有的资源系统C/S架构，客户端使用T3协议访问服务器上部署的应用，Cluster群集机制在8.1版本的使用上，存在性能问题，当群集中任何一个SERVER出现异常时，会导致整个系统运行缓慢。

为此，我们在测试环境进行了大量的测试，针对现有的资源管理系统客户端配置多个T3地址串的情况，测试发现异常SERVER及配置T3地址数量对用户登录耗时影响很大。以下是测试数据：

1.测试环境现状介绍：

测试环境为集群环境，两台主机，IP地址以192.168.1.1和192.168.1.2为例，每台主机部署3个应用服务，每个应用服务有自己的端口号

客户端单个T3地址样例：t3：// 192.168.1.1：9931

客户端T3地址串样例：t3：// 192.168.1.1：9931， 192.168.1.1：9932， 192.168.1.2：9922

2.测试用例

测试情况用例

2.1所有SERVER均正常，测试资源客户端配置SERVER由少到多对登录的影响

配1个T3地址时间： 4s 5s 6s

配2个T3地址时间：10s 9s 7s

配6个T3地址时间：20s 15s 22s

以上数据，除去网络环境等因素影响，证明客户端配置SERVER的数量，会影响用户的登录时长。客户端配的T3地址串中SERVER数量越多，客户端登录越耗时。

2.2测试资源客户端配T3地址串中有shutdown状态的SERVER对登录影响

配2个T3地址1开1停时间：12s

配3个T3地址2开1停时间：9s 18s 14s 14s

配4个T3地址2开2停时间：28s 28s 60s

配6个T3地址2开4停时间：55s 52s

除去网络环境因素影响，多SERVER配置中，状态异常的SERVER或者繁忙的SERVER 越多，登录耗时越长。也证明了客户端配置T3地址串后，会以某种机制询访T3串中的每个服务地址，异常SERVER对询访影响很大，但它位于T3串的前后位置对耗时几乎无任何影响。

针对上述的问题及规律，又进行了客户端询访机制的优化，客户端有一个参数控制程序对SERVER的询访时间：weblogic.jndi.requestTimeout ，默认时间为5s，这个时间压缩到1s。经测试该参数调整对上述两种场景的登录耗时有优化作用。

第二阶段：实现对F5负载均衡的支持

在经测试确定客户端进行随机分配并进入指定的SERVER的方案不可靠之后，经与F5设备厂家、Weblogic厂家多次沟通与测试，采用F5实现负载均衡的方案，实现基于T3协议的客户端与集群服务器之间的负载均衡。

首先通过现场研发8.1版本的Weblogic补丁，解除了F5负载均衡要求应用服务器上应用服务端口号和F5端口号一致的限制，在 F5侧配置客户端访问的T3协议地址，并建立该地址与资源12个SERVER服务间的映射关系。在功能上实现了现有环境对F5负载均衡的支持。

测试中发现，F5能将用户请求的数据流随机分配到某个SERVER上，通过该设备的这种机制实现了系统负载的均衡，在使用中，由于对Weblogic SERVER状态判断上有缺陷：只能发现SERVER宕掉，不能发现SERVER无响应，有时SERVER依然是Running状态，但是用户已经反映系统慢了，在这种情况下，系统整体性能会一直受影响。

第三阶段：实现了对Weblogic SERVER各种异常的发现

F5在运行过程中，需要轮询已在设备上配置的SERVER列表，有问题的SERVER会被踢出，再进行用户请求数据的分配时，只按踢出后的SERVER列表进行随机分配，实现系统的稳定安全运行，保证用户系统操作的有效性。

通过修改F5健康检查机制，同时能发现Weblogic SERVER宕掉和系统无响应两种情况。但是在Weblogic SERVER无响应的情况下，F5健康检查机制的发现时间较长，加上踢出SERVER列表中有问题的SERVER，时间在5分钟以上，这期间整个系统性能受影响，影响用户的使用。

第四阶段：把系统性能受影响时间控制在1分钟以内

优化F5对Weblogic SERVER的健康检查脚本，缩短F5设备对列表中异常SERVER的监控与处理时间。号线系统厂家针对异常SERVER的监控新开发了一个JSP页面，在F5上配置对该页面的调用，发现3次调用无响应，视为异常SERVER，F5设备会直接将其从列表踢除，这样实现了从发现到处置Weblogic SERVER异常的时间在1分钟以内。

第五阶段：应用程序端及其它方面进行的调整优化

分析以前系统异常情况，多是因内存溢出（OOM）或者大对象区空间不足GC忙于回收。号线系统厂家在尽可能不影响用户使用情况下，对此进行了代码层面与数据库查询SQL 方面的优化，减少频发的大对象。

开发用于监控各SERVER状态的JSP页面，在主机上配置TIMER，通访问调用此页面，发现异常SERVER，先执行kill -3 生成便于日后分析的Heapdump、Javacore文件，之后执行