0

I am trying to analyze/profile a core JAVA application.

I am using JConsole with Eclipse MAT.

I observed following in Perm-Gen graphs(data recorded in 1 hour duration on a Windows XP machine):

Code-Cache:

  • At recording start: 7MB
  • After 1 hour: 10.5 MB
  • Graph looks like: slantedline slightly going up increasing at intervals.

Memory Pool Perm-Gen(Shared-rw):

  • At recording start: 7MB
  • After 1 hour: 7 MB
  • Graph looks like: parallel to X axis.

Memory Pool Perm-Gen(Shared-r0):

  • At recording start: 5.5MB
  • After 1 hour: 5.5MB
  • Graph looks like: parallel to X axis.

Memory Pool:

  • At recording start: 21MB
  • After 1 hour: 22.5 MB
  • Graph looks like: slantedline slightly going up/down increasing at intervals.

My question is,

  • What can be inferred such behaviour of Perm-Gen space for each of the above category ?
  • What should be the ideal behaviour to look for each of the above category ?

Ideal behaviour here refers to a state which represents:

  • Application is performing at best.
  • Application does not have any memory related problems.
  • No improvements are needed in code, to improvise resource utilization.

Above question is also applicable for Heap space analysis.

Below are additional clarifications:

  • Its true that profiling should be done in same env as that of production. But it would really help if I can understand what is the real target here. As of now, I am trying to learn the same. Then in future, I will try to do it on production.

  • Also, I am trying to compare two code bases(one refactored and one old). I want to know the extent of benefits which are achieved by refactoring(as quantitative data). I think if I am recording results on same platform, comparison will hold true(regardless of Production or Development ).

UPDATE 1:

  • I further ran application for more than 8 hours straight.
  • I used GCViewer:1.31 to get GC information.
  • I am attaching the data gathered from GCViewer.
  • I observed that in every 30 seconds, one FULL GC event was happening. This concludes that lots of objects are log-living.
  • I need further information. I am really not sure how to interpret these details correctly and completely.

Please have a look at the attachment. Please provide inputs.

enter image description here

Cœur
  • 37,241
  • 25
  • 195
  • 267
Learn More
  • 1,535
  • 4
  • 29
  • 51
  • 1
    What is your production environment for this code? If the answer isn't "Windows XP", you are wasting your time. – kittylyst Aug 06 '13 at 09:55
  • Agreed. Its true that profiling should be done in same env as that of production. But it would really help if I can understand what is the real target here. As of now, I am trying to learn the same. Then in future, I will try to do it on production. – Learn More Aug 06 '13 at 10:03
  • I would like to add that I am trying to compare two codebases(one refactored and one old). I want to know the extent of benefits which are acheived by rafactoring as quantitative data. I think if I am recording results on same platform, comparision will hold true(regardless of Production or Development ). – Learn More Aug 06 '13 at 10:24
  • 1
    Profiling should also be done on development side. That memory behaviour is influenced by settings and platform might, which might have catastrophic effects, is true. But local profiling might already show which objects live very long, to say nothing about speed bottlenecks. – Joop Eggen Aug 06 '13 at 12:36
  • A couple more things: – kittylyst Aug 07 '13 at 15:11
  • @All, I have done further analysis and updated in OP. Please have a look. – Learn More Aug 13 '13 at 15:49
  • I've had another look & can't see necessarily that there are any issues here - it all depends on workload etc. Also GCViewer doesn't really seem to be providing enough info. – kittylyst Aug 14 '13 at 13:17
  • These are my precise queries: 1. How do I know if there are no issues. 2. What is additional information I should look for. – Learn More Aug 14 '13 at 13:42

1 Answers1

1

A couple of suggestions:

1) Ditch JConsole. VisualVM is included with the JDK and is superior in every respect (and includes a bridge mode so you can even use old plugins, if that's all that's keeping you on JConsole).

2) Switch GC logging on. You need at least these flags:

-Xloggc: (for more comprehensive GC logging) -XX:+PrintGCDetails (for more detailed output) -XX:+PrintTenuringDistribution (displays the tenuring thresholds assumed by the JVM)

Find a tool to analyse the logs - you need to pay attention to the working set of objects as well as PermGen, even if the the latter is your primary concern. GCViewer is free, or there are commercial tools (Full disclosure - I work for jClarity, which produces the Censum tool for this purpose).

3) You need to run for a lot longer than 1 hour. A lot of applications don't stabilise for quite a while.

4) Looking at your numbers again, this doesn't look that out of the ordinary / a problem. Why are you tuning this bit of the JVM? What aspect of the system has indicated that this is a serious problem and needs to be worked on? How did you determine this, and how is this problem manifesting?

kittylyst
  • 5,640
  • 2
  • 23
  • 36
  • I found your suggestions really useful. I have followed your guidelines. Please have a look at updated question. – Learn More Aug 13 '13 at 15:50