|
|
Featured White Papers
- Why choose an Open Source BPM?
- 10 FAQs on Business Process Management
- Best Practices for Getting Started with BPM
- Free Your Devs From The Pain Of Java Redeploys
- Increase Velocity 40% by Using JRebel
- What Developers Want: The End of Application Redeploys
- Developer Productivity Report: Java Tools, Tech, Devs, and Data
- Coding with JRebel: Java Forever Changed
- Utilizing Fast Testing to Transform Java Development
- Do You Really Get Classloaders?
- Pragmatic Continuous Delivery with Jenkins, Nexus, and LiveRebel
- Your Next Java Web App: Less XML, No Long Restarts, Fewer Hassles
- Coding with JRebel, Java Forever Changed
- 2012 Developer Productivity Report: Java Tools, Tech, Devs, and Data
Sponsored Links
Sponsored Links
Optimize with a SATA RAID Storage Solution
Range of capacities as low as $1250 per TB. Ideal if you currently rely on servers/disks/JBODs
JVM performance optimization, Part 5: Is Java scalability an oxymoron?
Why better Java performance tuning won't solve Java's scalability problem
A major issue stands in the way of Java scalability today, and Cloudera's Eva Andreasson wants Java developers to stop ignoring it. Here she makes the case for why true Java application scalability will require a dramatic overhaul in how we think about Java virtual machines, and how developers and vendors build them.
Most developers approach JVM performance issues as they surface, which means spending a lot of time fine-tuning application-level bottlenecks. If you've been reading this series so far then you know that I see the problem more systemically. I say it's JVM technology that limits the scalability of enterprise Java applications. Before we go further, let me point out some leading facts:
- Modern hardware servers offer huge amounts of memory.
- Distributed systems require huge amounts of memory, the demand is always increasing.
- A normal heap size for a Java application instance currently is between 1 and 4 GB -- far below what most servers can manage and what most distributed applications require. This is sometimes known as the Java application memory wall, as illustrated in Figure 1.
The time graph in Figure 1, created by Gil Tene, shows a history of memory usage on Java application servers and what was a normal heap size for Java applications at each point in time. (See Resources.)
Figure 1. The Java application memory wall from 1980 to 2010 (click to enlarge)
Image copyright Azul Systems.
This brings us to the JVM performance conundrum, which goes something like this:
- If you provide too little memory to an application it will run out of memory. The JVM will not be able to free up memory space
at the rate that your application needs it. Push too hard and eventually the JVM will throw an
OutOfMemoryErrorand shut down completely. So you have to provide more memory to your applications. - If you increase the heap size for a response-time-sensitive application, the heap will eventually become fragmented. This is unavoidable if you don't restart your system or custom-architect your application. When fragmentation happens, an application can hang for anywhere from 100 millisecond to 100 seconds depending on the application, the heap size, and other JVM tuning parameters.
Most discourse about JVM pauses focuses on average or target pauses. What isn't discussed as much is the worst-case pause time that happens when the whole heap needs to be compacted. A worst-case pause time in a production environment is around one second per gigabyte of live data in the heap.
JVM performance optimization: Read the series
- Part 1: Overview
- Part 2: Compilers
- Part 3: Garbage collection
- Part 4: Concurrently compacting GC
- Part 5: Scalability
A two- to four-second pause is not acceptable for most enterprise applications, so Java application instances are stalled out at 2 to 4 GB, despite their need for more memory. On some 64-bit systems, with lots of JVM tuning for scale, it is possible to run 16 GB or even 20 GB heaps and meet typical response-time SLAs. But compared to where Java heap sizes should be today, we're still way off. The limitation lies in the JVM's inability to handle fragmentation without a stop-the-world GC. As a result, Java application developers are stuck doing two tasks that most of us deplore:
- Feedback
More from JavaWorld
Resources
- "Understanding Java Garbage Collection and What You Can Do about It" (Gil Tene, InfoQ, December 2011): Azul cofounder Gil Tene explains the workings of a garbage collector, including terminology, metrics, key mechanisms, and the application memory wall challenge discussed in this article.
- Oracle HotSpot FAQ: State-of-the-art tuning advice for long pause times is to decrease heap size.
- "Maximum Java heap size of a 32-bit JVM on a 64-bit OS" (Stackoverflow, September 2009): Developers on Stackoverflow discuss the challenge of tuning Java heap size for real-world systems.
- "About OpenDJ and Hotspot JVM G1" (Ludovic Poitou, Ludo's Sketches, May 2012): JVM performance has far-reaching implications for innovation on Java projects like the OpenDJ Directory Services Project.
Earlier articles in the JVM performance optimization series:
- Part 1: Overview (August 2012)
- Part 2: Compilers (September 2012)
- Part 3: Garbage collection (October 2012)
- Part 4: Concurrently compacting (C4) GC (November 2012)
Also on JavaWorld:
- "Java performance programming, Part 1: Smart object-management saves the day" (Dennis M. Sosnoski, August 2001).
- "Pick up performance with generational garbage collection" (Ken Gottry, 2002)
- "Java's garbage-collected heap" (JW Classics, Bill Venners, 1996)
- "Building cloud ready, multicore friendly applications, Part 1" (Guerry Semones, March 2009).