graph doesn't change with resolution-seconds?

[Ted]

hey I'm trying to get a higher resolution right now and so I changed
javamelody.resolution-seconds=15, I cleaned out my data directory as
well.

The new rrd files are about 104k so they've definitly increased in
size.... from the previous 36K, but the graphs look the same.

Even when I zoom in on the graphs, it appears to have at best 1 pixel
per minute on the horizontal axis.

Anyone know what's up wit this?

[Vernat Emeric]

Hi,

I have understood what you said but not what you means.
That's because when I zoom in on a day chart, and zoom again using the
slider, then there is currently a maximum of 60 pixels displayed per
hour (1 pixel per minute). And that's a graph which is 1680 pixels wide,
just for a day.

How can it be more precise? Do you want a larger graph?
Perhaps you can send your image file for us to understand.

Note that with such a resolution, you will have more exact day graphs
anyway: with more values, you have better interpolation.

bye,
Emeric

Le 29/02/2012 01:13, Ted a �crit :

[Ted]

yes that's exactly my problem, Right now the graph shows 1 pixel per minute, I want the graph to show 1 pixel every 5 seconds or 10 seconds or 15 seconds.

yes I know the graph would be very wide, but a horizontal slider should solve that, or instead of making it a day graph if it were a 1 hour graph or 2 hours graph.

The resolution is important if you're tuning individual pools because that's how you can tell what the minimum and maximum usage of a given pool is. If the resolution is too coarse like 1 minute, then the garbage collector may have run a few times in that time interval.

Basically I need to see what jconsole sees. I need to be able to see the memory graph in an interval of a few seconds, and I need the memory graphs for each pool. With out this information it's is difficult to tune a jvm memory settings properly on high load systems.

I already submitted a patch for showing the different jvm pools (but it's still sitting there unapproved/merged), if there's currently no way to see a higher resolution graph then I can look into submitting a patch for that too, I just thought that the resolution-seconds may have done that and I may have been using it wrong or not clearing the files properly.

let me know.
ted.

On Sunday, 4 March 2012 08:54:20 UTC+11, evernat wrote:

Hi,

I have understood what you said but not what you means.
That's because when I zoom in on a day chart, and zoom again using the
slider, then there is currently a maximum of 60 pixels displayed per
hour (1 pixel per minute). And that's a graph which is 1680 pixels wide,
just for a day.

How can it be more precise? Do you want a larger graph?
Perhaps you can send your image file for us to understand.

Note that with such a resolution, you will have more exact day graphs
anyway: with more values, you have better interpolation.

bye,
Emeric

Le 29/02/2012 01:13, Ted a �crit :

[evernat]

Hi Ted,

You said: "Basically I need to see what jconsole sees. I need to be

able to see the memory graph in an interval of a few seconds, and I
need the memory graphs for each pool."

In fact, jconsole and jvisualvm do not have the same goals and
constraints than javamelody.

In short, jconsole is good enough to see short live data such as used
memory or some particular memory pool or some obscure MBean value. You
tipically connect it to QA or production for 5 minutes or for 1 hour
in order to see some specific value, and then you disconnect it. And
because there is no storage in jconsole, you lost all the values you
have seen.

Whereas javamelody is always there in QA and production, storing and
aggregating many values for days, or months (2 years of data max,
currently not configurable), and if asked giving html, pdf or xml
reports.
And the resolution-seconds in javamelody is NOT supposed to be as low
as 10 seconds in general, because you would increase much the overhead
with all the values collected and stored. And too much overhead is "no
way" in production. (The default "resolution-seconds" is 60 seconds.)


So for 10 minutes or 1 hour, you want to have very precise data of the
used memory in order to fine tune some JVM parameter?
I would suggest: "No problem, just connect jconsole, the precise data
(without storage) is just there in the first screen. Then
disconnect.", because it was written for that.
Of course, if you want to see the graph of the used memory for all day
or all week, javamelody will be your friend.


That said, if you also want to have big graphs in javamelody with your
data in your particular case, you can look at the URL of the image for
a graph.
There are width and height parameters: you can ask for any width you
want in the URL ...
Except that, a max is in the code to refuse very high values of width
for the graph:
http://code.google.com/p/javamelody/source/browse/trunk/javamelody-core/src/main/java/net/bull/javamelody/MonitoringController.java#444

You can download the source, change the max in the code and compile.
(The DevGuide gives information and an ant task or maven goal to make
a new jar.)
Then you can also have big graphs in javamelody.

bye,
Emeric

PS: I will certainly look at the enhancement about the memory pools
another day

[evernat]

For the anecdote, a DevOp should look at graph of GC logs once in his/
her life.

A long time ago, I have been myself looking at GC logs for some weeks
while chasing a JVM memory leak.
It was finally found to be caused by the windows screen saver.
But this was very "relative": it was going away when we were observing
it ;-)

Emeric

> for the graph:http://code.google.com/p/javamelody/source/browse/trunk/javamelody-co...

> > > Le 29/02/2012 01:13, Ted a crit :