paulwong

JavaEE应用程序在Glassfish上的性能调优案例分析

JavaEE应用程序在Glassfish上的性能调优案例分析 Java EE应用的性能问题对严肃的项目和产品来说是一个非常重要的问题。特别是企业级的应用,并发用户多,数据传输量大,业务逻辑复杂,占用系统资源多,因此性能问题在企业级应用变得至关重要,它和系统的稳定性有着直接的联系。更加重要的是,性能好的应用在完成相同任务的条件下,能够占用更少的资源,获得更好的用户体验,换句话说,就是能够节省费用和消耗,获得更高的利润。

要获得更好的性能,就需要对原来的系统进行性能调优。对运行在Glassfish上的JavaEE应用,调优是一件相对复杂的事情。在调优以前必须要认识到:对JavaEE的系统,调优是多层次的。一个JavaEE的应用其实是整个系统中很少的一部分。开发人员所开发的JavaEE程序,无论是JSP还是 EJB,都是运行在JavaEE应用服务器(Glassfish)之上。而应用服务器本身也是Java语言编写的,需要运行在Java虚拟机之上。 Java虚拟机也只不过是操作系统的一个应用而已,和其他的应用(如Apache)对于操作系统来说没有本质的区别。而操作系统却运行在一定的硬件环境中,包括CPU,内存,网卡和硬盘等等。在这么多的层次中,每一个层次的因素都会影响整个系统的性能。因此,对一个系统的调优,事实上需要同时对每个层次都要调优。JavaEE应用性能调优不仅仅和Glassfish有关,Java语言有关,还要和操作系统以及硬件都有关系,需要调优者有综合的知识和技能。这些不同层面的方法需要综合纵效,结合在一起灵活使用,才能快速有效的定位性能瓶颈。下面是一些具体的案例分析:


内存泄漏问题

        某个JavaEE应用运行在8颗CPU的服务器上。上线运行发现性能不稳定。性能随着时间的增加而越来越慢。通过操作系统的工具(mpstat),发现在系统很慢的时候,只有一颗CPU很忙,其他的CPU都很空闲。因此怀疑是Java虚拟机经常进行内存回收,因为虚拟机在内存回收的时候,有的回收算法通常只能运行在一个CPU上。通过Java虚拟机的工具“jstat”可以清楚的看到,Java虚拟机进行内存回收的频率非常高,几乎每5秒中就有一次,每次回收的时间为2秒钟。另外,通过“jstat”的输出还发现每次回收释放的内存非常有限,大多数对象都无法回收。这种现象很大程度上暗示着内存泄漏。使用 Java虚拟机的工具“jmap”来获得当前的一个内存映象。发现有很多(超过10000)个的session对象。这是不正常的一个现象。一般来说, session对应于一个用户的多次访问,当用户退出的时候,session就应该失效,对象应该被回收。当我们和这个系统的开发工程师了解有关 session的设置,发现当他们部署应用的时候,竟然将session的timeout时间设置为50分钟,并且没有提供logout的接口。这样的设置下,每个session的数据都会保存50分钟才会被回收。根据我们的建议,系统提供了logout的链接,并且告诉用户如果退出应用,应该点击这个 logout的链接;并且将session的timeout时间修改为5分钟。通过几天的测试,证明泄漏的问题得到解决。
 
数据库连接池问题

        某财务应用运行在JavaEE服务器上,后台连接Oracle数据库。并发用户数量超过100人左右的时候系统停止响应。通过操作系统层面的进程监控工具发现进程并没有被杀死或挂起,而CPU使用率几乎为零。那么是什么原因导致系统停止响应用户请求呢?我们利用Java虚拟机的工具(kill -3 pid)将当前的所有线程状态DUMP出来,发现JavaEE服务器的大部分处理线程都在等待数据库连接池的连接,而那些已经获得数据库连接的线程却处于阻塞状态。数据库管理员应要求检查了数据库的状态,发现所有的连接的session都处于死锁状态。显然,这是因为数据库端出现了死锁的操作,阻塞了那些有数据库操作的请求,占用了所有数据库连接池中的连接。后续的请求如果还要从连接池中获取连接,就会阻塞在连接池上。当解决数据库死锁的问题之后,性能问题迎刃而解。
 
大对象缓存问题

        电信应用运行在64位Java虚拟机上,系统运行得很不稳定,系统经常停止响应。使用进程工具查看,发现进程并没有被杀死或挂起。利用Java虚拟机的工具发现系统在长时间的进行内存回收,内存回收的时间长达15分钟,整个系统在内存回收的时候就像挂起一样。另外还观察到系统使用了12G的内存(因为是 64位虚拟机所以突破了4G内存的限制)。从开发人员那里了解到,这个应用为了提高性能,大量使用了对象缓存,但是事与愿违,在Java中使用过多的内存,虽然在正常运行的时候能够获得很好的性能,但是会大大增加内存回收的时间。特别是对象缓存,本系统使用了8G的缓存空间,共缓存了6000多万个对象,对这些对象的遍历导致了长时间的内存回收。根据我们的建议,将缓存空间减少到1G,并调整回收算法(使用增量回收的算法),使得系统由于内存回收而造成的最大停顿时间减少到4秒,基本满足用户的需求。


外部命令问题

        数字校园应用运行在4CPU的Solaris10服务器上,中间件为JavaEE服务器。系统在做大并发压力测试的时候,请求响应时间比较慢,通过操作系统的工具(mpstat)发现CPU使用率比较高。并且系统占用绝大多数的CPU资源而不是应用本身。这是个不正常的现象,通常情况下用户应用的CPU占用率应该占主要地位,才能说明系统是正常工作。通过Solaris 10的Dtrace脚本,我们查看当前情况下哪些系统调用花费了最多的CPU资源,竟然发现最花费CPU的系统调用是“fork”。众所周知, “fork”系统调用是用来产生新的进程,在Java虚拟机中只有线程的概念,绝不会有进程的产生。这是个非常异常的现象。通过本系统的开发人员,我们找到了答案:每个用户请求的处理都包含执行一个外部shell脚本,来获得系统的一些信息。这是通过Java的“Runtime.getRuntime ().exec”来完成的,但是这种方法在Java中非常消耗资源。Java虚拟机执行这个命令的方式是:首先克隆一个和当前虚拟机一样的进程,再用这个新的进程去执行外部命令,最后再退出这个进程。如果频繁执行这个操作,系统的消耗会很大,不仅在CPU,内存操作也很重。用户根据建议去掉这个shell 脚本执行的语句,系统立刻回复了正常。


文件操作问题

        内容管理(CMS)系统运行在JavaEE服务器上,当系统长时间运行以后,性能非常差,用户请求的延时比系统刚上线的时候要大很多,并且用户的并发量很小,甚至是单个用户也很慢。通过操作系统的工具观察,一切都很正常,CPU利用率不高,IO也不是很大,内存很富余,网络几乎没有压力(因为并发用户少)。先不考虑线程互锁的问题,因为单个用户性能也不好。通过Java虚拟机观察也没有发现什么问题(内存回收很少发生)。这使得我们不得不使用代码跟踪器来全程跟踪代码。我们采用了Netbeans的Profiler,跟踪的结果非常意外,用户请求的90%的时间在创建新文件。从系统设计人员了解到,此系统使用了一个目录用于保存所有上传和共享的文件,文件用其命名方式来唯一区别于其他文件。我们查看了那个文件目录,发现该目录下已经拥有80万个文件了。这时候我们才定位到问题了:在同个目录下放置太多的文件,在创建新文件的时候,系统的开销是比较大的,例如为了防止重名,文件系统会遍历当前目录下所有的文件名等等。根据我们的建议,将文件分类保存在不同的目录下,性能有了大幅度的提高。

高速缓存命中率问题

        运行在JavaEE服务器上的ERP系统,在CPU充分利用的情况下性能仍然不太好。从操作系统层面上观察不到什么大问题,而且ERP系统过于复杂,代码跟踪比较困难。于是进行了CPU状态的进一步检查,发现CPU的TLB命中率不是很高,于是对Java虚拟机的启动参数进行了修改,强迫虚拟机使用大尺寸的内存页面,提高TLB的命中率。下面的参数是在Sun的HOTSPOT中调整大尺寸(4M)页面的设置:
-XX:+AggressiveHeap
-XX:LargePageSizeInBytes=256m
通过调整,TLB命中明显提高,性能也得到近40%的提升。

posted on 2009-08-29 00:33 paulwong 阅读(228) 评论(0)  编辑  收藏 所属分类: J2EE


只有注册用户登录后才能发表评论。


网站导航: