• Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Does Monitoring via JConsole add additional overhead to JVM

 
Rudraksh Kreshak
Greenhorn
Posts: 4
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
All,

I am a newbie, I have question on Monitoring & Management via JConsole/VisualVM. I understand JConsole provides an efficient way of monitoring and managing remote MBeans residing on a remote JVM, but does it have an additional overhead to the system? Because if we keep JConsole up & running, every 4 seconds it will try to poll the Memory Usage (of Heap/NonHeap and various Memory Pools, etc) via JMX connector, and I believe the Memory Usage is calculated on the fly (via native API calls) as opposed to retrieving it from cache. So according to me there should be an additional overhead (may be negligible).

Can experts put some lights...
 
Greg Charles
Sheriff
Posts: 2985
12
Firefox Browser IntelliJ IDE Java Mac Ruby
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Yes, of course it will have some impact. However, here's an article that says it's only about 3%.
 
Rudraksh Kreshak
Greenhorn
Posts: 4
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
That was what I guessed too..

But my second question, does remote Mbean calculates Memory usage at the time it receives a request from JConsole (i.e., on the fly by calling some native API), or the Memory Usage(s) are being calculated and stored in the background in some data structure at a regular interval, and whenever the MBean (MemoryPoolMXBean) receives a request from JConsole, it retrieves the latest Usage and return it back to JConsole.
 
Tim Moores
Bartender
Posts: 2752
38
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I think the more important question is: does it have an impact that is noticeable to users? Most JVMs do not run at maximum CPU load, so even if monitoring has an overhead, users may not notice it. And if by monitoring a live system you figure out a performance problem and subsequently fix it, then that's going to help users a lot more than the overhead of monitoring takes form them while it's going on. (Presumably you would not have the JMX monitoring run at all times.)
 
Rudraksh Kreshak
Greenhorn
Posts: 4
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Thanks Tom, however, I was curious about what's going on behind the scenes, once we start a remote JVM with com.sun.management.jmxremote argument, it starts the mbean server and open a rmi connector port to start serving client (typically jconsole's) request.
Now 2 things can happen at the time of retrieving and displaying Memory Usage (for example):
1. Jconsole requests the 'Memory Usage' of a Memory Pool
1.1 The request hit the remote MBean Server and retrieves the corresponding MemoryPoolMXBean Object.
1.2 Calls the getUsage() method of the MBean which in turn calls some native API [getUsage0()] to calculate the 'Memory Usage' on the fly and returns the same.

2. Once we start any JVM with JMX param enabled, a background Thread kicks off and every micro second interval it calculates the 'Memory Usage' of all available Memory Pools and stores it in some Data Structure, once JConsole requests the Memory Usage of a Pool..
2.1 The Request hit the remote MBean and retrieves the corresponding MemoryPoolMXBean Object.
2.2 Calls getUsage() method of the MBean which in turn retrieve the most recent Usage from the Data Structure and returns it to the JConsole.

I guess its the former one which takes place.
 
Chris Hurst
Ranch Hand
Posts: 443
3
C++ Eclipse IDE Java
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
This was actually with Visual VM (new JConsole ;-) )..

At one point I was debugging memory usage reported on an application and I had the app at zero load but no there was all this memory being used ... of course it turned out it was the fact I was watching that was causing the memory churn due to its RMI connection ;-)
 
Rudraksh Kreshak
Greenhorn
Posts: 4
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Thanks Chris for your reply.
But which one of the below 2 Steps is true.

Step A:
1. Jconsole requests the 'Memory Usage' of a Memory Pool
1.1 The request hit the remote MBean Server and retrieves the corresponding MemoryPoolMXBean Object.
1.2 Calls the getUsage() method of the MBean which in turn calls some native API [getUsage0()] to calculate the 'Memory Usage' on the fly and returns the same.

Step B:
2. Once we start any remote JVM with JMX param enabled, a background Thread (in the remote JVM) kicks off and every micro second interval it calculates the 'Memory Usage' of all available Memory Pools and stores it in some Data Structure, once JConsole requests the Memory Usage of a Pool..
2.1 The Request hit the remote MBean and retrieves the corresponding MemoryPoolMXBean Object.
2.2 Calls getUsage() method of the MBean which in turn retrieve the most recent Usage from the Data Structure and returns it to the JConsole
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic