Java性能调优实战：开源工具识别与解决常见问题

java

performance

需积分: 10 15 浏览量更新于2024-07-18 收藏 7.53MB PDF 举报

身份认证购VIP最低享 7 折!

30元优惠券

《解决Java性能问题：使用开源工具检测及对策》是由Erik Ostermueller撰写的一本实用指南，专为IT专业人士设计，旨在帮助他们在处理Java应用中普遍存在的性能瓶颈时提高效率。本书主要聚焦于几个关键的性能反模式，即持久性、异构系统、线程管理和堆内存管理，这些是许多性能问题的根源所在。书中的核心部分是作者提出的“P.A.t.h. Checkliste”，这是一个系统化的步骤方法，帮助读者通过以下四个步骤来诊断和解决性能问题： 1. **持久性（Persistence）**：关注数据库查询优化、连接池管理以及数据访问是否高效。确保数据访问的效率对整体性能至关重要，避免不必要的I/O操作或慢查询导致的延迟。 2. **异构系统（Alien Systems）**：检查应用程序与外部系统的交互是否顺畅。这可能涉及API调用、网络通信或者第三方库的性能。确保这些外部资源的性能瓶颈不会拖累整个应用。 3. **线程（Threads）**：分析线程间的协作和同步，以避免死锁、竞态条件或过多的上下文切换。高效的线程管理能显著提升并发处理能力。 4. **堆内存管理（Heap Management）**：理解Java堆内存的工作原理，监控内存分配和回收，识别并避免内存泄漏或过大内存消耗。合理使用垃圾回收策略可以避免性能瓶颈。本书特别强调在缺乏监控的“暗”环境中应用这些技巧，因为它们提供了在没有全面日志支持的情况下也能进行有效诊断的方法。通过本书提供的实例和实用建议，读者不仅能掌握解决Java性能问题的基本技巧，还能学习如何在日常工作中实施一个可重复使用的性能优化流程，从而大大提高工作效率。总结来说，《Troubleshooting Java Performance》是一本深入浅出的实战手册，适合任何面临Java应用性能挑战的开发者或系统管理员，无论是初级还是经验丰富的从业者，都能从中获益匪浅。它强调了开源工具在性能分析中的重要作用，并提供了一个标准化的方法来应对各种性能问题，让读者在解决实际问题时更加自信和高效。

资源详情

资源推荐

xix

Acknowledgments

Thanks to Apress for trusting me as a first time author; your support means everything to me.

Shawn McKinney of the Apache Foundation was the first person who thought I could write a book.

Shawn, your early encouragement and honest feedback on crazy ideas have been invaluable, and you were

always the first to provide feedback on any new code. Thanks. Mike Scheuter is one of the smartest people

I know; he’s a longtime friend, mentor, and colleague from FIS who first taught me to fall in love with stack

traces and so many other things, work-related and otherwise. Thanks to my employer FIS and to our PerfCoE

team. FIS’ continued executive-level support for great performance throughout the enterprise is unique in

the industry. Thank you for that.

Dr. Liz Pierce, the Chair of the Information Science department at UA Little Rock, orchestrated an 8-hour

Java performance workshop that I gave in early June, 2017. Thanks, Dr. Liz for your support, and thanks to the 15

or so students, faculty, and others who gave up two Saturday afternoons to geek out on performance. Loved it. The

CMG Canada group in Toronto was also kind enough the vet some of these ideas a month or two prior. Thanks.

In 2011, I won a best paper and best speaker award at a cmg.org international performance conference. The

famous American computer scientist Jeff Buzen, who made many contributions to the field of queueing theory,

led the committee that selected me for those awards. CMG’s support (monetary and otherwise) way back then

provided the confidence I needed to publish this book many years later. Thank you Jeff, thank you CMG.

There are many others who have helped in various ways: Joyce Fletcher and Rod Rowley who gave

me my first tuning job way back in 2006. Thanks to Mike Dunlavey, Nick Seward, Stellus Pereira, David

Humphrey, Dan Sobkoviak, and Mike McMillan for their support. To my Dad, Ralph Ostermueller, for your

sustained interest and support over many, many months, and to Mom, too.

I’d also like to quickly mention just few of the particular open-source projects that I benefit from every

day. Thanks to Trask at Glowroot.org for last minute fixes, to JMeter and JMeter-Plugins. You all rock.

Thanks to Walter Kuketz, Jeremiah Bentch, Erik Nilsson, and Juan Carlos Terrazas for reading late

drafts of this book. Erik, your demands for clarity in the early chapters haunted me. Your input forced me to

raise my standards a bit; I hope it shows, thanks. Jeremiah, your veteran commentary on SELECT N+1, JPA

and other issues helped me fill in big gaps. Thanks. Lastly, to Walter: Your decades of performance/SDLC

experience, succinctly imparted, really helped me avoid derailment at the end. Thanks.

To my technical reviewer, Rick Wagner: Rick, what I most loved about working with you, beyond your

extensive Java/RedHat experience and beyond your unique experience reviewing so many technical books,

was your ability to regularly guide me to paint a more complete picture of software performance for the

reader, instead of the 1/2 painted I had started with. Thanks.

Lastly, thanks to my family. My older son Owen’s editing skills are really on display in the introduction,

Chapters 1 and 8, and other places as well. He’s 20, knows nothing about programming, but gave me

masterful lessons on how to gradually build complex ideas. Who’d a thunk it. Contact him before you write

your next book. John, my younger son, helped test the code examples and put up with many brainstorming

sessions that finally knocked the right idea out of my head. John’s editing skills lie in smoothing out

individual sentences. It turns out, there is a pattern here. My incredible wife Joan Dudley, who teaches

college literature, is a-big picture editor for both this book and her students. Joan’s editing contributions are

“every paragraph is important” and “clarity takes a back seat to no one.” Joan, you made many sacrifices,

holding the fort down while I worked on this insanely long project. I love you and thank you for encouraging

me to attempt great things.

xxi

Introduction

With just 30 minutes of troubleshooting, how close can you get to finding the root cause of a Java

performance problem? What observability tools would you use? What subsystems would you investigate?

This book is a short curriculum in Java performance tuning for Java server-side developers. It explores

one methodical approach to getting the most out of your 30 minutes and aims to show that much more is

possible than is generally thought, even for Java developers with little exposure to performance tuning.

The brevity of this book is attributed to a sharp focus on only the worst problems seen in the author’s

10 years of working exclusively as a lead Java performance engineer with Java distributed systems. That said,

the tools and techniques can be used to find pretty much any defect.

This book is heavy on walkthroughs of performance problems that you can download from github.com

and run on your own machine. The hands-on examples provide a rich, in-the-trenches experience that a

book-only approach can’t provide, not even a much larger book.

The reader will learn a methodical, easy-to-remember four-step tuning approach, called the P.A.t.h.

Checklist, that directs the reader’s attention to the right parts of the system and the right tools to find the

performance defects. If you’re wondering why I’ve chosen to capitalize the acronym that way, you’ll find out

in Chapter 4. Only open-source and freely available tools are used. In most cases, you will even see how the

monitoring data looks before and after a performance fix is applied. Here is the checklist:

• P: Persistence. Learn how to recognize and fix the most common JDBC performance

issues, ones that also apply to the NoSQL world.

• A: Alien systems. Detect when network calls to other systems cause slowdowns.

• t: threads. Learn how to identify CPU and response time issues using a low overhead

tool that can be used in any environment, even production.

• h: heap. With the Quick GC Health Check, the reader will use a red-yellow green

approach to assess whether GC performance is healthy. It also provides direction for

more advanced techniques like finding/fixing memory leaks.

Generating a production-like workload is required to identify these defects, so there are a few chapters

to get you up and going quickly to create load scripts to stress out your system. Among other topics like

load scripting priorities and avoiding common pitfalls, the reader will learn a unique approach to deciding

exactly how many threads of load to apply to show whether your system is scalable.

Themes

There are a number of recurring themes that we bump into while tuning software.

■ IntroduCtIon

xxiii

• Large environments have a ton of extra components with questionable performance:

load balancers, firewalls, content switches, clusters, application server configuration,

and so on.

• Larger staffing costs to babysit the extra infrastructure.

All of these things keep me from getting excited about large environments. I’m a little surprised anyone

chooses to work like this because progress is excruciatingly slow. Ultimately, what really gets me excited is

more tuning in less time.

What if we could get 5-10 fix-test tuning cycles completed a day, instead of the traditional 2-3? That

would be a faster and more impressive way to tackle poor performance.

What if we could carefully design a tuning environment that minimized the Big Environment Paralysis?

This would enable us developers to shift focus away from managing an environment and towards the

performance of our deliverable, the Java code itself. I call this the Code First approach to tuning, and it’s

important because it’s the fastest way to tune a system.

Chapter 2 lays out a very detailed design for such a tuning environment, one with a very special

mystery feature that really minimizes Big Environment Paralysis. But aside from all of this, one particular

requirement for this environment is key: when tuning here, we must be be able to reproduce most of

the defects that we’d normally find in production. The environment would be worthless without it. So

to concretely demonstrate that production-like performance defects can be found (and fixed) in this

environment, I have coded two sets of server-side Java code examples that demonstrate these performance

defects (under load) and their fixes.

Write Once Run Anywhere (WORA) Performance Defects

When Java was first released in the mid 1990s, compiling and running a ‘C’ program on multiple operating

systems (OSs) was a royal pain. In response, the Java platform went to great lengths to ensure that Java code

written on one OS could easily compile and run on all other OSs where Java was available. Sun Microsystems

called this Write Once Run Anywhere (WORA).

But it just so happens that WORA has an undesirable and little-known side-effect: if there is a

performance defect in your code, then that defect manifests itself not only on multiple platforms, but also in

environments of different sizes, large and small.

Of course there are exceptions, but this has proven out repeatedly in my ten years as a Java performance

engineer. Since I expect this will be hard for most readers to believe, I have coded more than a dozen

performance defects to prove the point. Chapter 2 provides a quick overview of the performance results of

these load tests. Chapter 8 details the architecture of the tests and describes how to run these examples on

your own machine, with whatever capacity it might have.

Because most performance defects are reproducible in both large and small environments, we have an

critical choice to make of where we do our performance tuning. This part is very important: Why tune in a

big environment and suffer through all the ‘Big Environment Paralysis’ problems, when we could be much

more productive and get 5-10 fix test cycles a day in a small environment?

Keep in mind that even though most tuning is done in a small environment for expediency, a larger

environment is often required to demonstrate the full throughput and other performance requirements.

What are performance requirements? We’ll get to that real soon.

Three Threads of Load, Zero Think Time (3t0tt)

Part of my day job is training developers to tune their code. One of the most frequent mistakes I see is people

stressing out their Java server-side systems with unrealistically large amounts of load. There are so many

guys in this field, perhaps this is a testosterone thing?

■ IntroduCtIon

xxiv

Both sets of code that come with this book execute small load tests that apply stress to a server-side

system. Each one of these tests is configured to launch exactly three Java threads that are simultaneously and

perpetually submitting HTTP network requests. No ‘think time’ is configured between the HTTP requests. I

call this amount of load 3t0tt, because it is 3 threads of load with zero think time. This is pronounced ‘three

tot.’ It is used as a quantity of load, like this: How much load are you applying? 3t0tt.

This particular level of load is designed to have small enough CPU and RAM consumption to run on

just about any workstation, but large enough to reproduce most multithreaded / synchronization problems.

Even though this small amount of load is rarely enough stress to cause a system to go bezerk, throughout

this book, the reader is encouraged to evaluate a few specific parts of the system and determine which one

is causing the largest slowdown. This is called ‘the lowest hanging fruit.’ After identifying the issue, a fix is

deployed and re-tested. If performance improves, the next lowest hanging-fruit issue is investigated and the

process repeats.

Choosing the right amount of load to apply is tough for newcomers to performance. 3t0tt provides a

very easy starting point to a difficult training problem. In Chapter 6, you will learn the next lesson in this

realm, which is determining how much load to apply to quickly assess scalability.

The Discipline of Performance Engineering

This book is more of a troubleshooting guide than a guide to the entire discipline of performance tuning.

This little section provides a brief look at how the performance process should work and how to know when

you’re done tuning a system.

If we’re building a software system, the specs that define precisely what we’re going to code are called

the ‘functional requirements.’ They detail the items of data entry on each screen and the results that should

be displayed when the user hits the ‘submit’ button. When all functionality in the requirements has been

delivered, the application is functionally complete.

Performance requirements, on the other hand, define how quickly the application must respond,

and how many business processes the system must handle in a particular time interval (like in an hour) in

order to satisfy client needs. These are called, respectively, response time and throughput requirements.

A performance requirements document starts by listing all/most of the business processes (from the

function requirements) and then assigning response time and throughput requirements to each.

For example, if the response time requirement for your funds transfer is 2 seconds and its throughput

requirement is 3,600 an hour, then a steady state load test (see Chapters 4, 5, 6, and 7 for details on load

testing) must demonstrate that 90% of funds transfer response times are less than 2 seconds and that at least

3,600 of them were successfully executed in 60 minutes.

Sometimes performance requirements even place a cap on how much money can be spent

on hardware. If five nodes in a cluster were required to meet the above goals, and the performance

requirements said we could buy at most four nodes, then more tuning would need to be done (probably to

lower CPU consumption) so that the response time and throughput goals could be met with just four nodes.

It is also common to stipulate that all performance requirements must be met while keeping CPU

consumption below X, where X is whatever the operations folks feel comfortable with in production.

One of the most common mistakes in this area is not having any performance requirements at all. Of

course these requirements are imprecise and imperfect. Start with something and refine them over time to

best approximate client performance and stability needs without wasting time over-tuning the system.

Here is an example of the kind of refinement I’m talking about. Time should be spent understanding

how closely the performance requirements match up to response time and throughput data gathered

from production. If production data shows that the system processes 7,200 funds transfers on the busiest

hour of the busiest day of the year, and the throughput requirement is less than that, then the throughput

requirement should be raised to at least this number (7,200) and probably a little (perhaps 25%) higher, just

to be safe.

剩余203页未读，继续阅读

tlforest

粉丝: 27
资源: 198

Java性能调优实战：开源工具识别与解决常见问题

Troubleshooting Java Performance Detecting Anti-Patterns with Open Source epub

trouble shooting java performance

Java Performance Tuning Guide 1.3 By 江南白衣

awt is not properly configured on this server. perhaps you need to run your container with "-djava.awt.headless=true"? see also: https://www.jenkins.io/redirect/troubleshooting/java.awt.headless

troubleshooting是什么意思

JDWP can not find class java/lang/class

unable to verify your captcha response. please visit https://docs.github.com/articles/troubleshooting-connectivity-problems/#troubleshooting-the-captcha for troubleshooting information.

warning: ignoring JAVA_HOME=C:\Program Files\Java\jdk-16.0.2\; using bundled JDK

matlab2015b报错troubleshooting

troubleshooting ip routing protocols

WebSocketServer java.io.EOFException

SQL Server Query Store

SQL Profiler

Unable to verify your captcha response. Please visit https://docs.github.com/articles/troubleshooting-connectivity-problems/#troubleshooting-the-captcha for troubleshooting information.

centos7 troubleshooting

https://github.com/git-lfs/git-lfs/wiki/Troubleshooting

esptool.py v4.5.1 Serial port COM1 Connecting...................................... A fatal error occurred: Failed to connect to ESP32: No serial data received. For troubleshooting steps visit: https://docs.espressif.com/projects/esptool/en/latest/troubleshooting.html

troubleshooting with the windows sysinternals tools, 2nd edition

There has been a critical error on this website. Learn more about troubleshooting WordPress.具体解决办法

最新资源