performance problem when running java applications overnight

[york]

Hi,

I'm having problems with Java applications that I use and develop on
Windows systems (I have seen on XP and Win2k, not sure if the same
problem exists under Linux). What happens is that I use the
applications all day long and then go home at night. I leave my
computer running and I may or may not minimize the various
application. At night, the computer remains running but idle with
the console locked (doesn't go into standby or spin down harddrives--I
know, waste of electrity but it is company policy so that the
virus-scan/backups can occur).

The next morning I come in and find that each of the java applications
is very sluggish. This sluggishness continues for several minutes at
which times the applications begin responding more normally. All
other applications (firefox, thunderbird, Windows explorer, etc...)
run normally with no performance problems.

System details:
Pentium4, 2.2GHz, 1GB RAM, WinXP + SP2 + all patches, dual-monitor
1600x1200x32@85 Hz (GeForce2 MX 400 & GeForce4 MX 440). During
problem, I had about 400MB of free memory (was using 600MB).

JBuiler2005:
Running JBuilder 2005 under JRE 1.4.2_05, Windows LAF.
Returning to work, I unlocked my console. I had the application
minimized so I performed a "restore" to bring it back to it's
maximized state. A solid-gray window was painted onto my primary
monitor. It stayed gray for about 5-10 seconds and then the GUI
repainted. I then clicked on the Project menu. Nothing happened for
about 5-10 seconds and then I got the gray background of the menu drop
down which a few seconds later painted to show the menu choices.

Next I went to the Help menu and went to the About dialog.
Performance was fine doing that. I then went back to the Project menu
to click on it. This time, the Project menu drew it's gray background
immediately then things hung for well over 2 minutes. I didn't have
the bright idea of bringing up the task manager to see if the jbuilder
process was taking up CPU cycles so I don't know what it was doing. I
do know that every other application on my computer was responsive and
fast during this time. Eventually the menu painted the menu options
and everything is working perfectly fast now.

So what was JBuilder doing? This happens to me every morning so I
know that there is a problem. I searched and searched for someone
with this question but nobody else seems to be complaining. Am I the
only one seeing this?

My application:
Second application: my own. This swing application runs under JRE5
(1.5.0). It also uses the Windows LAF. When I restored that
application this morning, I got pretty much identical symptoms to what
I got with JBuilder - namely the application restored to the screen
(not maximized in this case) by rendering a gray rectangle to the
screen. The actual GUI did not paint for about 5-10 seconds. Then
various actions in the GUI were very sluggish for the first several
minutes of use and then magically things sped up to normal speed.

This is not a new problem- I've seen this problem as far back as I can
recall. Several times I've gotten fed up and done a search both on
usenet and on Sun's java site but I can never find anybody complaining
about this problem. I'd hate for my users to experience this problem
with my application.

Any ideas? I'm hoping there is some JVM tuning I can do to
minimize/eliminate this problem?

Thanks for your help!
Justin

 

[Skip]

I'm having problems with Java applications that I use and develop on
Windows systems (I have seen on XP and Win2k, not sure if the same
problem exists under Linux). What happens is that I use the
applications all day long and then go home at night. I leave my
computer running and I may or may not minimize the various
application. At night, the computer remains running but idle with
the console locked (doesn't go into standby or spin down harddrives--I
know, waste of electrity but it is company policy so that the
virus-scan/backups can occur).

You might have more than enough _free_ RAM, but the OS will start swapping
anyway (if available). The whole app might be swapped and retreived again in
small parts when those parts are required, which could explain the long time
of interaction with the GUI before everything speeds up again.

If this is the case: the more interaction, the faster things are back to
normal. You could try to disable the pagefile for one night, if possible,
and check the results.

I'd hate for my users to experience this problem with my application.

It isn't really normal to have a GUI open (and inactive) overnight AFAIK.
Little chance this will happen to the average user (if that is your target).

 

[Tim Ward]

The next morning I come in and find that each of the java applications
is very sluggish. This sluggishness continues for several minutes at
which times the applications begin responding more normally. All
other applications (firefox, thunderbird, Windows explorer, etc...)
run normally with no performance problems.

Yea, Java applications do rather seem to behave like that - their attempts
to second-guess how the operating system is going to manage its memory seem
to be seriously out of kilter with how Windows, the world's most commonly
installed desktop OS, actually does so. Whether this is because the relevant
bits of the Java system were designed in blissful ignorance of how Windows
works or whether it was done on purpose to make Linux implementations look
faster is left as an exercise for the reader.

Suggested solution: rewrite in C++.

 

[Will Hartung]

The next morning I come in and find that each of the java applications
is very sluggish. This sluggishness continues for several minutes at
which times the applications begin responding more normally. All
other applications (firefox, thunderbird, Windows explorer, etc...)
run normally with no performance problems.

The problem is simply that during the night, your applications were paged
out and are paging back in as you use them.

I have the exact same problem at home with Mozilla on my W2K box. I also
have issue at work on my XP box.

It always depends, but that's basically what's happening.

Regards,

Will Hartung
([email protected])

 

[johndoe]

The problem is simply that during the night, your applications were paged
out and are paging back in as you use them.

I have the exact same problem at home with Mozilla on my W2K box. I also
have issue at work on my XP box.

It always depends, but that's basically what's happening.

I had severe problems with disk thrashing on my Windows box until I
disabled virtual memory.

 

[york]

The problem is simply that during the night, your applications were paged
out and are paging back in as you use them.

I have the exact same problem at home with Mozilla on my W2K box. I also
have issue at work on my XP box.

It always depends, but that's basically what's happening.

Regards,

Will Hartung
([email protected])

Will (and everybody else), thanks for your responses.

I've set my pagefile size on Windows down to zero and the results are
promising. I haven't seen a single slowdown on any of my java apps
today, even when I've left them minimized for a really long time.
Tomorrow morning will be the real test.

The strange thing is, I've never noticed the slowdown on any other
applications. I guess they have smaller memory footprints so they are
not as much affected by paging to disk. It is bizarre to me though
that moving JBuilder back into active RAM would sometimes take over a
minute! Windows XP must have some really crappy paging algorithms!

So far my 1GB of memory seems more than ample to allow me do JBuilder
and other applications all at once even with the page file disabled.
The real test will be when I do some profiling using OptimizeIt!

Thanks,
Justin

 

[york]

The problem is simply that during the night, your applications were paged

Will (and everybody else), thanks for your responses.

I've set my pagefile size on Windows down to zero and the results are
promising. I haven't seen a single slowdown on any of my java apps
today, even when I've left them minimized for a really long time.
Tomorrow morning will be the real test.

Just to followup since several of you were kind enough to post
suggestions. Indeed, disabling the page file in Windows has
completely eliminated the problem I described in my original post (see
top of thread). I'm still amazed that this made such a difference but
two full days of running my java applications and they haven't slowed
down once. In fact, the periodic long-pauses that I would experience
in JBuilder even while using it have completely disappeared.

Thanks again to everyone for their feedback. I hope that other's can
use this solution.

Justin

 

[noah]

I've set my pagefile size on Windows down to zero and the results are
One more thing you should think about (anyone reading this)...
Why not set the memory min & max size when the java apps are started
up?

It's very possible that simply setting each of 3 JVMs to run in (just
a rough guess here) < 1/3 of your available memory, you shouldn't have
as much of a swapping problem. Disabling your virtual/swap memory can
be detrimental to common development tasks (i.e. keeping many files
open in editors, background procs such as mysql, etc).


Here's the command-line switch (from 'man java')
-Xmxn Specifies the maximum size of the memory allocation
pool.
This value must be greater than 1000. To modify the meaning of
n, append either the letter k for kilobytes or the letter m for
megabytes. The default value is 64m. The uppoer limit for this
value will be approximately 4000m on SPARC platforms and 2000m on
x86 platforms, minus overhead amounts.

 

[NOBODY]

I got the best solution: don't iconize the application....Seriously.

Windoze still thinks it is in the window 3.1 times, were foreground apps
have more priority...

trick #1:
For example, on my eclipse ide, I resize to whole window to only title bar,
like many window managers do, (window blinds?).
It is not taking any destop space and yet, is not iconized, so not SO
quickly swapped out.

As for JVM, this is heap fragmentation, since the -Xmx may be large but the
jvm has no idea where the 'memory' is (physical or not), then a simple GC
of a single object may cause enire pages to be swept in.


trick #2:
use cacheman (shareware, or other tuning tool) to increase your page I/O
limit (instead of 512 k at a time, that could well be 16 megs they say.)

trick #3:
invoke jvm with the defragment heap garbage collector option (see sun's jvm
tuning gc options webpage)
http://java.sun.com/docs/hotspot/

 

[G Winstanley]

I got the best solution: don't iconize the application....Seriously.

Windoze still thinks it is in the window 3.1 times, were foreground apps
have more priority...

This one can be addressed in part by:
System Properties -> Advanced -> Performance -> Advanced
and selected "Background Services" for the Processor Scheduling option. This
at least gives all programs equal CPU time (allegedly).

Stan

 

[John McGrath]

It's very possible that simply setting each of 3 JVMs to run in (just
a rough guess here) < 1/3 of your available memory, you shouldn't have
as much of a swapping problem.

That presume that Windows will not swap out programs if it has enough
physical memory to store them. While that may seem logical, it is not
the way that Windows behaves.