was的性能优化

Websphere性能分析与优化

——从Heapdump浅谈JVM堆设置

不同版本的JDK可以设置的JVM堆大小是不一样的，而JVM堆的大小直接制约系统的性能，合理设置每个应用服务器中的JVM堆，在系统性能优化中是十分关键的一步。

一般来说，JVM堆可设置的大小受其版本限制，可分为以下两大类：

1、32位的JDK，JVM堆最大可设置到1.5G左右

2、64位的JDK，JVM堆大小暂无限制

那我们该如何调整JVM的堆大小呢？在Was上如何去设定一个合理的值且多大的值才算是合理的呢？

首先我们来了解下JVM堆大小对系统有哪些主要的影响，在JVM堆不足的情况下将会导致系统：

1、频繁的垃圾回收（引发系统资源紧张情况，集群环境下CPU资源消耗就更严重）

2、OOM，内存溢出（out of memory）

系统繁忙时，一般都是在处理大量的客户端请求，或是在进行多个复杂的计算，它们都需要向JVM堆申请空间进行对象的创建。在堆空间不足的情况下，应用系统会出现以下一些情况，从而大大降低客户的感知度：

1、请求操作响应时间长

2、请求操作失败，资源等待操作，内存溢出

为了保证系统的性能，提高系统稳定性，我们就需要对JVM堆的详细使用情况刨根问底，以此估出一个合理的值来设置JVM堆大小。

有专家给出建议，Was每个Server的线程池不宜配置过大，一般建议值在50-120之间，而JVM堆则设置在2G内。这个建议针对大部分系统都是适用的，如果在这个配置上系统运行还出现性能问题，可先从应用程序角度着手优化。因为无论线程池的线程大小是多少，每个线程给系统带来的主要压力就是JVM堆资源的占用。

在32位的Java虚拟机上，JVM堆最大可设置到1.5G左右。假设请求从客户端来到Was，Was从线程池中分配一个线程处理这个请求，同时从JVM堆空间申请相应的资源进行操作。假设这是一个上传5MB的Excel的线程，那么在上传与处理这个Excel过程中，线程占用的JVM堆的资源会越来越多，甚至有可能需要向JVM堆申请超过30MB的空间（当然30MB的堆空间不是绝对，这与代码设计密切相关，如果到Excel上传过程中，还要进行分析，封装，持久化等操作）。这种情况下，再有50个类似的上传Excel的线程，系统性能就会受到影响，因为在线程操作结束前，JVM堆资源被大量占用且无法快速释放，系统剩余可分配的JVM堆空间越来越少，如再有其它线程继续申请堆空间资源的话，就需要等待垃圾回收或者资源空间的创建了。

因此为了保证系统的性能，我们首先要保证JVM堆剩余可分配空间的大小。除了加大JVM堆的设置外（可考虑集群方式降低单Server的压力），我们还要从系统设计与应用程序代码优化入手，避免资源相互占用，资源调用后可快速释放。

应如何优化应用代码呢？在实际项目中，许多应用系统的工期都十分紧张，从需求调研到系统上线，可能仅有个把月的时间。由于复杂的业务逻辑和紧张的工作期限，在编码过程中难免都会出现一些漏洞，这些漏洞问题可能因为功能交叉关联，过于复杂，在测试阶段不能重现，直到投入生产使用中才发现，并且随着系统功能不断增加，关联越来越多，有些问题会成为影响性能的根源，让我们猝不及防！因此我们需要增加数据监控这一过程，其中可以通过Heapdump文件收集生产上每个Server的JVM堆中对象空间详细分配情况作为参考，进行代码优化与堆大小设置。

Heapdump文件主要用于记录JVM堆对象的详细信息，在JVM堆接收到转储命令时产生，其相当于JVM堆某一时间切面的详细信息，也可理解为记录对象在

JVM中详细痕迹的一个日志。通过分析Heapdump文件，我们可了解到各个对象的大小，及对象之间的关联关系等。

Heapdump文件一般比较大，文本查看工具已不能满足我们的要求，为了迅速从文件中找占用资源最多的对象，我们需要借助一些专业的工具来进行分析。如：

1、IBM HeapAnalyzer

该软件采用树形方式描述JVM堆，目前已出到V4.08版本。分析过程需要一层层展开查阅，寻找到资源消耗最大的关键对象。

通过该工具，我们可以详细了解到对象之间的关系，根据关系推断资源消耗大的对象主要存储了哪些内容，由哪些关键类去触发。

在左图中我们看到庞大的堆栈树，若一层层展开查阅与分析，很容易就看到眼冒金星。因此我们需要使用一些小功能去帮助分析整个堆载信息，如：

（1）Go to the largest drop in the subtrees （使用该功能，可快速查询到堆栈树下最大的可疑对象，然后逐层向上分析）

（2）List same type（查看相同类型的对象，在死循环情况下，可以快速定位问题）

2、MDD4J工具

同样是分析内存堆使用情况的工具，但较HeapAnalyzer有较大不同，该工具会在装载文件的过程中进行智能分析，然后给出相应的建议，缩小我们的分析范围。

如：可疑内存对象视图、类型视图、实例视图、树形视图等。

简易分析方法：

（1）先通过可疑内存对象视图，了解到究竟哪些对象存在泄露的可能性

（2）再通过树形视图详细分析每个可疑泄露对象，展开每一层节点，分析是否存在内存泄露的可能性。一般来说，我们都是根据经验查找非JDK，或者IBM 对象的对象，而直接查找项目或项目使用到的组件的对象进行分析，查看其关系。

以上两种工具都可以从IBM的官方网站下载，也可以安装ISA（IBM Support Assistant Workbench ）分析工具，快速搜索最新版本下载。如：

无论是哪个工具，通过其提供的信息，我们可认识到JVM堆中的内容就是一棵庞大的堆栈树，我们可先排除Was中间件的问题，从项目代码或者使用到的组件代码进行分析，搜索可疑泄漏对象，一步步详细分析下去，关键步骤就是要找到以下一些重要对象：