使用IBM性能分析工具解决生产环境中的性能问题 - 编程入门网
| 旧出现，于是通过客户和公司的协调，请来几位专家，包括操作系统专家、数据库专家，大部分的专家在巡检之后，给出的结论是：大部分需要调整的参数都已经调整过了，还是要从应用系统本身找原因，看来还是要靠我们自己来解决了。（最终的结果也证明，如此诡异隐蔽的 OOM 问题是很难一眼就能发现的，工具的作用不可忽视。）
我们通过对底层封装的框架代码，主要是 DAO 层与数据库交互的统一接口，增加了 log 处理以抓取所有执行时间超过 10 秒钟的 SQL 语句，记录到应用系统日志中备查。同时通过数据库监控辅助工具给出的建议，对所有超标的 SQL 通过建立 index，或者修正数据结构（主要是通过建立冗余字段来避免多表关联查询）来进行优化。这样过了几天后，已经基本上不存在执行时间超过 10 秒的 SQL 语句，可以说我们对应用层的优化已经达标了。 但是，宕机的问题并没有彻底解决，陆续发生了几次，通过短暂的控制台监控，发现都有线程等待的现象发生，还有两三次产生了几个 G 大小的 heapdump 文件，同时伴随有 javacore 文件产生。因为每次宕机的时候都需要紧急处理，不允许长时间监控，只能保留应用服务器日志和产生的 heapdump 文件，做进一步的研究。通过日志检查，我们发现几次宕机时都发生在相同的某两个业务点上，但是多次对处理该业务功能的代码进行检查分析，仍旧没有找到原因。看来只能寄希望于宕机产生的 heapdump 和 javacore 了，于是开始重点对 OOM 产生的这些文件进行分析。 使用IBM性能分析工具解决生产环境中的性能问题(2)时间:2012-03-17 IBM 张永峰IBM 分析工具的使用 这里，我们简单介绍一下 heapdump 文件和 javacore 文件。heapdump 文件是一种镜像文件，是指定时刻的 Java 堆栈的快照。应用程序在发生内存泄露的错误时，往往会生成 heapdump 文件，同时伴随有 javacore 文件生成，javacore 包含 JVM 和应用程序相关的在特定时刻的一些诊断信息，如操作系统，内存，应用程序环境，线程等的信息。如本文案例中分析的下图中的 heapdump.20090602.134015.430370.phd 和 javacore.20090602.134015.430370.txt。 由于笔者之前并没有这方面的分析经验，觉得 heapdump 文件很大，就想当然拿它开刀了。首先是寻找工具，类似的工具有多种，笔者最后选择了 IBM 的 HeapAnalyzer（http://www.alphaworks.ibm.com/tech/heapanalyzer）。通过对 heapdump 文件的解析，HeapAnalyzer 可以分析出哪些对象占用了太多的堆栈空间，从而发现导致内存泄露或者可能引起内存泄露的对象。它的使用很简单，可以从它的 readme 文档中找到，这里我们简单举个例子如下： #/usr/java50/bin/java – Xmx2000m – jar ha36.jar heapdump.20090602.134015.430370.phd 通常我们需要使用较大的 heapsize 来启动 HeapAnalyzer，因为通过 HeapAnalyzer 打开过大的 heapdump 文件时，也可能会因为 heapsize 不够而产生 OOM 的错误。开始的时候，笔者从服务器上将 heapdump 文件通过 ftp 下载下来，然后试图通过本机 window 环境进行分析。笔者使用的电脑是 2G 内存，启动 HeapAnalyzer 时指定的是 1536 M，但是几次都是到 90% 多的时候进度条就停止前进了。迫不得已同时也是为了能达到环境一致的效果，笔者将 HeapAnalyzer 上传到生产环境，直接在生产环境下打开 heapdump 文件。
使用IBM性能分析工具解决生产环境中的性能问题(3)时间:2012-03-17 IBM 张永峰个人感觉 HeapAnalyzer 给出的分析结果可读性不强，而且不能准确定位问题，从分析结果看大致是因为加载的对象过多，但是是哪个模块导致的问题就跟踪不到了。笔者开始寻找 HeapAnalyzer 分析结果相关的资料，试图从这个可读性不强的结果 |
凌众科技专业提供服务器租用、服务器托管、企业邮局、虚拟主机等服务，公司网站：http://www.lingzhong.cn 为了给广大客户了解更多的技术信息，本技术文章收集来源于网络,凌众科技尊重文章作者的版权，如果有涉及你的版权有必要删除你的文章，请和我们联系。以上信息与文章正文是不可分割的一部分,如果您要转载本文章,请保留以上信息，谢谢! |
