没有合适的资源?快使用搜索试试~ 我知道了~
HP-UX中的Java应用性能调优概述.doc
1.该资源内容由用户上传,如若侵权请联系客服进行举报
2.虚拟产品一经售出概不退款(资源遇到问题,请及时私信上传者)
2.虚拟产品一经售出概不退款(资源遇到问题,请及时私信上传者)
版权申诉
0 下载量 109 浏览量
2022-06-09
11:05:39
上传
评论
收藏 679KB DOC 举报
温馨提示
试读
39页
HP-UX中的Java应用性能调优概述
资源推荐
资源详情
资源评论
HP-UX 中的 Java 应用性能调优概述
HP-UX 中的 Java 应用性能调优简介
本指南旨在为读者提供一系列有用的方法来排除与 相关的性能问题,并帮助在
系统中进行 应用的性能调优。
本文并没有详细地讨论这一课题,只是为该领域的工作进行了概述。参考资料部分提
到了几本关于 性能调优相关的书籍和参考文章,可以参阅它们来了解更多详细信息。
本文的内容与包含 编译器版本 的
() 及以后版本保持一致。
在许多报告有性能问题的情况中,对垃圾回收行为的调查表明 运行的 配置
存在问题。在其它情况中,也可能是应用的线程锁定或内存溢出引起了该问题。我们建议
初学者采用以下方法的结合来解决 应用性能的问题!
使用 "#$% 工具来找出瓶颈所在
分析–&'%#(来自垃圾回收器的详细报告) 选项的输出结果;
使用 ( 工具分析–(扩展的简档描述) 选项的输出结果;
浏览 )*+,-命令的几个输出结果
它们将提供有用的数据,可以帮助您对碰到的问题进行彻底的初始分析。本文将会对这些
领域进行深入的分析。
以上所述四种方法,以及对硬件设置、操作系统和 版本及选项的详细描述,是性
能工程师着手解决问题时最初的一些步骤。
"#$% 是一个 的工具,在 # 光盘的软件包中。
它 也 可 以 用 于 其 它 操 作 系 统 , 例 如 ' 和 . 。 其 它 工 具 , 如
“/、“'/、“'/和“'/也提供了类似的性能信息。这些均被记录在 '
和 01%2'3所著的《 性能调优》一书中。鉴于本文的目的,我们将侧重
于介绍使用 "#$% 进行系统和进程层的监视。
采用系统化的方法
性能分析中存在许多的不确定因素。 内核参数、在运行时指定的 选
项以及应用设计等所有一切都会带来相应的影响。正是由于该原因,所以在分析性能问题
时应采取从上至下系统化的方法(从最外层的系统角度)并在首次分析时考虑所有的可能
性,这一点非常重要。采取从上至下的方法,我们首先将系统作为一个整体来考虑(将一
台或多台协作的计算机作为一个集合,它们互相之间具有网络影响,可能在某些点还存在
数据库访问影响)。
在考虑了整个系统中所有的可变因素之后,我们将分析范围缩小到单个计算机,再进
一步缩小到该计算机中的单个进程,从而找出问题的根本原因。之所以采用从上之下的分
析方法,是因为导致性能问题的原因可能存在于程序、计算机、数据源和网络等构成整个
系统的各个部分。有多种工具可以帮助我们逐一分析每台计算机,"#$%
便是其中最强大的工具之一,本文后面的部分会再次提到该工具。
过去,研发实验室进行的分析工作发现性能瓶颈的原因也可能源于非 的技术。性
能工程师必须时刻考虑到这一点。系统中各台计算机之间以及计算机与其外部数据源之间
的数据交换也必须进行检查。这项工作可以通过使用“'/等网络与数据库监视工具来
完成。
推荐流程中的步骤包括:
评估整体的系统配置、吞吐量和负载情况;
测量性能(使用我们将进一步详细介绍的工具);
分析来自性能测量工具的数据;
确定一个或多个可能的瓶颈;
每次仅更改或调节一个项目;
再次测量性能以检查该调节步骤所带来的变化。
在本文以后的章节我们将会更加详细地分析这些步骤。在分析过程中考虑来自多个工
具的数据并反复核对其输出结果也非常重要。例如,"#$% 生成的线程信息应该与
将“)*+,-/命令应用于 进程时所看到的线程数据一致。
较高的吞吐量水平并非总是性能问题的原因所在。许多生产系统在运行时都一直保持
高容量的交易流。性能工程师所要面对的真正问题是“进程中的瓶颈在哪里,并且它们如何
被触发?”
为了找出这些瓶颈,有时候需要为系统添加负载,再现峰值用户处理水平时的负载,
这时候系统将非常繁忙。有多种工具可以在基于 0& 的应用上实现这种高负载,它们将
在本文最后的工具章节中介绍。
避免在信息不充分的情况下妄加猜测
不经过分析和测量便对问题原因作出最初的猜测非常具有诱惑力,特别是在项目小组
承受着压力要解决一个问题时。这种情况应该避免。通常情况下,我们所作的猜测会造成
误导。
相反,我们建议先使用各种工具( "#$%、(、(、'、–
&'%# 和– 的 选项等等)来收集性能数据,在这些工具的数据经过分析
并被了解之后,便可以就所见的症状给出原因了。该分析需要一定的时间,通常性能工程
师进行性能调优的第一步是先搜集系统运行数据,而不是上来就修改系统参数。
准备一个修改记录非常重要,用于记录所作出的每一个变更,以及应用变更后所带来
的性能影响。性能工程师非常容易对系统一次进行多个变更,这种情况应该避免。因为多
个变更、多种结果以及许多的外部影响因素很容易给工程师造成混乱,所以应该以书面的
形式将所应用的变更记录下来。
测试大型应用具有代表性的较小样本
计算机编程中的一个常用故障排除技巧是将问题尽可能分解到能够反映症状的最小代
码块。但是这种方法在性能分析中却非常危险,因为较小样本的行为通常与实际生产系统
有很大差别。建议尽可能在“真实的”系统上进行性能分析,而不是采用大型系统的子集。
这可能会占用测试的时间,但是所获得结果的将会更加准确。
在分析一个系统时,测量工具本身确实也会对性能产生影响。例如 "#$% 便是
系统中的一个进程,它会占用该机器的一部分 4 资源。我们所使用的工具已经
尽可能使这种影响将到最低。但我们在使用一个测量工具时,这种影响总是存在的。
将系统作为一个整体进行评估
当前许多基于 & 的体系结构可能采用一组计算机作为 & 服务器层,另一组计算
机作为应用服务器层以及一个数据库层。所有这些都通过网络连在一起,并互相作用以响
应每一个客户请求(例如通过浏览器发出的请求)。
进行整体系统评估的主要工具有 "#$%(图形进程监视)以及类似的工具(如
),它能够显示单个计算机中操作系统和进程的状态。"#$% 将就计
算机不同组件的状态为工程师提供一个可视、直观的评估,例如其 4 负载、输入输出负
载、网络流量,以及内存消耗率等。
在每台 计算机上使用 "#$% 工具使工程师能够清楚地看到参与整个系
统的所有机器中哪些负载紧张,哪些比较空闲。下图显示了 "#$% 窗口中最顶层的
计算机视图,我们可以看到该计算机的“系统时间”消耗水平非常高,而被使用的“用户时间”
水平非常低。这表明该计算机存在问题。实际上我们希望有更高的 4 消耗被用于“用户
时间”(用于执行应用的时间),而不是“系统时间”(用于执行操作系统功能的 4 时间)。
机器中出现这种非常高的“系统时间”占用率可能是由于操作系统调用,它们负责锁定
被称为“5'/的数据结构,占用很长的系统时间来解决争夺,或者等待访问这些结构
的线程被强制进入休眠状态。因此以下的情况可能是 程序中的线程锁争夺所引起的,
该话题将在本文以后的部分深入讨论。
到目前为止,我们已经知道太多的时间被用于执行系统代码,而不是应用代码。下一
步是检查机器中的哪一个特定进程造成了这种情况。
图 ! 中 "#$% 工具的主窗口
"# 主窗口 — 高系统时间举例
低用户 4 时间
高系统 4 时间
从整体系统视图缩小至单个计算机,再进一步缩小至特定的进程是使用 "#$%
工具以及其它 性能分析工具的一个练习。它们将在参考 2'3中详细描述。
剩余38页未读,继续阅读
资源评论
oligaga
- 粉丝: 52
- 资源: 2万+
上传资源 快速赚钱
- 我的内容管理 展开
- 我的资源 快来上传第一个资源
- 我的收益 登录查看自己的收益
- 我的积分 登录查看自己的积分
- 我的C币 登录后查看C币余额
- 我的收藏
- 我的下载
- 下载帮助
安全验证
文档复制为VIP权益,开通VIP直接复制
信息提交成功