How to interpret profiling results?

Question

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.

Answer 1

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.

Answer 2

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.

Answer 3

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

Answer 4

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).