Java EE应用在Glassfish下的性能调优案例分析

Java EE应用在Glassfish上的性能调优案例分析

核心提示：Java EE应用的性能问题对严肃的项目和产品来说是一个非常重要的问题。特别是企业级的应用，并发用户多，数据传输量大，业务逻辑复杂，占用系统资源多，因此性能问题在企业级应用变得至关重要，它和系统的稳定性有着直接的联系。

 

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％的提升。