HP-UX中Java应用性能调优概述.doc

  1. 1、本文档共39页,可阅读全部内容。
  2. 2、原创力文档(book118)网站文档一经付费(服务费),不意味着购买了该文档的版权,仅供个人/单位学习、研究之用,不得用于商业用途,未经授权,严禁复制、发行、汇编、翻译或者网络传播等,侵权必究。
  3. 3、本站所有内容均由合作方或网友上传,本站不对文档的完整性、权威性及其观点立场正确性做任何保证或承诺!文档内容仅供研究参考,付费前请自行鉴别。如您付费,意味着您自己接受本站规则且自行承担风险,本站不退款、不进行额外附加服务;查看《如何避免下载的几个坑》。如果您已付费下载过本站文档,您可以点击 这里二次下载
  4. 4、如文档侵犯商业秘密、侵犯著作权、侵犯人身权等,请点击“版权申诉”(推荐),也可以打举报电话:400-050-0827(电话支持时间:9:00-18:30)。
查看更多
HP-UX中的Java应用性能调优概述HP-UX中的Java应用性能调优简介 本指南旨在为读者提供一系列有用的方法来排除与Java相关的性能问题,并帮助在HP-UX系统中进行Java应用的性能调优。本文并没有详细地讨论这一课题,只是为该领域的工作进行了概述。参考资料部分提到了几本关于Java性能调优相关的书籍和参考文章,可以参阅它们来了解更多详细信息。本文的内容与包含HotSpot Runtime编译器版本1.3.1的Java Software Developer Kit(SDK)1.3.1及以后版本保持一致。文中讨论的许多主题,在下面的网站有更加详细的分析 /dspp(搜索“Java Performance Tuning on HP-UX”) 或直接访问 /dspp/tech/tech_TechDocumentDetailPage_IDX/1,,1602!0!,00.html 在许多报告有性能问题的情况中,对垃圾回收行为的调查表明JVM运行的heap配置存在问题。在其它情况中,也可能是应用的线程锁定或内存溢出引起了该问题。我们建议初学者采用以下方法的结合来解决JAVA应用性能的问题:使用Glance/gpm工具来找出瓶颈所在分析–Xverbosegc(来自垃圾回收器的详细报告)JVM选项的输出结果;使用Hpjmeter工具分析–Xeprof(扩展的简档描述)JVM选项的输出结果;浏览kill –3 pid命令的几个输出结果它们将提供有用的数据,可以帮助您对碰到的问题进行彻底的初始分析。本文将会对这些领域进行深入的分析。以上所述四种方法,以及对硬件设置、操作系统和JVM版本及选项的详细描述,是性能工程师着手解决问题时最初的一些步骤。Glance/gpm是一个HP的工具,在HP-UX Application Software光盘的软件包中。它也可以用于其它操作系统,例如Solaris和AIX。其它工具,如“top”、“vmstat”、“netstat”和“sar”也提供了类似的性能信息。这些均被记录在Sauers和Weygant [Sauers]所著的《HP-UX性能调优》一书中。鉴于本文的目的,我们将侧重于介绍使用Glance/gpm进行系统和进程层的监视。采用系统化的方法Java性能分析中存在许多的不确定因素。HP-UX内核参数、在运行时指定的JVM选项以及应用设计等所有一切都会带来相应的影响。正是由于该原因,所以在分析性能问题时应采取从上至下系统化的方法(从最外层的系统角度)并在首次分析时考虑所有的可能性,这一点非常重要。采取从上至下的方法,我们首先将系统作为一个整体来考虑(将一台或多台协作的计算机作为一个集合,它们互相之间具有网络影响,可能在某些点还存在数据库访问影响)。在考虑了整个系统中所有的可变因素之后,我们将分析范围缩小到单个计算机,再进一步缩小到该计算机中的单个进程,从而找出问题的根本原因。之所以采用从上之下的分析方法,是因为导致性能问题的原因可能存在于程序、计算机、数据源和网络等构成整个系统的各个部分。有多种工具可以帮助我们逐一分析每台计算机,HP-UX Glance/gpm便是其中最强大的工具之一,本文后面的部分会再次提到该工具。过去,研发实验室进行的分析工作发现性能瓶颈的原因也可能源于非Java的技术。性能工程师必须时刻考虑到这一点。系统中各台计算机之间以及计算机与其外部数据源之间的数据交换也必须进行检查。这项工作可以通过使用“netstat”等网络与数据库监视工具来完成。推荐流程中的步骤包括:评估整体的系统配置、吞吐量和负载情况;测量性能(使用我们将进一步详细介绍的工具);分析来自性能测量工具的数据;确定一个或多个可能的瓶颈;每次仅更改或调节一个项目;再次测量性能以检查该调节步骤所带来的变化。在本文以后的章节我们将会更加详细地分析这些步骤。在分析过程中考虑来自多个工具的数据并反复核对其输出结果也非常重要。例如,Glance/gpm生成的线程信息应该与将“kill –3 pid”命令应用于JVM进程时所看到的线程数据一致。较高的吞吐量水平并非总是性能问题的原因所在。许多生产系统在运行时都一直保持高容量的交易流。性能工程师所要面对的真正问题是“进程中的瓶颈在哪里,并且它们如何被触发?”为了找出这些瓶颈,有时候需要为系统添加负载,再现峰值用户处理水平时的负载,这时候系统将非常繁忙。有多种工具可以在基于Web的应用上实现这种高负载,它们将在本文最后的工具章节中介绍。避免在信息不充分的情况下妄加猜测不经过分析和测量便对问题原因作出最初的猜测非常具有诱惑力,特别是在项目小组承受着压力要解决一个问题时。这种情况应该避免。通常情况下,我们所作的猜测会造成误导。相反,我们建议先使用各种工具(Glance/gpm、Hpjm

文档评论(0)

ygxt89 + 关注
实名认证
内容提供者

该用户很懒,什么也没介绍

1亿VIP精品文档

相关文档