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 cycl
> 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 mecanis
David,
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?
Thanks,
-Bill
David Delbecq-2 wrote:
>
> Hi,
>
> check the jvm runs in "server" mode (check there is a '-server'
: 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 algor
> 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
> 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
es R wrote:
>
>> 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
> 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
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=
-XX:MaxGCPauseMillis=
to tell the JVM to try to align its GC to mee
-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 yo
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 co
> 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
> take
Peter,
Thanks! This is a very good idea. I know that there are some virus scans
and other processes running at night. I will do some monitoring to
determine if paging is the problem. If it turns out to be so, is there
anything I can do to force it to not page out the JVM heap?
Thanks again,
-
> 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
>
> From: Caldarale, Charles R [mailto:[EMAIL PROTECTED]
> Peter's not talking about the JNI pin function, which only prevents
> objects from moving around in the JVM heap, not in RAM. He's
> referring
> to nailing the entire heap into RAM, which is an OS call requiring
> privileges; operations 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 ca
> 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
18 matches
Mail list logo