Day 3@J1
G1 Garbage Collector Performance Tuning
Charlie Hunt
Monica Beckwith
Monica Beckwith
This was an interesting talk on the behaviour profile of G1 (garbage first) garbage collector and the available tuning switches.
The slides presented a number of interested -X toggles for G1 that I couldn't grab as Monica had a large amount of material to cover and a small amount of time to fit it all in. I encourage a review of the slides, they gave options for targeting throughput (the percentage of time your JVM is not in garbage collection) and low latency - a key flag for G1 as -XX:MaxGCPauseMillis. Note that this will be ignored if you also set the young and tenured heap sizes.
Do your GC logs speak to you
Kirk PeperdineI found this the least useful talk, but again I think this could be down to the fact that this type of thing is our main area of expertise. To a new comer this talk will probably help bring them up to speed on JVM throughput profiling. Effectively I can reduce it to the following statement:
-Turn on GC logging
-Monitor the heap sizes
-Know about the Young, Survivor, Tenured spaces
-Graph the heap sizes.
-Use flags such as MaxTenuringDistribution to control promotion of objects in young to old space.
Continuous Enterprise Development
Andrew Lee RubingerAslak Knutsen
This talk began with a review of the types of enterprise testing policies and their benefits. It then positions Arquillian as a tool which can fit into the missing gap of JEE testing, and goes on to introduce the OpenShift PaaS platform.. Whilst lively and well hosted by Rubinger and Knutsen, I felt that it was lacking the technical detail that would allow me to evaluate and leverage Arquillian in this space.
I think this is a shame, as Arquillian is a powerful tool that has real potential to enable repeatable test scenarios at the container level - something that takes great time, expense and custom code/setup presently. I like this tool and want more people using it!
I'd have liked more of an overview of the features that Arquillian brings to bear on this problem. I'd like to have left the talk knowing how to go from 0-60 with Arquillian.
Hudson: From Setting Up Your First Instance to Your First Plug-in and Beyond
Hudson: From Setting Up Your First Instance to Your First Plug-in and Beyond
This was an open tutorial on getting to grips with Hudson. Unfortunately my session was plagued with bugs!
- The release candidate of Hudson had incompatibilities with Java 7 and Maven 3!
- I could not spawn helper client instances that inherited pathing & tooling issues to build sub-projects.
Like a good community member I reported the bugs!
Advanced Enterprise Architectures Using Open Source
Heath Kesler
This was a well presented talk about how to architect and configure instances of Apache ActiveMQ, Apache Camel and Apache Karaf/ServiceMix to expose Highly Available SOA style enterprise services. The focus was on the ease of endpoint configuration using these services, native coupling and architectural considerations.
I'm a big fan of Camel, it was good to see it being presented as a candidate service provider in the enterprise space. One thing to consider however that wasn't touched in the talk: Camel is not natively fault tolerant; your service invocations will be lost if the hosting node fails!
Big RAM
Neil FergusonThis was an interesting talk on using large Java heap sizes in a forward look at computing trends. Beginning with a bold prediction that within 4 years we will be operating with hosts that have Terrabytes of RAM, this talk goes on to look at how instances of Java can utilise heaps that run to hundreds of GB.
The answer is; currently not very well. Stop the world pause times, even with the present G1 offering, run to tens of minutes. Parallel GC was actually the most predictable and performant.
Neil went on to look at other JDK features such as off heap storage and memory fragmentation, and the performance statistics associated with each. In my opinion this isn't a use case that we see a lot of; most end users will virtualise large memory machines at the operating system level to isolate concerns and improve utilisation. That said, I do agree that JVM performance moving past 8G size heaps is a cause for concern.
I think Neil's takeaway point is fair, that as we move forwards we should try to get very large heap support considered as a high priority for the JDK GC algorithm engineers. I personally think that this is a problem that will require at least an iterative step from the existing GC algorithms, possibly even a new generation of them. As big memory becomes more prominent tools such as data grids and Hadoop will allow grow in usage, the techniques to leverage large scale memory instances are already there, but we'll see bigger and bigger implementations leading to novel and new problems.
Nick Wright
No comments:
Post a Comment