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

核心提示： 外部命令问题 数字校园应用运行在4CPU的Solaris10服务器上，中间件为JavaEE服务器，JavaEE应用程序在Glassfish上的性能调优案例分析(3)，系统在做大并发压力测试的时候，请求响应时间比较慢，下面的参数是在Sun的HOTSPOT中调整大尺寸（4M）页面的设置：-XX:+A

外部命令问题

数字校园应用运行在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％的提升。