调优背景
HBCZT信息中心使用IBM X服务器Windows运行其基于JEE技术的应用系统另外运行一个基于COM技术的数据采集应用程序该程序客户端读入用户填写的xls格式表格文件信息并通过该程序将XLS内容封装成为XML并打包ZIP后发送到数据采集程序的服务器端服务器端接受到文件后对该ZIP包进行解包并对解包后的XML信息进行解析使用SQL逐条将记录插入到Oracle数据库中数据库连接池已经设置为但批量数据插入数据库的时候（数据量至少条记录一般情况条记录）导致数据库异常缓慢客户希望找到系统瓶颈并提出相应性能调优建议
总体思路
硬件调优操作系统调优数据库调优 略！我们假设都已经是最佳状态由于本人负责WebLogic部分的调优所以以下思路与内容均为WebLogic方面特此说明
JEE应用架构环境下的系统调优首先我们一般会从应用程序出发去审核代码做到代码级的优化然后再调整应用服务器(BEA WebLogic)和数据库 (Oraclei)的参数最后当然是调整操作系统和网络的性能(包括硬件升级)这是一种MDA的先进做法诚然在这样一个政务项目中不可能完全按照这个思路来做我们把目标首先定位在应用系统所在的应用服务器(BEA WebLogic)上通过对BEA WebLogic的参数进行设置使WebLogic能够在最优化的环境中去运行其系统然后对ORACLE数据的参数进行优化设置最后进行性能测试再找出导致性能瓶颈所在的SQL代码或JAVA程序考量其修改的可行性并进行最终问题优先级认定与瓶颈模块进行协商解决性能问题当然一般情况下我见过的案例都是出现了性能问题后才想到调优而且一般都是先进行系统参数调整实在解决不了才会对代码进行检查实际上我们应当将代码级的调优放在应用设计时来做测试生产时修改代码将是一件极其痛苦的事情
下表为一般性JEE性能调优的参照情况一览表供参考
毛病
描述
症状
原因或治法
线性内存洩漏
每单位(每事务
每用户等)洩漏造成内存随着时间或负载线性增长
这会随着时间或负载增长降低系统性能
只有重启才有可能恢复
随着时间越来越慢
随着负载越来越慢虽然可能有多种外部原因但最典型的是与资源洩漏有关(例如每单位数据的链表存储或者没有回收的回收/增长缓沖区)指数方式内存洩漏
双倍增长策略的洩漏造成系统内存消耗表现为时间的指数曲线
随着时间越来越慢
随着负载越来越慢通常是由于向集合(VectorHashMap) 中加入永远不删除的元素造成的糟糕的编码无限循环
线程在 while(true) 语句以及类似的语句里阻塞
可以预见的锁定
您需要对循环进行大刀阔斧的删剪
资源洩漏
JDBC 语句
CICS 事务网关连接
以及类似的东西被洩漏了
造成对 Java 桥接层和后端系统的影响
随着时间越来越慢
可以预见的锁定
突然混乱通常情况下这是由于遗漏了 finally 块或者更简单点就是忘记用 close() 关闭代表外部资源的对象所造成的外部瓶颈问题
后端或者其他外部系统（如鑒权）越来越慢
同样减缓了 J
EE 应用服务器和应用程序
持续缓慢
随着负载越来越慢咨询专家（负责的第三方或者系统管理员）获取解决外部瓶颈问题的方法外部系统
J
EE 应用程序通过太大或太多的请求滥用后端系统
持续缓慢
随着负载越来越慢清除冗余的工作请求 成批处理相似的工作请求把大的请求分解成若干个更小的请求调整工作请求或后端系统(例如公共查询关键字的索引)等糟糕的编码CPU密集的组件
这是 J
EE 世界中常见的感冒
一些糟糕的代码或大量代码之间一次糟糕的交互
就挂起了 CPU
把吞吐速度减慢到爬行的速度
持续缓慢
随着负载越来越慢典型的解决方案就是数据高速缓存或者性能计数中间层问题
实现得很糟糕的桥接层(JDBC 驱动程序
到传统系统的 CORBA 连接)
由于对数据和请求不断的排列
解除排列
从而把所有通过它的流量减慢到爬行速度
这个毛病在早期阶段很容易与外部瓶颈混淆
持续缓慢
随着负载越来越慢检查桥接层和外部系统的版本兼容性如果有可能评估不同的桥接供应商如果重新规划架构有可能完全不需要桥接内部资源瓶颈过度使用或分配不足内部资源(线程放入池的对象)变得稀缺是在正确使用的情况下加大负载时出现过度使用还是因为洩漏？随着负载越来越慢
零星的挂起或异常错误分配不足根据预期的最大负载提高池的最大尺寸过度使用请参阅外部系统的过度使用不停止的重试这包括对失败请求连续的(或者在极端情况下无休止的)重试可以预见的锁定
突然混乱可能就是后端系统完全宕机在这里可用性监控会有帮助或者就是把尝试与成功分开线程阻塞点线程在过于积极的同步点上备份造成交通阻塞随着负载越来越慢
零星的挂起或异常错误
可以预见的锁定
突然混乱可能同步是不必要的(只要重新设计)或者比较外在的锁定策略(例如读/写锁)也许会有帮助线程死锁/活动锁最普遍这是您基本的获得顺序的问题突然混乱处理选项包括主锁确定的获得顺序以及银行家算法
调优建议
通过分析其配置我们发现JDBC连接池存在性能问题
在WebLogic中就大量使用了池:JDBC Connection PoolSocket PoolObject Pool和Thread PoolI/O操作中buffer是必须的特别是对大文件的操作不然容易造成内存溢出字节操作最快所以尽可能采用write(byte[])Buffered FileOutputStream比Buffered FileWriter要快因为FileWriter需要Unicode到Byte的转换JDBC建议使用buffer和cache为HttpServletResponse设置buffersize使用wlcache缓存在JNDI树上获取的对象等等
此外使用JDK 的非阻塞I/O对性能也有很大提高
JDBC代码调优最大的原则就是使用WebLogic的连接池而不是自己直连数据库在我接触的很多自己实现连接池的项目中大部分遇到死锁和连接洩漏的问题最后得不得修改代码而WebLogic提供了功能强大性能良好的数据库连接池我们要做的只是封装一个连接管理类从JNDI树上获取数据源并缓存得到连接并提供一系列关闭数据库资源的方法
对任何资源使用的原则是用完即关不管是数据库资源上下文环境还是文件数据库资源的洩漏极易造成内存洩漏乃至系统崩溃在使用完数据库资源后依次关闭ResultSetStatement和Connection而在一个数据库连接多次进行数据库操作时要特别注意ResultSet和Statement依次关闭
由于获取连接时默认自动提交方式使用connectionsetAutoCommit(false)关闭自动提交使用PreparedStatement批量更新业务复杂或者大数据量操作时使用存储过程尽量使用RowSet此外设置记录集读取缓存FetchSize和设置记录集读取方向FetchDirection对性能也有一定的提高
Servlet代码调优比较简单在Servlet之间跳转时forward比sendRedirect更有效设置HttpServletResponse 缓沖区如responsesetBufferSize();在init()方法里缓存静态数据而在destroy()中释放它建议在Servlet里使用ServletOutputStream输出图片等对象避免在Servlet和Jsp中定界事务等
JDBC Connection Pool的调优受制于WebLogic Server线程数的设置和数据库进程数游标的大小通常我们在一个线程中使用一个连接所以连接数并不是越多越好为避免两边的资源消耗建议设置连接池的最大值等于或者略小于线程数同时为了减少新建连接的开销将最小值和最大值设为一致增加Statement Cache Size对于大量使用PreparedStatement对象的应用程序很有帮助WebLogic能够为每一个连接缓存这些对象此值默认为在保证数据库游标大小足够的前提下可以根据需要提高Statement Cache Size比如当你设置连接数为Cache Size为时数据库可能需要打开*=个游标不幸的是当遇到与PreparedStatement Cache有关的应用程序错误时你需要将Cache Size设置为尽管JDBC Connection Pool提供了很多高级参数在开发模式下比较有用但大部分在生产环境下不需调整这里建议最好不要设置测试表 同时Test Reserved Connections和Test Released Connections也无需勾上 当然如果你的数据库不稳定时断时续你就可能需要上述的参数打开
最后分析一下JDBC驱动程序类型的选择Oracle提供thin驱动和oci驱动从性能上来讲oci驱动强于thin驱动特别是大数据量的操作但在简单的数据库操作中性能相差不大所以我建议对数据量至少条记录一般情况条记录的状况使用oci驱动
通过分析其日志并使用GC资源查看我们发现存在内存洩露的垃圾回收失败问题
垃圾收集(GC)是指JVM释放Java堆中不再使用的对象所占用的内存的过程而Java堆(Heap)是指Java应用程序对象生存的空间堆大小决定了GC的频度和时间堆越大GC频度低速度慢堆越小GC频度高速度快所以GC和堆大小是一组矛盾为了获取理想的Heap堆大小需要使用verbosegc参数(Sun jdk: Xloggc:)以打开详细的GC输出分析GC的频度和时间结合应用最大负载所需内存情况得出堆的大小通常情况下我们建议使用可用内存(除操作系统和其他应用程序占用之外的内存)%为避免堆大小调整引起的开销设置内存堆的最小值等于最大值即:Xms=Xmx而为了防止内存溢出建议在生产环境堆大小至少为M(Platform至少M)实际环境中M~G左右性能最佳G以上是不可取的在调整内存时可能需要调整核心参数进程的允许最大内存数对于sun和hp的jvm永久域太小(默认M)也可能造成内存溢出应增加参XX:MaxPermSize=m建议设置临时域Xmn的大小为Xmx的/~/ SurvivorRatio为
为了获得更好的性能建议在启动文件设置WebLogic为产品模式此时sun和hp jvm JIT引擎为server默认情况下打开JIT编译模式对性能也有帮助调整Chunk Size和Chunk Pool Size也可能对系统的吞吐量有提高此外还需关闭显示GC: XX:+DisableExplicitGC
建议Intel平台上使用jRockit（使用参数jrockit）无疑大大提高WebLogic性能本系统使用SUN JDK_jRockit支持四种垃圾收集器分代复制收集器单空间并发收集器分代并发收集器和并行收集器默认状态下JRockit使用分代并发收集器要改变收集器可使用Xgc:对应四个收集器分其他为gencopy singlecom gencon以及parallel为得到更好的响应性能应该使用并发垃圾回收器Xgc:gencon可使用Xms和Xmx设置堆栈的初始大小和最大值要设置护理域Xns为Xmx的%而如果要得到更好的性能应该选用并行垃圾回收器:Xgc: parallel由于并行垃圾回收器不使用nursery不必设置XnsjRockit 还提供了强大的图形化监控工具Jrockit Management Console可以查看GC性能问题
通过实时查看并分析操作系统与ORACLE系统中的I/O信息我们发现存在I/O读写占用资源率高且频繁问题
WebLogic Server有两套套接字复用器Java版和本地库采用小型本地库更有效尽量激活Enable Native IO(默认)此时UNIX默认使用CPUs+个线程Window下为双倍CPU如果系统不能加载本地库将会抛出一个异常javalangUnsatisfiedLinkException此时只能使用Java套接字复用器可以调整socket readers 百分比默认为%该参数可以在Console Server Tuning Configuration配置栏里设置
