Javaperformancetuning-gettingstarted资源-CSDN文库

需积分: 6 122 浏览量 2009-04-06 17:41:02 上传评论收藏 1.13MB PDF 举报

### Java性能调优入门 #### 引言本文档旨在为读者提供一系列有用的起步方法，以解决与Java相关的性能问题，并帮助用户针对HP-UX环境下的Java应用进行性能调优。文档并不涵盖所有细节，而是作为该领域的入门指南。对于更深入的信息，建议参考专门的书籍和其他参考资料。 #### 方法论在进行Java性能调优时，采用系统化的方法至关重要。避免盲目猜测问题所在，而是应该通过测试具有代表性的小型样本应用来逐步定位问题。同时，需要将整个系统作为一个整体来进行评估，确保所有可能影响性能的因素都被考虑在内。 #### 数据收集数据收集是性能调优的基础步骤。这包括但不限于CPU利用率、内存使用情况、磁盘I/O等关键指标。HP-UX提供了多种工具用于监控这些指标，如`vmstat`、`iostat`、`top`等。 #### HP-UX 内核参数 HP-UX中的内核参数对Java应用程序的性能有直接影响。例如，`shmall` 和 `shmmax` 参数可以用来调整共享内存的大小，这对于多线程应用尤其重要。`semmsl` 和 `semmns` 参数则影响信号量集的大小和数量。调整这些参数可以帮助优化Java应用的资源管理。 #### 垃圾回收 (GC) 垃圾回收是Java运行时环境(JRE)的重要组成部分，它负责管理堆内存中的对象生命周期。了解不同类型的垃圾回收器（如Serial、Parallel、CMS或G1）及其各自的优缺点，对于有效调优Java应用至关重要。例如，使用`-XX:+PrintGCDetails`选项可以获得详细的GC日志信息，帮助分析GC行为。 #### 堆内存中的空间堆内存分为不同的区域，如新生代（Eden Space和Survivor Spaces）和老年代（Tenured Generation）。合理配置这些区域的大小可以显著提高应用性能。例如，增加年轻代的大小可以减少年轻代垃圾回收的频率，从而降低应用的暂停时间。 #### 线程、锁和竞争 Java应用中的线程管理和同步机制也会影响性能。过度的锁竞争会导致线程频繁阻塞和上下文切换，从而降低性能。使用`kill -3 <pid>`命令可以获得当前进程的线程堆栈转储，以便分析线程状态和锁持有情况。此外，HP jMeter等工具可以帮助检测线程锁定问题。 #### 昂贵的方法调用频繁的方法调用会增加程序的执行时间，尤其是在涉及复杂计算或大量I/O操作的情况下。通过代码审查和性能测试，识别并优化这些方法调用可以显著提高性能。 #### 内存泄漏内存泄漏是指不再使用的对象仍然被引用，导致无法被垃圾回收器回收。内存泄漏会逐渐消耗系统资源，最终可能导致应用崩溃。使用内存分析工具（如VisualVM或Eclipse Memory Analyzer）可以帮助定位内存泄漏的位置。 #### 性能基准症状性能基准测试有助于识别应用的瓶颈。通过对应用进行基准测试，可以确定在特定负载下应用的表现，并根据结果进行相应的调优。常见的性能症状包括CPU使用率过高、响应时间延长等。 #### 结论 Java性能调优是一个复杂但必要的过程，它涉及到对应用的整体架构、资源管理以及具体代码实现的深入了解。通过采取系统化的方法、利用合适的工具和技术，开发者可以有效地识别并解决性能问题，从而提高应用的稳定性和用户体验。 #### 参考资料与工具 - **性能分析工具**：如VisualVM、Eclipse Memory Analyzer、HP jMeter等。 - **负载测试工具**：如JMeter、LoadRunner等。通过以上工具和技术的应用，开发者可以在HP-UX平台上高效地进行Java性能调优。

展开

资源推荐

资源详情

资源评论

performance tuning for

Java on hp-ux

getting started

Hewlett Packard Company,

September 25th, 2001

table of contents

INTRODUCTION ........................................................................................................................................ 3

USING A METHODICAL APPROACH................................................................................................... 4

AVOID MAKING AN UNINFORMED GUESS AT THE PROBLEM CAUSE ................................... 5

TESTING A SMALLER REPRESENTATIVE SAMPLE OF A BIG APPLICATION ....................... 5

ASSESSING THE SYSTEM AS A WHOLE............................................................................................. 6

DATA GATHERING................................................................................................................................... 7

HP-UX KERNEL PARAMETERS............................................................................................................. 8

GARBAGE COLLECTION...................................................................................................................... 11

SPACES WITHIN HEAP MEMORY ...................................................................................................... 15

THREADS, LOCKING AND CONTENTION........................................................................................ 20

GETTING A THREAD DATA DUMP USING KILL -3........................................................................ 24

USING THE HPJMETER TOOL TO DETECT THREAD LOCKING PROBLEMS....................... 26

A FINAL WORD ON THREADS............................................................................................................. 27

EXPENSIVE METHOD CALLS.............................................................................................................. 28

MEMORY LEAKS .................................................................................................................................... 30

BENCHMARKING SYMPTOMS............................................................................................................ 33

CONCLUSIONS......................................................................................................................................... 35

REFERENCES ........................................................................................................................................... 36

TOOLS.................................................................................................................................................. 36

Performance Analysis Tools................................................................................................................. 36

Load Testing Tools ............................................................................................................................... 36

The four actions described above, along with a full description of the hardware setup, operating

system and JVM version and options will be the first steps for the performance engineer who is

embarked on resolving a problem.

Glance/gpm is an HP add-on tool that is found in the Applications CD and in the Enterprise and

Mission-critical bundles for HP-UX. It is also available for other operating systems, such as Solaris

and AIX. Other tools, such as “top”, “vmstat”, “netstat” and “sar” provide similar performance

information. These are documented in the book entitled “HP-UX Performance Tuning” by Sauers

and Weygant [Sauers]. For the purposes of this paper, we will concentrate on using Glance/gpm for

system and process level monitoring.

using a methodical approach

There are many variables at play in Java performance analysis. Everything from the HP-UX kernel

parameters, to the options specified at runtime to the JVM, to the design of the application, has an

effect. For this reason, it is important to analyze a performance problem methodically from the top

down (from the outermost system view) and to consider all possibilities on the first approach. By a

top-down approach we mean consideration of the system as a whole first (as a collection of one or

more computers acting in concert, with networking effects between them and possibly database

access effects at certain points).

Having considered all variables in the entire system, we then drill down to a single computer and

further down to a single process within that computer as the culprit for the problem. The reason for

doing this top-down analysis is that the cause of a performance problem can lie anywhere in the

collection of programs, computers, data sources and networks that make up the full system. There

are tools to help us with analysis of each computer in turn – one of the most powerful is the HP-UX

tool Glance/gpm, which will be mentioned again later in this document.

In the past, analysis work done by the R & D lab found that the reason for performance bottlenecks

may occur in non-Java technology. The performance engineer must consider this at all times.

The interchanges of data between the computers in the system and between the computers and their

external data sources should be examined. This can be done using network and database monitoring

tools such as the “netstat” tool.

The steps in the recommended process are to:

• assess the overall system configuration, throughput and loading;

• measure the performance (using tools which we will give further details on);

• analyze data from performance measurement tools;

• identify one or more possible bottlenecks;

• change or tune one item at any one time;

• measure the performance again to detect changes resulting from that tuning step.

We go into some detail about these steps in further sections of this document. It is important also to

consider the data from more than one tool in the analysis process and to cross-check the output

between them. For example, the thread information produced by Glance/gpm should be consistent

with the thread data seen when a “kill –3 <pid>” is issued to the JVM process.

It is also very useful to identify a single “unit of work” or “user transaction” that has a completion

time and is easily measurable, in order to gauge progress in performance tuning. This might be the

number of transactions per second put through a collection of software.

High throughput levels are not always the source of a performance issue. Many production systems

run with a high volume of transactions flowing through them constantly. The real question for the

performance engineer is “Where are the bottlenecks in the process and how can they be acted on ?”

In order to find these bottlenecks, it is sometimes necessary to place a load on the system which

represents the type of loading at peak user levels, when the system will be very busy. There are tools

for achieving this high loading on web based applications, which are given in the Tools section at the

end.

avoid making an uninformed guess at the problem cause

It is very tempting, especially when a project team is under pressure to solve a problem, to make an

initial stab at the problem cause without analysis and measurement. This is to be avoided. More often

than not, the initial guess we make is misleading.

Instead, it is recommended that the performance data be collected from a variety of tools

(Glance/gpm, HPjmeter, HPjtune, sar, the JVM options –Xverbosegc and –Xeprof and others) and

once the data from these tools is analyzed and understood, then a reason can be given for the

symptoms seen. This analysis takes some time – and typically the first hours of the performance

engineer’s time is spent in gathering and analyzing this data before making a change to one of the

performance-influencing variables of the system.

It is very important to have a notebook or journal of some kind, into which all the changes one

makes are recorded as we carry them out with their resulting effect on performance. The

performance engineer will be tempted to make several changes at once to the system, a course of

action to be avoided. Keeping track of the changes applied in written form defends the engineer

against the confusion that can easily arise from multiple changes, multiple results and many outside

influencing factors.

testing a smaller representative sample of a big application

A standard troubleshooting technique in computer programming is to boil the problem down to the

smallest possible piece of code that exhibits the symptom. This is fraught with danger, however, in

performance analysis, as the small sample can frequently behave quite differently to the real

production system. It is recommended that as much as possible, do the performance analysis on the

剩余35页未读，继续阅读

评论收藏

内容反馈

#完美解决问题
#运行顺畅
#内容详尽
#全网独家
#注释完整

Jiutianhgnc

粉丝: 2
资源: 4

Java performance tuning - getting started

最新资源

Java performance tuning - getting started

getting-started-java:Java入门

Java版水果管理系统源码-getting-started-github-apps:入门-github-apps

java performance tuning

Java performance tunning guide

Java Performance Tuning

Java.EE.7.Performance.Tuning.and.Optimization.178217642X

Learning Neo4j 3.x, 2nd Edition-Packt Publishing(2017).epub

Apache Spark 2.x Cookbook_Cloud-ready recipes for analytics and data science

performance tuning

java performance java性能优化

Performance Tuning

Professional NoSQL 英文版 Shashank.Tiwari

Pro.React.14842126

最新资源