options to java.exe

[mitsura]

Hi,

in our company we are using an monitoring tool that comes with a
console written in Java. It's a commercial product so we don't have
access to sources or to design info.

What I notice is that this console becomes slow after a few hours.
After a fresh restart the console is snappy again.
I see the memory usage increasing from about 50Mb to 170Mb. After
restart, the memory usage is again 50Mb.
There 'should' be no persistent data in the console itself. What I
mean is that the console gets all it's data from the server so the
data that you see in the console before/after a restart is the same.

My question is, are there any parameters that I can give to Java
runtime that might keep the performance of this console somewhat
constant? It is using j2re1.4.2.
I see that the only parameter given is '-Xmx128m'.


Any help much appreciated.

Kris

 

[Owen Jacobson]

Hi,

in our company we are using an monitoring tool that comes with a
console written in Java. It's a commercial product so we don't have
access to sources or to design info.

What I notice is that this console becomes slow after a few hours.
After a fresh restart the console is snappy again.
I see the memory usage increasing from about 50Mb to 170Mb. After
restart, the memory usage is again 50Mb.

How are you measuring this? The OS process list will only show you
how much memory the JVM itself is using, not how much of that memory
is actually in use by the Java program inside that JVM. You might get
a better picture by turning on verbose garbage collection (-
verbose:gc). Over time the JVM will tend to consume its entire
maximum heap, even if a large portion of that is still unused within
the JVM, and since your maximum heap is set to 128m the JVM using 170
is consistent with that. However, read on...

There 'should' be no persistent data in the console itself. What I
mean is that the console gets all it's data from the server so the
data that you see in the console before/after a restart is the same.

You're right: there "should" be no data kept in the console itself.
The symptoms you're seeing indicate that some objects are being kept
unnecessarily -- that is, that there's a packratting bug in the
console program. If so, no matter what you, do the program will
eventually run low on memory and start to slow down as the JVM spends
more time trying to reclaim space. You can reduce the impact, until
your vendor fixes the bug you're reporting to them, by giving the JVM
more memory (-Xmx512m will set the maximum Java heap size to 512
megabytes rather than 128, for example) and by twiddling some of the
garbage collection parameters (-Xincgc is an easy one to try;
otherwise take a look at the GC tuning guide, below).

There is an exhaustive list of JVM parameters for Sun's Java 1.4, 1.5,
and 6 JVMs at <http://blogs.sun.com/watt/resource/jvm-options-
list.html>. There is also a guide for tuning GC on the 1.4.2 JVM at
<http://java.sun.com/docs/hotspot/gc1.4.2/>.

-o

 

[mitsura]

How are you measuring this? The OS process list will only show you
how much memory the JVM itself is using, not how much of that memory
is actually in use by the Java program inside that JVM. You might get
a better picture by turning on verbose garbage collection (-
verbose:gc). Over time the JVM will tend to consume its entire
maximum heap, even if a large portion of that is still unused within
the JVM, and since your maximum heap is set to 128m the JVM using 170
is consistent with that. However, read on...


You're right: there "should" be no data kept in the console itself.
The symptoms you're seeing indicate that some objects are being kept
unnecessarily -- that is, that there's a packratting bug in the
console program. If so, no matter what you, do the program will
eventually run low on memory and start to slow down as the JVM spends
more time trying to reclaim space. You can reduce the impact, until
your vendor fixes the bug you're reporting to them, by giving the JVM
more memory (-Xmx512m will set the maximum Java heap size to 512
megabytes rather than 128, for example) and by twiddling some of the
garbage collection parameters (-Xincgc is an easy one to try;
otherwise take a look at the GC tuning guide, below).

There is an exhaustive list of JVM parameters for Sun's Java 1.4, 1.5,
and 6 JVMs at <http://blogs.sun.com/watt/resource/jvm-options-
list.html>. There is also a guide for tuning GC on the 1.4.2 JVM at
<http://java.sun.com/docs/hotspot/gc1.4.2/>.

-o

Thanks!

 

[Roedy Green]

My question is, are there any parameters that I can give to Java
runtime that might keep the performance of this console somewhat
constant? It is using j2re1.4.2.
I see that the only parameter given is '-Xmx128m'.

Chances are your app is packratting. You need to monitor it to figure
out what it is needlessly holding onto.

see http://mindprod.com/jgloss/packratting.html
http://mindprod.com/jgloss/profiler.html

 

[Nigel Wade]

Hi,

in our company we are using an monitoring tool that comes with a
console written in Java. It's a commercial product so we don't have
access to sources or to design info.

What I notice is that this console becomes slow after a few hours.
After a fresh restart the console is snappy again.
I see the memory usage increasing from about 50Mb to 170Mb. After
restart, the memory usage is again 50Mb.
There 'should' be no persistent data in the console itself. What I
mean is that the console gets all it's data from the server so the
data that you see in the console before/after a restart is the same.

My question is, are there any parameters that I can give to Java
runtime that might keep the performance of this console somewhat
constant? It is using j2re1.4.2.
I see that the only parameter given is '-Xmx128m'.


Any help much appreciated.

Kris

It depends on why it is running slowly. There could be two main reasons, and
each requires a different remedy.

Specifying -Xmx128m tells the JVM that the maximum heap size it can use is
128MB. If the Java application creates many objects then there is a good chance
that all this heap will be used, and the JVM will use garbage collection to
free unused objects. If the application is creating and destroying a lot of
objects and the heap is full then there will be a lot of garbage collection
going on. If your system has spare physical RAM then you might be able to
alleviate the garbage collection by increasing the heap size. However, if the
application is badly written then this might only serve to increase the
application size until the larger heap is full and the same problem re-occurs.
If this happens there's not a lot you can do, other than contact the software
developers and suggest they might want to improve their code ;-)

If your system is low on physical RAM then the application may be causing page
faulting. If the application can run with a smaller heap then you could try
lowering the max. heap size to avoid page faulting. If the system can be
upgraded you could add in more physical RAM, or stop any other applications
which are using up RAM.