Tuning suggestions, please?

  • Thread starter Bret Schuhmacher
  • Start date
B

Bret Schuhmacher

Hello all,

I have a program that runs very quickly with one small exception. I'm
trying to tune the performance and I can't track down a 15ms delay. Maybe
you can help. 15ms may not sound like much, but this is supposed to be a
VERY high performing app, and 15ms adds up...

I've got log4j spitting out log statements at the entrance and exit of the
method in question. All the program does is open a file and read the
contents into a bufferedreader, then enter a loop and call the method until
there are no more rows to read. Here are the timings from the log4j log:
2007-07-03 19:40:21,678 INFO
2007-07-03 19:40:21,678 INFO
2007-07-03 19:40:21,678 INFO
2007-07-03 19:40:21,693 INFO
2007-07-03 19:40:21,693 INFO
2007-07-03 19:40:21,709 INFO
2007-07-03 19:40:21,709 INFO
2007-07-03 19:40:21,709 INFO
2007-07-03 19:40:21,725 INFO
2007-07-03 19:40:21,725 INFO
2007-07-03 19:40:21,740 INFO
2007-07-03 19:40:21,740 INFO
2007-07-03 19:40:21,740 INFO
2007-07-03 19:40:21,756 INFO
2007-07-03 19:40:21,756 INFO
2007-07-03 19:40:21,771 INFO
2007-07-03 19:40:21,771 INFO
2007-07-03 19:40:21,771 INFO
2007-07-03 19:40:21,787 INFO
2007-07-03 19:40:21,787 INFO
2007-07-03 19:40:21,787 INFO
2007-07-03 19:40:21,803 INFO
2007-07-03 19:40:21,803 INFO
2007-07-03 19:40:21,803 INFO
2007-07-03 19:40:21,818 INFO
2007-07-03 19:40:21,818 INFO
2007-07-03 19:40:21,818 INFO
2007-07-03 19:40:21,834 INFO
2007-07-03 19:40:21,834 INFO
2007-07-03 19:40:21,850 INFO
2007-07-03 19:40:21,850 INFO
2007-07-03 19:40:21,850 INFO
2007-07-03 19:40:21,865 INFO
2007-07-03 19:40:21,865 INFO
2007-07-03 19:40:21,865 INFO
2007-07-03 19:40:21,881 INFO

Notice the 15ms delay every so often? I'll get about 3 calls to the method
in the same millisecond, then it'll delay about 15-16ms, and continue. I
thought it was garbage collection, but if it is, I can't find the 15ms. And
GC wouldn't run so frequently, would it? I'm running inside the Informix
JRE (it's an IBM recompiled 1.4.2) and Sun 1.5.0_6. In the Sun JRE I use
the following tuning: -Xms128m -Xmx768m -XX:MaxPermSize=128m
-XX:+UseParallelGC -verbosegc -XX:MaxNewSize=32M -XX:NewSize=32M. That
shows me this info:

[GC 24576K->1121K(126976K), 0.0162035 secs]
[GC 25697K->1120K(126976K), 0.0185842 secs]
[GC 25696K->1121K(126976K), 0.0144689 secs]
[GC 25697K->1121K(126976K), 0.0177961 secs]
[GC 25697K->1109K(126976K), 0.0154531 secs]
[GC 25685K->1113K(129920K), 0.0149296 secs]
[GC 31577K->1137K(128512K), 0.0141060 secs]
[GC 31281K->1137K(129408K), 0.0029744 secs]
[GC 30833K->1137K(128064K), 0.0011108 secs]
[GC 30833K->1137K(129344K), 0.0010085 secs]
[GC 30577K->1121K(129408K), 0.0044000 secs]
[GC 30561K->1121K(129408K), 0.0015647 secs]
[GC 30561K->1121K(129408K), 0.0035977 secs]
[GC 30561K->1121K(129472K), 0.0015692 secs]
[GC 30625K->1121K(129408K), 0.0011789 secs]
[GC 30625K->1121K(129536K), 0.0029607 secs]
[GC 30753K->1121K(129472K), 0.0025517 secs]
[GC 30753K->1137K(129664K), 0.0014398 secs]
[GC 31025K->1121K(129600K), 0.0014365 secs]
[GC 31009K->1121K(129792K), 0.0009292 secs]

Any idea what might cause this 15ms delay? Any other avenues I should be
looking into? FWIW, I got the 15ms delay before I added any JVM arguments
(i.e. they didn't cause the problem). I only added the JVM args to try to
figure out the issue.

Thanks in advance for your thoughts and suggestions!

Rgds,

Bret
 
T

Twisted

I've got log4j spitting out log statements at the entrance and exit of the
method in question. All the program does is open a file and read the
contents into a bufferedreader, then enter a loop and call the method until
there are no more rows to read.
Click to expand...
Notice the 15ms delay every so often? I'll get about 3 calls to the method
in the same millisecond, then it'll delay about 15-16ms, and continue.
Click to expand...

It's probably just when the BufferedReader has to fetch more data from
the disk. If one row is about 256 bytes and the buffer in the
BufferedReader is 1K, it will indeed grab more data from the disk
about every fourth call.

It may be possible to tweak BufferedReader to a larger buffer size, or
use NIO to get double-buffering where it will fill up one buffer while
your code reads from another then switch.
 
B

Bret Schuhmacher

Thanks for the quick reply! Unfortunately I don't think it's the
BufferedReader. I first noticed the problem when the method in question was
called from Informix as a User Defined Routine and there was no
BufferedReader. I added a main() and some code to open a flat file today to
see if Informix was the issue and the problem persisted exactly as it had
under Informix - 15ms delays.

Thanks very much for the response, though.

Rgds,

Bret
 
T

Twisted

Thanks for the quick reply! Unfortunately I don't think it's the
BufferedReader. I first noticed the problem when the method in question was
called from Informix as a User Defined Routine and there was no
BufferedReader. I added a main() and some code to open a flat file today to
see if Informix was the issue and the problem persisted exactly as it had
under Informix - 15ms delays.
Click to expand...

Well there's a few other things it could be:
* Another Java thread is doing stuff -- anything from incremental
GCs to the random things I see in Eclipse's debugger from time to
time like "JVM termination thread", "Finalization thread", and "AWT
image fetcher thread". These manage a bunch of stuff under the hood.
Some only for graphical apps; others for any app, to finalize dead
objects with nontrivial finalize() methods, handle reference queues,
and etc.
* JIT compiling (but that should stop after a few iterations when
it's fully optimized)
* The JVM is simply doing something weird
* Something else on the host system is hogging the CPU and yielding
timeslices every 15 ms that are just long enough for the Java task
to get a few iterations in
* The OS you're running it on is doing something weird (Windoze
by any chance?)
* The very hardware you're running it on is doing something weird
Thanks very much for the response, though.
Click to expand...

YW.
 
P

pascal.lecointe

Hello all,

I have a program that runs very quickly with one small exception. I'm
trying to tune the performance and I can't track down a 15ms delay. Maybe
you can help. 15ms may not sound like much, but this is supposed to be a
VERY high performing app, and 15ms adds up...

I've got log4j spitting out log statements at the entrance and exit of the
method in question. All the program does is open a file and read the
contents into a bufferedreader, then enter a loop and call the method until
there are no more rows to read. Here are the timings from the log4j log:
2007-07-03 19:40:21,678 INFO
2007-07-03 19:40:21,678 INFO
2007-07-03 19:40:21,678 INFO
2007-07-03 19:40:21,693 INFO
2007-07-03 19:40:21,693 INFO
2007-07-03 19:40:21,709 INFO
2007-07-03 19:40:21,709 INFO
2007-07-03 19:40:21,709 INFO
2007-07-03 19:40:21,725 INFO
2007-07-03 19:40:21,725 INFO
2007-07-03 19:40:21,740 INFO
2007-07-03 19:40:21,740 INFO
2007-07-03 19:40:21,740 INFO
2007-07-03 19:40:21,756 INFO
2007-07-03 19:40:21,756 INFO
2007-07-03 19:40:21,771 INFO
2007-07-03 19:40:21,771 INFO
2007-07-03 19:40:21,771 INFO
2007-07-03 19:40:21,787 INFO
2007-07-03 19:40:21,787 INFO
2007-07-03 19:40:21,787 INFO
2007-07-03 19:40:21,803 INFO
2007-07-03 19:40:21,803 INFO
2007-07-03 19:40:21,803 INFO
2007-07-03 19:40:21,818 INFO
2007-07-03 19:40:21,818 INFO
2007-07-03 19:40:21,818 INFO
2007-07-03 19:40:21,834 INFO
2007-07-03 19:40:21,834 INFO
2007-07-03 19:40:21,850 INFO
2007-07-03 19:40:21,850 INFO
2007-07-03 19:40:21,850 INFO
2007-07-03 19:40:21,865 INFO
2007-07-03 19:40:21,865 INFO
2007-07-03 19:40:21,865 INFO
2007-07-03 19:40:21,881 INFO

Notice the 15ms delay every so often? I'll get about 3 calls to the method
in the same millisecond, then it'll delay about 15-16ms, and continue. I
thought it was garbage collection, but if it is, I can't find the 15ms. And
GC wouldn't run so frequently, would it? I'm running inside the Informix
JRE (it's an IBM recompiled 1.4.2) and Sun 1.5.0_6. In the Sun JRE I use
the following tuning: -Xms128m -Xmx768m -XX:MaxPermSize=128m
-XX:+UseParallelGC -verbosegc -XX:MaxNewSize=32M -XX:NewSize=32M. That
shows me this info:

[GC 24576K->1121K(126976K), 0.0162035 secs]
[GC 25697K->1120K(126976K), 0.0185842 secs]
[GC 25696K->1121K(126976K), 0.0144689 secs]
[GC 25697K->1121K(126976K), 0.0177961 secs]
[GC 25697K->1109K(126976K), 0.0154531 secs]
[GC 25685K->1113K(129920K), 0.0149296 secs]
[GC 31577K->1137K(128512K), 0.0141060 secs]
[GC 31281K->1137K(129408K), 0.0029744 secs]
[GC 30833K->1137K(128064K), 0.0011108 secs]
[GC 30833K->1137K(129344K), 0.0010085 secs]
[GC 30577K->1121K(129408K), 0.0044000 secs]
[GC 30561K->1121K(129408K), 0.0015647 secs]
[GC 30561K->1121K(129408K), 0.0035977 secs]
[GC 30561K->1121K(129472K), 0.0015692 secs]
[GC 30625K->1121K(129408K), 0.0011789 secs]
[GC 30625K->1121K(129536K), 0.0029607 secs]
[GC 30753K->1121K(129472K), 0.0025517 secs]
[GC 30753K->1137K(129664K), 0.0014398 secs]
[GC 31025K->1121K(129600K), 0.0014365 secs]
[GC 31009K->1121K(129792K), 0.0009292 secs]

Any idea what might cause this 15ms delay? Any other avenues I should be
looking into? FWIW, I got the 15ms delay before I added any JVM arguments
(i.e. they didn't cause the problem). I only added the JVM args to try to
figure out the issue.

Thanks in advance for your thoughts and suggestions!

Rgds,

Bret
Click to expand...

If I remember coreectly, the frequency of the user clock timer on
windows is between 15 and 16 ms, so you can't have a better resolution
within Java 1.4.

Since Java5 (or Java6, don't remember), there is the new method
System.nanoTime(), which has a much better resolution (use another
clock timer of the OS)
 
J

Juha Laiho

Bret Schuhmacher said:
Hello all,

I have a program that runs very quickly with one small exception. I'm
trying to tune the performance and I can't track down a 15ms delay. Maybe
you can help. 15ms may not sound like much, but this is supposed to be a
VERY high performing app, and 15ms adds up...
Click to expand...

Could it be OS context switches; is there something else in the machine
doing something, and thus stealing the CPU every now and then?
 
N

Nigel Wade

Bret said:
Hello all,

I have a program that runs very quickly with one small exception. I'm
trying to tune the performance and I can't track down a 15ms delay. Maybe
you can help. 15ms may not sound like much, but this is supposed to be a
VERY high performing app, and 15ms adds up...

I've got log4j spitting out log statements at the entrance and exit of the
method in question. All the program does is open a file and read the
contents into a bufferedreader, then enter a loop and call the method until
there are no more rows to read. Here are the timings from the log4j log:
2007-07-03 19:40:21,678 INFO
2007-07-03 19:40:21,678 INFO
2007-07-03 19:40:21,678 INFO
2007-07-03 19:40:21,693 INFO
2007-07-03 19:40:21,693 INFO
2007-07-03 19:40:21,709 INFO
2007-07-03 19:40:21,709 INFO
2007-07-03 19:40:21,709 INFO
2007-07-03 19:40:21,725 INFO
2007-07-03 19:40:21,725 INFO
2007-07-03 19:40:21,740 INFO
2007-07-03 19:40:21,740 INFO
2007-07-03 19:40:21,740 INFO
2007-07-03 19:40:21,756 INFO
2007-07-03 19:40:21,756 INFO
2007-07-03 19:40:21,771 INFO
2007-07-03 19:40:21,771 INFO
2007-07-03 19:40:21,771 INFO
2007-07-03 19:40:21,787 INFO
2007-07-03 19:40:21,787 INFO
2007-07-03 19:40:21,787 INFO
2007-07-03 19:40:21,803 INFO
2007-07-03 19:40:21,803 INFO
2007-07-03 19:40:21,803 INFO
2007-07-03 19:40:21,818 INFO
2007-07-03 19:40:21,818 INFO
2007-07-03 19:40:21,818 INFO
2007-07-03 19:40:21,834 INFO
2007-07-03 19:40:21,834 INFO
2007-07-03 19:40:21,850 INFO
2007-07-03 19:40:21,850 INFO
2007-07-03 19:40:21,850 INFO
2007-07-03 19:40:21,865 INFO
2007-07-03 19:40:21,865 INFO
2007-07-03 19:40:21,865 INFO
2007-07-03 19:40:21,881 INFO
Click to expand...
Any idea what might cause this 15ms delay? A
Click to expand...

I don't think it's a 15ms delay, rather it's the resolution of the clock. On my
Windows XP laptop the resolution is exactly 10ms. On my Linux desktop the
resolution is 1ms.

Try this simple piece of code to see what your resolution is. It outputs the
difference in mS of the clock every time the clock generates a new value, along
with the number of times that it was able to create a new Date() (with the same
value) during that interval.

import java.util.Date;
public class TestClock {

public static void main(String[] args) {
int count = 0;
Date olddate = new Date();
while(true) {
Date date = new Date();
if ( date.after(olddate)) {
long step = date.getTime() - olddate.getTime();
System.out.println(step+" "+count);
olddate = date;
count = 0;
}
else {
count++;
}

}
}

}
 
B

Bret Schuhmacher

Thanks for the code, Nigel. Here's the output:
15 193573
16 186582
16 190201
15 183223
16 116424
16 123012
15 100954
16 183436
15 170407
16 180246
16 195359
15 186473
16 190119
16 148391
..
..
..

Looks like the timer resolution on my laptop running Windows XP is 15-16ms -
consistent with the 15-16 ms I was trying to track down.

I originally saw the issue at a customer's site on an AIX v5.2 box and
replicated it on my Windows laptop. Is it possible an AIX box has the same
timer resolution a Windows box does? I see the same issues inside and
outside of Eclipse, as well as under different JVM versions (for those of
you who were asking).

Is there *anything* I can do about this? Sounds like it's hardwired into
the CPU. I tried adding this:
Thread thisThread = Thread.currentThread();
thisThread.setPriority(Thread.MAX_PRIORITY);
But it didn't help.

Are there other ways of dedicating a CPU or increasing the timeslice or
priority to a thread in Java? Would it help?

Thanks again, Nigel!

Rgds,

Bret
 
R

Roedy Green

And
GC wouldn't run so frequently, would it?
Click to expand...

I wish I could remember what the tool was I used, (might have just
been IntelliJ) but it let me know every time GC ran. I was amazed at
how frequent it was. It seemed to do big gcs and little gcs.

One type of optimisation I have not seen much attention paid to is
reducing the frequency of garbage collection by avoiding creating new
objects uncessarily, particularly large objects like a buffer to read
on entire file into RAM.

Other possible culprits:

1. some other task on your machine, e.g. indexing, mail check, cache
flushing. You might run the resource monity with and without your
code to see what other tasks are up to.

2. you should see a couple of pauses for HotSpot to do some
optimisation.

As a practical matter, consider Jet to ultra optimise this code. See
http://mindprod.com/jgloss/jet.html
'
 
N

Nigel Wade

Bret said:
Thanks for the code, Nigel. Here's the output:
15 193573
16 186582
16 190201
15 183223
16 116424
16 123012
15 100954
16 183436
15 170407
16 180246
16 195359
15 186473
16 190119
16 148391
.
.
.

Looks like the timer resolution on my laptop running Windows XP is 15-16ms -
consistent with the 15-16 ms I was trying to track down.

I originally saw the issue at a customer's site on an AIX v5.2 box and
replicated it on my Windows laptop. Is it possible an AIX box has the same
timer resolution a Windows box does? I see the same issues inside and
outside of Eclipse, as well as under different JVM versions (for those of
you who were asking).

Is there *anything* I can do about this? Sounds like it's hardwired into
the CPU. I tried adding this:
Thread thisThread = Thread.currentThread();
thisThread.setPriority(Thread.MAX_PRIORITY);
But it didn't help.

Are there other ways of dedicating a CPU or increasing the timeslice or
priority to a thread in Java? Would it help?

Thanks again, Nigel!

Rgds,

Bret
Click to expand...

You don't need to do anything. Your CPU is getting 100% (or pretty much). The
only issue is the time resolution - you can't resolve the time to better than
15ms.

In the above test output you can see that during the 15ms resolution of your
clock the code is actually running round the loop between 100,000 and 200,000
times.
 
P

Patricia Shanahan

Bret said:
Thanks for the code, Nigel. Here's the output:
15 193573
16 186582
16 190201
15 183223
16 116424
16 123012
15 100954
16 183436
15 170407
16 180246
16 195359
15 186473
16 190119
16 148391
.
.
.

Looks like the timer resolution on my laptop running Windows XP is 15-16ms -
consistent with the 15-16 ms I was trying to track down.

I originally saw the issue at a customer's site on an AIX v5.2 box and
replicated it on my Windows laptop. Is it possible an AIX box has the same
timer resolution a Windows box does? I see the same issues inside and
outside of Eclipse, as well as under different JVM versions (for those of
you who were asking).

Is there *anything* I can do about this? Sounds like it's hardwired into
the CPU. I tried adding this:
Thread thisThread = Thread.currentThread();
thisThread.setPriority(Thread.MAX_PRIORITY);
But it didn't help.

Are there other ways of dedicating a CPU or increasing the timeslice or
priority to a thread in Java? Would it help?
Click to expand...

You still seem to be looking for something like context switches that
would cause intermittent delays. However, the message from the timer
resolution measurement is that all you know is the average time for a
series of calls. Maybe there are intermittent delays. Maybe every single
call takes between 8.5 and 8.7 milliseconds. Both are consistent with
the data.

The next step should be to redo the measurement, using
System.nanoTime(). That will tell you what type of problem you are
looking for.

Patricia
 
B

Bjorn Borud

["Bret Schuhmacher" <[email protected]>]
|
| Looks like the timer resolution on my laptop running Windows XP is 15-16ms -
| consistent with the 15-16 ms I was trying to track down.

if it is a timer-resolution problem then why not increase the number
of times the calculation is run between sampling of the clock? if you
run it 10, 100 and 1000 times you should be less and less dependent on
the resolution of the timer.

(other factors may come into play, like GC, but I don't think this
should be an issue here. anyway, make sure that the heap is large
enough so that the young generation comfortably can cope with all the
(transient) objects allocated during the calculation. not that I
suspect this to be a problem here (I'd have to take a look at the
code), but if all your objects are really short-lived, you will
actually lessen the GC burden).

(oh, and you should check if there are any differences in running the
code in -server or -client mode).

-Bjørn
 
B

Bjorn Borud

[Roedy Green <[email protected]>]
|
| I wish I could remember what the tool was I used, (might have just
| been IntelliJ) but it let me know every time GC ran. I was amazed at
| how frequent it was. It seemed to do big gcs and little gcs.

probably VisualGC? if you run Java 1.5 or later it should be very
simple to just attach it to a running VM and inspect what the GC
system is doing.

check here:

http://java.sun.com/performance/jvmstat/#Tools

If you see several minor-collections per second then you might have
heap that is too small. also have a look at how the tenured
generation grows.

the hardest thing to optimize is code that keeps filling up the
tenured generation, triggering major collections. (a few years ago I
had an application that strained the GC a lot. turned out that by
getting rid of some caches in the application¹, I got much smoother
overall performance since the system wasn't doing major collections as
often)

¹) the assumption of the programmer who put them there was possibly
that these would make the system faster since he was used to the
expense of frequent object creation and destruction in C++. it
turned out that in this case the cache just slowed things down
and that instantiation of the classes in question was pretty
quick anyway.


| One type of optimisation I have not seen much attention paid to is
| reducing the frequency of garbage collection by avoiding creating new
| objects uncessarily, particularly large objects like a buffer to read
| on entire file into RAM.

well, and then hanging on to them for so long that they go into the
tenured generation. remember, if you get rid of the object *quickly*
it won't have to be copied during a number of minor collections and it
won't end up in the tenured generation -- which is significantly
slower to garbage collect.

-Bjørn
 
D

David Gourley

Juha said:
Could it be OS context switches; is there something else in the machine
doing something, and thus stealing the CPU every now and then?
Click to expand...

There is a virtual machine thread which wakes up and does some stuff
every 20 ms.. (This might show up as introducing pauses on single
CPUs). (you can see this effect if you look at a JVM running with a
kernel profiler e.g. prospect on hpux). Also on single CPU boxes, some
kernel threads will periodically steal cycles (e.g. to flush file cache).

Another thing to look out for (as your thread looks like it might be CPU
bound) is what's happening to it priority wise. The default scheduler
behaviour on many OSs reduces the priority of long running threads if
they run without yielding the CPU... this behaviour can often be
modified (e.g. using rtsched command on hp-ux, but solaris and windows
have equivalents as well, so I'm guessing AIX does). Setting thread
priority from Java affects base priority but may not stop the priority
from getting adjusted dynamically if that's the default OS scheduling
policy.

You need to do UNIX profiling to see this last effect (shows up as the
priority getting reduced for your application thread, and a large number
of involuntary context switches).

If you're looking to benchmark with the nanosecond routines, you
probably need to double check what system call they map onto.. on some
hardware platforms, the high accuracy time routines can get mapped onto
a fixed CPU (essentially to avoid clock drift between processors) and
this can become a bottleneck.

Cheers

Dave
 
J

Joshua Cranmer

Any idea what might cause this 15ms delay? Any other avenues I should
be looking into? FWIW, I got the 15ms delay before I added any JVM
arguments (i.e. they didn't cause the problem). I only added the JVM
args to try to figure out the issue.
Click to expand...

From the Javadocs:

public static long currentTimeMillis()

Returns the current time in milliseconds. Note that while the unit of
time of the return value is a millisecond, the granularity of the value
depends on the underlying operating system and may be larger. For
example, many operating systems measure time in units of tens of
milliseconds.

I notice the same thing to: when timing, I noticed that all of my times
were nicely divisible by 15 ms (e.g, 4095ms, etc.).

In short: it's the fact that Window's doesn't like telling you that 1ms
has passed.
 
B

Bret Schuhmacher

Thanks for the tips everyone! I do appreciate your input :).

I've run visualgc and the GC time shows 94 collections, 59.81ms and unknown
GC reason. The Eden space graph is up and down like a yo-yo very regularly.
Is that normal? I don't know where the tenured GC is, though. I have an
image of the tool running, but probably can't post it to this non binary
newsgroup. I'll try to extend my heap as you suggested Bjorn - I do see a
lot of GC in the Eden space - it's wild.

Thanks,

Bret
 
W

Wojtek

Bret Schuhmacher wrote :
Thanks for the tips everyone! I do appreciate your input :).

The Eden space graph is up and down like a yo-yo very regularly.
Is that normal?
Click to expand...

I have a Web app where I capture the used memory every ten minutes. The
result is displayed as a bar graph. Even when the app is idle, the used
memory looks like a saw tooth:

* * *
** ** **
*** *** ***
*************
 
T

Twisted

I have a Web app where I capture the used memory every ten minutes. The
result is displayed as a bar graph. Even when the app is idle, the used
memory looks like a saw tooth:

* * *
** ** **
*** *** ***
*************
Click to expand...

Is it really idle? If it's got a GUI all kinds of short-lived FooEvent
objects are buzzing around, and every so often the GC will clear up
the accumulated cruft. If it's doing networking stuff in the
background, that activity also probably involves some rate of object
turnover. You'll see a sawtooth graph like this whenever the rate of
object turnover isn't basically zero.
 
W

Wojtek

Twisted wrote :
Is it really idle? If it's got a GUI all kinds of short-lived FooEvent
objects are buzzing around, and every so often the GC will clear up
the accumulated cruft. If it's doing networking stuff in the
background, that activity also probably involves some rate of object
turnover. You'll see a sawtooth graph like this whenever the rate of
object turnover isn't basically zero.
Click to expand...

It is a Web application. When no hits are happening, it should be doing
nothing. And my code does no networking.

Mind you I do have several timers running, but then the memory use goes
from 30M to 74M over a 2 hour period, then drops back to 30M, which
seems kind of excessive for timers.
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Similar Threads

Garbage Collector Tuning? 3
Question about loggers 26
Tomcat keeps crashing on low activity site, any suggestions? 4
Custom Minecraft launcher client error; I think regarding java 0
Need help with incremental GC failure 0
Need help with incremental GC failure 0
reason for sporadic long full GC pause times?!?.... 0
[ANN] punch-0.0.1 4

Members online

Total: 42 (members: 2, guests: 40)
Robots: 56

Forum statistics

Threads
473,997
Messages
2,570,240
Members
46,829
Latest member
KimberAlli

Latest Threads

Top