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