Oracle Architect optimizes performance using GCeasy

Prabhakar Jonnalagadda is the performance architect in Oracle. He was presented with a performance problem of an application which had following symptoms:

+ Frequent unavailability of the application (crash issues)

+ Significant degraded performance in repeated spells

In this post he talks about how he solved this application’s performance problems. He basically analyzes the GC log using GCeasy to understand the GC behavior. He then tweaks JVM arguments such as ‘-XX:ConcGCThreads’, ‘-XX:G1ReservePercent’, ‘-XX:InitiatingHeapOccupancyPercent’, ‘-XX:G1HeapRegionSize’, ‘-XX:G1HeapWastePercent’, ‘-XX:MaxGCPauseMillis’ and makes the application performance lot better. It’s an interesting read.

Prabhakar then concludes his post with following note (which we totally agree):

‘The tuning options recommended were very specific to this particular use case and usually remain unique for each and every application.  It is up to the engineers working on the problem to take reference of these and then adapt / modify them appropriately for their specific requirement as there is no ‘one size fits all’ concept.  The same problem could have been dealt with a different set of tuning parameters, and this is one of the many approaches and does not necessarily make this the only one solution.  Its up to the engineers who are workign on such problems to be intrigued and invest time in investigation and experiment as much to get things right.’ 

One thought on “Oracle Architect optimizes performance using GCeasy

Add yours

  1. Thanks for the heads up on the new blog and series. It’s always exciting to see when someone wants to try to contribute to the challenging world of java/performance tuning and troubleshooting.

    That said, it’s unfortunate that the blog there does not offer people the ability to leave comments. I realize that’s a “thing” in some blogging circles. But there are many things I’d have asked about (on behalf of readers), such as:
    – what was the Java 8 update they “reverted” to?
    – what would have seen if they if they had updated to the latest Java 8 update?
    – what if they had done ONLY the Java update change they did, and not all the other changes?
    – indeed, what if they had merely removed ALL the non-standard jvm “tuning” args other than heap size?
    – Or in fact what if they just left the jvm to choose its heap size (a calculation that can change per jvm version and is)?
    – more important, why didn’t they show the impact of any one change at a time? Or of whatever they may think were key ones?

    Most important, they often literally “jumped to conclusions”, proposing changes to values without explaining how a reader might be able to come to the same conclusion (let alone what mitigating factors might lead them or the reader to a different setting).

    Yes, it’s great that they acknowledged how such tuning exercises are unique to each situation, and it’s great that you highlighted that.

    But since a post like that (or especially such a series, or indeed such a blog devoted to Java/performance tuning) could get a lot of attention, it’s incumbent on them to be still more careful about recommendations–and to be open to feedback, so that those with questions (or others with answers) can contribute to the knowledge shared, like you do here.

    Of course, even that post was itself a lot of work, I realize. And going into more depth is challenging to both the writer AND reader. But it’s necessary, specifically IN ORDER that readers don’t misread suggested changes as being broadly applicable to everyone. There’s definitely a fine line, and it’s not easy…as indeed folks looking for help can attest.

    I realize this is criticism of the blog. Again, I do appreciate their effort. But I hope it’s indeed constructive criticism, whether they or others may agree with me or not. I leave it here for your readers to consider, at least. And I’m certainly open to feedback.

Leave a Reply

Powered by

Up ↑

%d bloggers like this: