Monitoring and Profiling using VisualVM-1

I executed a simple GUI application which would load the CSV file and parse it and show the contents in a JTable. When the applications started- There was a JFrame, 2 JPanels, a JLabel and a JButton with an Icon. I wanted to monitor the Heap size variations, the number of Classes, Threads details and also wanted to profile the application. So i thought of using VisualVM. The following are the results and snapshots of profiling using VisualVM. Note that the application had only one public class MainFrame in gui package. Also note that i was using the Nimbus Look and Feel.

The Overview tab had the following information:

  • The name of the main class
  • The process ID of the application (PID)- in this case it was 2376
  • Location where the application is running- In this case it was localhost
  • The name of the class containing the main(). Note that it showed the complete name including the package- In this case gui.Mainframe
  • Arguments if any passed to the application on start up.
  • Then there was JVM Version, path to the Java Home, JVM Flags.

Before loading the file for parsing (On initial startup):
[All values in Bytes]

Heap Details:

  • Heap Size: 5,242,880 (This value kept varing)
  • Used Heap: 4,000,000(Average)- This kept fluctuating a lot. Almost used up 77% of the heap size available :(.
  • Max Heap- 67,108,864
Heap details before parsing

Heap details before parsing

There was a button to perform GC. As soon i clicked on it the used heap size came down to around 2,400,000. But it began to increase right after that but kept hovering around the 3,300,300 mark. Looks like lot of objects are being created 😦 This is before the parser actually started working.

PermGen Details:

This gives the overview of the changes in the permanent generation area over time. The permanent generation area stores the classes used by the executing program. This includes the bytecode and the access types of the methods of the classes and the static variables of the classes.

[All values in Bytes]

  • PermGen Size: 12,582,912
  • Used PermGen: 4,038,200
  • Max PermGen Size: 67,108,864

This is the area of the heap. So u can see that the max PermGen size and the Max Heap size are similar. These values rather remained static and did not vary.

Permanent Generation Area before parsing

Permanent Generation Area before parsing

The Classes details are: This gives the overview of the total number of loaded classes and shared classes.

  • Total loaded Classes: 2458
  • Shared loaded classes: 1619
  • Total Unloaded classes: 20
Permanent Generation Area before parsing

Classes stats before parsing

Shows number of live and daemon threads in the application’s JVM.

  • Live Threads: 14
  • Daemon Threads: 11
  • Live Threads peak: 15
  • Started threads total: 19
Permanent Generation Area before parsing

Thread before parsing

Monitoring Threads:
This section gave a Timeline in which the Live and Daemon threads activity was mapped. The threads were either live or finished threads. Live threads were Running, Sleeing, Waitin or Monitoring. On clicking the thread gave more details about the thread.

Monitoring threads before parsing

Monitoring threads before parsing

After loading and parsing the file:

Heap Details:

  • Heap Size: 7,544,832
  • Used Heap: 5,000,000 (Average)
  • Max heap was the same.
Heap details after parsing

Heap details after parsing

In the image u can see the shift in the area graph.

The used PermGen size increased to 4,221,208. An increase of 5% indicating more classes were loaded. The number of loaded classes increased to 2592 and shared classes increased to 1702. Looks like there’s a few more memory consumption after the file was loaded and parsed.

Heap details after parsing

Permanent Generation area details after parsing

Heap details after parsing

Classes stats after parsing

Monitoring tab showing the Heap, thread, PemGen and Classes details

Monitoring tab showing the Heap, thread, PemGen and Classes details

Coming to the major part- Profiling Applications. 2 types of profiling can be done:

  • CPU Profiling– This is done to profile the performance of the application
  • Memory Profiling– This is done to analyze the memory usage of the application. The results display the objects allocated by the application and the class allocating those objects.
CPU Profiling

CPU Profiling

Memory Profiling

Memory Profiling

Categories: Java

Tags: , , , , , ,

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.

%d bloggers like this: