From: Bill Clarke-Fields [mailto:[EMAIL PROTECTED]
If it turns out to be so, is there
anything I can do to force it to not page out the JVM heap?
There's cheap and there's messy :-).
The cheap way: Set up a job that runs overnight that exercises your app.
It should keep the critical files
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Peter,
Peter Crowther wrote:
The messy way: Run Tomcat as an admin (ick!) and make a JNI call to
some native code that pins Tomcat's address space into RAM.
Messy indeed.
I have not tried this, don't know whether there's a correct JVM way
of
From: Christopher Schultz [mailto:[EMAIL PROTECTED]
My experience with JNI is that you have to pin objects one at a time.
To be clear: I wasn't talking about pinning Java objects to particular
addresses in memory, instead pinning the entire process address space
into memory using Win32 API
From: Christopher Schultz [mailto:[EMAIL PROTECTED]
Subject: Re: Very Long Full GC after Inactivity
My experience with JNI is that you have to pin objects one at a time.
Peter's not talking about the JNI pin function, which only prevents
objects from moving around in the JVM heap
From: Bill Clarke-Fields [mailto:[EMAIL PROTECTED]
We are running an application on Tomcat 5.0.28 with Java
1.4.2. The usage
of the application is very cyclical. It is used heavily
during the day, and
lightly at night. During peak daytime hours, a full garbage
collection
takes less
@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
View this message in context:
http://www.nabble.com/Very-Long-Full-GC-after-Inactivity-tf4589459.html#a13118297
Sent from the Tomcat - User mailing list archive at Nabble.com
larger objects?)
Thanks for your help.
-Bill
p.s. Upgrading to a newer version of Tomcat or Java is unfortunately not an
option at this point.
--
View this message in context:
http://www.nabble.com/Very-Long-Full-GC-after-Inactivity-tf4589459.html#a13100609
Sent from the Tomcat - User mailing
Hi,
check the jvm runs in server mode (check there is a '-server'
parameter given to jvm startup). Server and client mode have different
GC mecanisms.
Bill Clarke-Fields a écrit :
Hi,
We are running an application on Tomcat 5.0.28 with Java 1.4.2. The usage
of the application is very
From: David Delbecq [mailto:[EMAIL PROTECTED]
Subject: Re: Very Long Full GC after Inactivity
check the jvm runs in server mode (check there is a '-server'
parameter given to jvm startup). Server and client mode have different
GC mecanisms.
That's not correct; the set of GC algorithms
.
-
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
View this message in context:
http://www.nabble.com/Very-Long-Full-GC-after-Inactivity
this message in context:
http://www.nabble.com/Very-Long-Full-GC-after-Inactivity-tf4589459.html#a13101470
Sent from the Tomcat - User mailing list archive at Nabble.com.
-
To start a new topic, e-mail: users@tomcat.apache.org
From: Bill Clarke-Fields [mailto:[EMAIL PROTECTED]
Subject: Re: Very Long Full GC after Inactivity
Tomcat is running as a Windows service, and the jvm startup
parameter is set to: C:\j2sdk1.4.2_11\jre\bin\server\jvm.dll.
Do I also need to pass a -server parameter
From: Bill Clarke-Fields [mailto:[EMAIL PROTECTED]
Subject: RE: Very Long Full GC after Inactivity
The problem is that off-hours usage is very different, and
leads to these very long full GCs.
GC pause time is largely dependent on the number of live objects
existing at the time of the GC
:
From: Bill Clarke-Fields [mailto:[EMAIL PROTECTED]
Subject: RE: Very Long Full GC after Inactivity
The problem is that off-hours usage is very different, and
leads to these very long full GCs.
GC pause time is largely dependent on the number of live objects
existing at the time of the GC, so
From: Bill Clarke-Fields [mailto:[EMAIL PROTECTED]
Subject: RE: Very Long Full GC after Inactivity
I'm just throwing ideas out now, but would it help to set a
lower value for the -Xms parameter?
Probably not. For best throughput, you generally want -Xms and -Xmx to
be the same
garbage collection is a reactive process, ie, it wont kick in until it
really needs to.
and the time it takes for the GC, depends on your java heap size, -Xmx,
in JDK 1.5 you can specify GC goals like
-XX:MaxGCMinorPauseMillis=value
-XX:MaxGCPauseMillis=value
to tell the JVM to try to align
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Bill,
Bill Clarke-Fields wrote:
Or, is there a way to schedule (or force) full garbage collections?
Not really. You can issue a call to Runtime.gc(), but it's not
guaranteed to do anything at all. My experience has been that the JVM
does respect
Just a hypothesis.
During these off-peak hours some other applications are actively running
(maintenance etc.), and as java is not intensively used, its memory is swapped
to the hard disks.
Thus, when it awakens and does the GC, it takes so much time to wake up
the memory walking through it to
18 matches
Mail list logo
