WebsphereJVM堆分析与优化.docVIP

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有较大不同，该工具会在装载文件的过程中进行智能分析，