11

I ran memory Profiler using NetBeans and VisualVM and received the results but do not have a clue how to analyze its results, I studied this article but it does not teach or give a clue on how to interpret the results.

I have also found this article about interpreting results on Netbeans 4 but am looking for an article with more details,or a way to interpret the following results to learn.

enter image description here

J888
  • 1,944
  • 8
  • 42
  • 76
  • Check this out https://netbeans.org/competition/win-with-netbeans/nb-profiler-tutor-5.html – Aneel Ansari Nov 21 '13 at 05:01
  • @AneelAnsari this is same as the second article that I mentioned in the question. – J888 Nov 21 '13 at 05:03
  • Sorry my bad! This article does tell you how to interpret these graphs and as well as how you can watch your methods performance. – Aneel Ansari Nov 21 '13 at 05:04
  • 1
    I've noticed that, but I am lookign for the updated one and more details, this one is related to netbeans 4 and is not a comprehensive refernece. – J888 Nov 21 '13 at 05:07
  • 1
    Perhaps you would like to tell us what exactly you are trying to analyse while profiling? – Aneel Ansari Nov 21 '13 at 05:08
  • 1
    memory and cpu usage, to make sure it does not have memory leaks and all usages are reasonable. – J888 Nov 21 '13 at 05:10

5 Answers5

8

There really isn't much information conveyed in the telemetry graphs you've pasted in your question.

What is conveyed

  • Your program was monitored for about 3 minutes
  • Your heap utilization is slightly less than 200mb (nothing special)
  • You've got about 90 threads (this must be an app server)
  • You're spending less than 5% on average in GC (normal)

I bet the saw-tooth pattern conveyed in the memory visualizer is your program booting - otherwise why do things seem to smooth other in the last minute or so. Was your application under any load during the 3 minute period shown in your question?

As a starting point I'd look at how much time your program spends in GC (Relative Time in GC) when your program is doing some heavy lifting. If it's more than 5%, you may consider tuning your heap or digging further to find out where the allocations are occuring.

Next I would look for a bottleneck. Find out where your application is spending most of it's time, and see if you can somehow optimize that code.

Amir Afghani
  • 37,814
  • 16
  • 84
  • 124
  • great thanks, yes thats just a sample, it does not load the app just runs into errors .it shows warnings such as SEVERE: *** Profiler engine warning: class sun.reflect.GeneratedConstructorAccessor49 that should be instrumented is not loaded by target VM SEVERE: *** Requested classloader: sun.reflect.DelegatingClassLoader@f27821e SEVERE: , its class = class sun.reflect.DelegatingClassLoader, index = 194, hashcode = 254247454 SEVERE: *** Profiler engine warning: target VM cannot load class to instrument sun.reflect.GeneratedConstructorAccessor49 – J888 Nov 29 '13 at 05:24
  • it also shows Instance is not GlassFish Server 4 or it is not running. – J888 Nov 29 '13 at 05:26
  • Do you know of any documentation so I can read more about interpreting results? – J888 Nov 29 '13 at 05:29
  • I'm not familiar with the NetBeans profiler but you can always read through https://profiler.netbeans.org/. With respect to your other question about the errors, I believe this means the version of the JVM is not the same as the JVM running your profiler. – Amir Afghani Nov 29 '13 at 05:30
  • I see how can I verify the version of JVMs ? I am not sure whats wrong with it, even when I use visual vm it does not show the project's name it just shows Glassfish 4 and netbeans – J888 Nov 29 '13 at 05:34
  • 1
    I could just solve the problem and run the profiler, then ran a function of application and updated the questions's picture would you comment on that, if possible please tel me more info similar to your last two paragraphs or refer me to a doc to find similar info thanks. – J888 Nov 29 '13 at 05:56
7

I don't know much about profiler in netbeans but I'd prefer visualvm. It has wide range of profiling. https://visualvm.java.net/

VisualVM is a visual tool integrating several commandline JDK tools and lightweight profiling capabilities. Designed for both production and development time use, it further enhances the capability of monitoring and performance analysis for the Java SE platform

Sample program for memory test

public class MemoryTest {
    public static void main(String[] args) {
        ArrayList<String> temp = new ArrayList<String>();
        for (int i = 0; i < 1000000; i++) {
            temp.add(String.valueOf(i));
            System.out.println("index:" + temp.get(i));
        }
        System.out.println(temp.size());
    }
}

Open visualvm. It'll list your program in left side. Also provide you multiple option to test your program against Memory and CPU. You can also profile particular package using it.

enter image description here

enter image description here

Vicky Thakor
  • 3,847
  • 7
  • 42
  • 67
  • 6
    Great thanks, I've tried V-VM as well but my problem is that need to know how to interpret the results. I mean in this case char[] and String are used much then how to figure out which part of the code causes them? –  Nov 28 '13 at 07:47
2

This entry is not specific to Netbeans 7 but does have some good simple starters on JVM memory usage and profiling fundamentals. Sometimes a better understanding of the fundamentals uncovers better programming technique for avoiding future memory issues. http://java.dzone.com/articles/java-memory-model-simplified

Fast Engy
  • 1,913
  • 1
  • 12
  • 10
2

It is really difficult to find good article on Netbeans profiler. I found this link helpful.

Summary of above three graphs is as below:

Graph (1) In 1st graph, red shading in the first graph indicates allocated size of the JVM heap while purple overlay indicates the amount of heap space actually in use. In this picture allocated heap size is around 450 MB out of which 140 MB is used to hold java objects.

Graph (2) 2nd graph shows heap statistics.

  • Blue line is the % of execution time spent by the JVM doing GC. If you see blue line large percentage then you should increase JVM heap size.(-Xmx parameter). Proper analysis of GC frequency will allow you to determine if your app is facing problem or not. Keep in mind that GC related problems are unlikely to be caught during development or functional testing. Proper garbage collection tuning will require you to perform load and perform testing with high-volume from simultaneous users.
  • Red line: Count of surviving generations is the % of different ages of the java objects on the JVM's heap. When the value of surviving generations is low it indicates that most of the objects on the heap have been around about the same amount of time. If however, the value for surviving generations is increasing at a highe rate over time then it indicates that your app is allocating new objects while maintaining references to many of the older objects it already allocated, so waste of memory or even memory leak.

Graph (3) 3rd Graph shows count of active threads in JVM. Too much variation of active counts of threads will eat CPU (context switching).

Pujan
  • 3,154
  • 3
  • 38
  • 52
0

If You would run this app for a longer time and the graph indicating JVM heap size would look like this:

enter image description here

then You can be sure of a memory leak.

Creating a memory leak with Java

Community
  • 1
  • 1
Thomas
  • 2,131
  • 2
  • 20
  • 23