Forcing �Mark Sweep� Garbage Collection?

I have a fairly complex Java server-based application which is experiencing some memory management problems. As the application runs, it will continue to grow over time. If 5 or 6 instances of the application are running concurrently, eventually the server performance is significantly degraded and the application will crash due to a lack of system memory or system swap space.
When monitoring the application with JConsole, I have noticed that a large number of �Scavenge� garbage collections normally occur. These do not consume much CPU time, but they also do not seem to free much memory. When I manually click the �Perform GC� button, however, that seems to trigger a �MarkSweep� type of garbage collection. This will normally reclaim a huge amount of memory (although it takes a relatively large amount of CPU to perform.)
Is there a way to cause this �MarkSweep� to occur more frequently? I have read that explicitly calling system.gc() in my application is discouraged, and may not even cause any garbage collection to occur. (Although it appears that JConsole is somehow forcing it to occur.) I have also seen it suggested that I could tweak some of the JVM parameters for heap size and ratios, but this approach seems difficult and problematic for my application.
I realize that explicitly forcing MarkSweep collections may cause noticeable pauses in my application. Although that behavior is not ideal, it is tolerable � especially if I can control when the pauses occur. Any suggestions or insight would be appreciated.
Thanks,
Mike H.

Seeing the date of this question my answer will not be in use by the guy who asked but for some one else could be.
I had similar problem - I wanted to release unused memory from the JVM to the OS.
After some research i found that calling several consequent times System.gc() helps. I do the calls with some pause between them (1-2 seconds). This makes the app to be slower at this particular moment but releases hundreds of Megabytes in my case.
I tested with this approach and found that it works only when Serial GC is running, but fortunately this is the GC in most of cases that JVM uses.

Similar Messages

GC taking long time when using Concurrent Mark Sweep GC with Sun JDK 150_12

We are having problem of Garbage collection taking too long. We are using Weblogic 9.2 and Sun JDK 150_12
Below are the memory arguments we are using. We are using Concurrent Mark Sweep GC. What we are observing is Young Generation is getting filled up and consequent tenured generation also hangs with long pauses.
Below are the JVM arguments we are using
-Xms2560M -Xmx2560M -Xloggc:${LOGDIR}/gc.log -XX:+PrintGCTimeStamps -XX:+PrintGCDetails -XX:+UseParNewGC -XX:+UseConcMarkSweepGC -XX:+CMSParallelRemarkEnabled -XX:SurvivorRatio=128 -XX:MaxTenuringThreshold=0 -XX:CMSInitiatingOccupancyFraction=60 -XX:NewSize=512m -XX:MaxNewSize=512m -XX:MaxPermSize=256m
I have seen many forums where there are many reported issues with Concurrent Mark Sweep garbage collection with Sun JDK, but with different recommendations. But did not find any defnite recommendation. Please advice.
- - Tarun

We are having problem of Garbage collection taking too long. We are using Weblogic 9.2 and Sun JDK 150_12
Below are the memory arguments we are using. We are using Concurrent Mark Sweep GC. What we are observing is Young Generation is getting filled up and consequent tenured generation also hangs with long pauses.
Below are the JVM arguments we are using
-Xms2560M -Xmx2560M -Xloggc:${LOGDIR}/gc.log -XX:+PrintGCTimeStamps -XX:+PrintGCDetails -XX:+UseParNewGC -XX:+UseConcMarkSweepGC -XX:+CMSParallelRemarkEnabled -XX:SurvivorRatio=128 -XX:MaxTenuringThreshold=0 -XX:CMSInitiatingOccupancyFraction=60 -XX:NewSize=512m -XX:MaxNewSize=512m -XX:MaxPermSize=256m
I have seen many forums where there are many reported issues with Concurrent Mark Sweep garbage collection with Sun JDK, but with different recommendations. But did not find any defnite recommendation. Please advice.
- - Tarun

Can I force full garbage collection?

Hi, my program is memory bound , as users load more files more memory is required , if the user decides to load a very large number of files they will eventually run out of memory. So I am trying to detect when there is less 15% of heap memory left, then force garbage collection and if it cant free up more than 15% of the heap I will stop the user from loading any more files. But the problem is though I call System.gc() to try and force a full garbage collect it rarely
retrieve enough memory to get below the 15% limit. But using the Yourkit Profiler I can select the Force GarbageCollection option and this always manages to free up more memory to get the figure under the 15% limit. in support of this I found that sometimes my program stop me loading more files when there is still quite a bit available.
So my questions are.
1. I know System.gc() is only hint to garbage collect, but the docs imply it only replys after the garbage collection (if any) has been done, is this right or do I have to wait.
2. Is there any way to Force complete Garbage Collectionas profiler appears to do.
3. is there a VM option I could set instead to force the JVM to completely garbage collect at say 83% so that if I then polled that 85% of heap was being used I would know that it really was, and I wouldnt need to bother trying to garbage collect further. (Im using Suns 1.6. JVM on Windows and Linux, and Apples 1.5 or 1.6 JVM on Macs)
public static void checkMemoryWhilstLoadingFiles() throws LowMemoryException
        MemoryUsage mu = ManagementFactory.getMemoryMXBean().getHeapMemoryUsage();
        //No max defined future proofing
        if(mu.getMax()==-1)
            return;
        if (mu.getUsed() > (mu.getMax() * 0.85f))
            MainWindow.logger.warning("Memory low:" + mu);
            System.gc();
            MainWindow.logger.warning("Memory low gc1:" + ManagementFactory.getMemoryMXBean().getHeapMemoryUsage());
            System.gc();
            MainWindow.logger.warning("Memory low gc2:" + ManagementFactory.getMemoryMXBean().getHeapMemoryUsage());
            System.gc();
            MainWindow.logger.warning("Memory low gc3:" + ManagementFactory.getMemoryMXBean().getHeapMemoryUsage());
            mu = ManagementFactory.getMemoryMXBean().getHeapMemoryUsage();
            if (mu.getUsed() > (mu.getMax() * 0.85f))
                MainWindow.logger.severe("Memory too low:" + mu);
                throw new LowMemoryException("Running out of memory:"+mu.getUsed());
            else
                 MainWindow.logger.warning("Memory usage reduced to:" + mu);
    }thanks for any help Paul
Edited by: paultaylor on 27-Jun-2008 11:10

On all of the current Sun HotSpot JVM's, calling System.gc() will cause a full compacting collection. Unless you have -XX:+DisableExplicitGC on your command line, in which case the call is a noop. Or if you are running the mostly-concurrent collector (-XX:+UseConcMarkSweepGC) and have the -XX:+ExplicitGCInvokesConcurrent flag on your command line, in which case calling System.gc() will start a concurrent collection (and the calling thread will block until the cycle is finished).
But calling System.gc() isn't enough to recover all the space that might be recovered. For example, System.gc() will identify objects that are unreferenced but need to have their finalize() methods called before their space becomes available again. So one call to System.gc() won't recover their space. Those finalize() methods need some cycles to run in, so back-to-back (or back-to-back-to-back :-) calls to System.gc() won't help. If you use a lot of finalize() methods, you should leave a lot of time for the finalize() methods to run between the calls to System.gc(). (Better would be to convert your code to use WeakReferences and run your own reference processing queues, and then you could tell when you were done processing references. But that's real work.) Some people try calling System.runFinalization() and wait for that to return, but that has at least two failure modes (details left to the reader).
In addition, there are details like: if there is still 15% of the heap free, then we won't aggressively clear SoftReferences when you call System.gc(). We might if you waited until the heap was full and we collected it on our own, since we know how much free space there will be after a collection at the point where we are choosing which SoftReferences to clear, and use that to decide how aggressively to clear SoftReferences.
There is no method to force the collector to do a compacting collection at, say 85% full. There is an option to have the mostly-concurrent collector start a collection cycle that way. But there's no way to find out if a collection cycle is running.
You are skating on the edge of the qualities of service offered by the different collectors in the various JVM's available. That weakens your ability to "write once, run anywhere".

Interpreting Concurrent Mark Sweep GC-Log

Hi.
I am trying to extract some metrics from the garbage collector log of the concurrent mark sweep garbage collector. I have found a nice walkthrough a this site:
[http://www.sun.com/bigadmin/content/submitted/cms_gc_logs.html |http://www.sun.com/bigadmin/content/submitted/cms_gc_logs.html ]
I'm using CMS in incremental mode and that's where I am having interpretation problems. The site above states that the incremental mode takes over the job of the "concurrent mark"-phase. If this is correct (is it?) that means that I have two different statistics that state how long the "concurrent mark"-phase took. First the incremental CMS statistics and second the ordinary CMS statistics.
The first incremental stats look like this:
2803.125: [GC 2803.125: [ParNew: 408832K->0K(409216K), 0.5371950 secs]
611130K->206985K(1048192K) icms_dc=4 , 0.5373720 secs]
2824.209: [GC 2824.209: [ParNew: 408832K->0K(409216K), 0.6755540 secs]
615806K->211897K(1048192K) icms_dc=4 , 0.6757740 secs] The second ordinary statistics look like this:
40.683: [CMS-concurrent-mark: 0.521/0.529 secs]I'm wondering wether the second (ordinary) statistics are still valid when using incremental mode.
Kind regards
Frank

40.683: [CMS-concurrent-mark: 0.521/0.529 secs]
Yes, these logs are still valid. icms_dc indicates the time in percentage that the concurrent work took between two young GCs.
e.g. for the following logs:
-->1.289: [GC 1.289: [DefNew: 1984K->191K(1984K), 0.1952985 secs] 5695K->5714K(7648K) icms_dc=55 , 0.1956749 secs] [Times: user=0.19 sys=0.00, real=0.20 secs]
1.488: [CMS-concurrent-reset-start]
1.494: [CMS-concurrent-reset: 0.006/0.006 secs] [Times: user=0.00 sys=0.00, real=0.01 secs]
1.503: [GC [1 CMS-initial-mark: 5522K(9208K)] 6715K(11192K), 0.0191550 secs] [Times: user=0.02 sys=0.00, real=0.02 secs]
1.522: [CMS-concurrent-mark-start]
-->1.531: [GC 1.531: [DefNew: 1710K->192K(1984K), 0.1260654 secs] 7232K->7220K(11192K) icms_dc=70 , 0.1265609 secs] [Times: user=0.10 sys=0.02, real=0.13 secs]
2.051: [CMS-concurrent-mark: 0.401/0.528 secs] [Times: user=0.50 sys=0.03, real=0.53 secs]
Concurrent work took around 70% of the time between the two young GCs at 1.531 and 1.289. Here, some part of CMS-concurrent-mark work was done before the second young GC and rest after that. And overall CMS-concurrent-mark phase ran for 0.401s out of total (2.051-1.522=) 0.529s.

Clearing movieclips content / garbage collection

I have a movie clip that has 20 key frames, and on each key
frame is a different bitmap that has been dragged into place from
the library. when i attached this, the movie clip play and the
memory goes (levels out at the end of the sequens).
But when i remove the movie clip (removeChild) and set the
instance to 'null' the memory doesn't come down (even if i wait or
force it to garbage collect). Does movie clips content get cleared?
Any help would be very welcome. Thanks

What do you mean "adding assets is the only reliable way i've
found to force gc"??
Is it possible to add a movie clip that contains a load of
bitmaps and when you delete it, the memory goes down? seems like
they are just being stored in memory even though their are no
references to them.

Applescript: force garbage collection?

Hello
I am trying to call applescript functions (from my cocoa application - using NSAppleScript's -executeAndReturnError), to automate some operations in Microsoft Word.
The problem is that after every Applescript call, the Word operates slower and slower (and i guess finally it won't respond at all). I am calling operations, like "set myvar to all words of current document whose [some conditional]" or "set myvar to all fields of current document whose [some conditional]" (which are memory consuming - on each call Word enumerates all the words of a long document, searches there some matches, etc), and i think that after each call of NSAppleScript's -executeAndReturnError, Word doesn't clean its previous "results", which slows it down with every next call. I wanted to try to do an explicit call of Applescript's garbage collector after each -executeAndReturnError from my Cocoa app, maybe that could eliminate the problem i have.
But i didn't find any info on how to do that. Java, ActionScript - both have System.gc() functions (that launch Garbage collection if it's needed right here and right now). If theres no way to force garbage collecting in AppleScript, maybe someone knows "implicit ways", when AppleScript engine calls it? Like the next iteration of a loop, or some other conditions? Or some timespan, after passing which the GC is called?
What could cause that slowness of Mac:Word? Is it a mistake of Microsoft, or am i forgetting to do something? If someone could advice readings about how applications usually implement Applescript interface "from the inside" (and who is responsible for cleaning the results of each call), i'd be very thankful.
Thanks for any advice!
George

If you really want to see the results you should also run the finalizer
thread on the newly garbage collected objects. It might take up to 2 GC
cycles for the memory to be actually free for new allocation at least on
the Sun JVMs. Maybe the new types of garbage collectors do it better or
more optimized but anyway, the GC would first mark the objects and only
then the finalizer will run to call the finalize method. Then next GC
will free the memory of the finalized objects.
HTH,
Dejan
Dinesh wrote:
Hi Slava Imeshev,
Thanks for immediate response. I agree JVM will do GC at specific interval. But,
I have found that , there is some difference in both of them. If you invoke "Force
Garbage Collection" explicitly, the graph will show the heap memory usage to baseline.
Where in, if you perform System.gc(). It won't make much difference.
Thus why, I want to know what is the code behind the "Force Garbage Collection"
button.
Thanks,
-Dinesh.
"Slava Imeshev" <[email protected]> wrote:
"Dinesh" <[email protected]> wrote in message news:406a8df4$[email protected]..
How can i schedule "Force Garbage Collection" to be done at every
week or daily?.
Can i automate this process instead of manually invoking the button?
GC is already done by JVM automatically.
Why would you want to "schedule" it?
Regards,
Slava Imeshev

Do you think JOptionPane dialogs force garbage collection afterwards?

I ask because I've made a nested static class to implement my own file selection tool; the problem is that each time I call it the old JPanel is being recalled and so the components get re-added to it each time it's called, resulting in n versions of each file for every n times you open it.
I'm running myDialog.dispose() upon exiting, so is my only option now manual garbage collection? How could I force it to be garbage collected? Because System.gc() seems to have no effect.

Strictly speaking there is no way to force garbage collection, so, no, JOptionPane will not be doing it.
You almost certainly have a leak in your code. Post it and we may be able to help.

Howto Force Garbage Collection manually in Oracle Application Server

Hi,
I have a Oracle SOA suite installed on Oracle 10g Application Server. The heap memory for the SOA oc4j container is 2G with a permgen space of 256M. But it looks like there is some memory leak somewhere and the Heap area is getting filled frequently and this causes an *[libopmnoc4j] OC4J ping attempt timed out* and as a result of this the SOA oc4j container gets restarted automatically.
Is there any means by which we can force a Garbage Collection manually so that this automatic restart does not happen.
Kindly let me know if it is possible to trigger a Garbage Collection manually in Oracle Application Server.
Thanks,
Vijay.

We had a similar situation where the oc4j instance will throw OutOfMemoryException and opmn will restart a new instance every 10-12 hours. The JDBC 10.2.0.3 driver has a memory leak in the XA Resource classes. There is a fix available in metalink.

Memory leak in java / forcing garbage collection for unused resource?

Is there any possibility in big programs if not designed properly for leakage of memory?
If say i forget to force garbage collection of unused resouces what will happen?
Even if i am forcing garbage collection how much assurity can be given to do so?
I need answers w.r.t typical programming examples if someone can provide i will be happy.
Or any useful link.
Thanks
Vijendra

Memory leaks are usually much related with C/C++ programming since in that language you have direct access to memory using pointers.
Now, in Java you do not have access to pointers, however you could still tie up your objects in a way that the garbage collection can not remove them.
Basically, the grabage collection will search all the object implementation, and see if they are referenced or not. If not it will free that memory. However if you, somehow in you code allow a reference to your object then the garbage collection will not displose of that object.
An example I can think of is when developing web applications. For example storing objects in the session will mean that you will have a reference to the object from the session, therefore the garbage collection will not free up the meomry taken by those objects untill the session has expired.
That is how I know it... at least that is how they tought it to me!
regards,
sim085

Force Garbage Collection through scripting

Hi ,
I am using weblogic server 8.1.5 on windows 2003 server.
can we do force garbage collection through a script? If so can i have a sample script for the same?
OS:windows 2003 server
thanks in advance.
Madan Mohan

And the key here is "any length of time". I used to have WLDF notification on for all errors in the log file, but I specifically disabled it for the "almost out of memory" error, because it happened constantly, even when we didn't really have a memory problem. It's a little harder to determine the "any length of time" constraint. I'm not aware of an interface to "gc()" through WLST, which would be the most practical way to do this.
I think it's possible the "shape" of your free/used memory patterns would change if you changed your GC algorithm. If you're currently using a "stop the world" collector, the free memory percentage will probably decrease almost to zero before it collects. However, if you use a generational collector, it's possible in normal operation that you won't get down so close to zero before it collects. In that case, the "almost out of memory" error might be more meaningful.

Why can we force Garbage Collection

Hello,
Why can we force garbage collection since we have AUTOMATIC garbage collection?

If you don't call dispose on the Window, it may keep a
GUI thread running in the background. Since this
thread is still running and accesible from the root,
it will hold onto the Window. You should always call
dipose() on Windows you want to be completely removed.I know I should that's why a mentioned it! But is it correct that I should have to? Nowhere in the documentation does it say so. The fundamental principle is you let go of all object references and eventually the object will be removed by the GC. In this case this important principle is broken.
At least a clear WARNING should be stated. Window (and all its subclasses) break an important principle of Java. If you don't call dispose your program will leak memory !!!

Force Garbage Collection

Before I load a new level, should I force garbage collection on the old level? And if so, how?

Just remember that the method suggest the garbage collector to run, not forcing it..
If you have a lot of objects created that are later available for garbage collecting, you could try to reuse the objects instead of creating new ones (if garbage collection is really a problem for you).

Force Garbage collection externally....

hi!
I am new to java.is it possible to the force Garbage collection externally?
can i achieve it by giving the command "System.gc();".pls give me idea...
Thanx
Rgds,

You can't force a full GC as far as I know. gc() might force a GC of the youngest generation.
Why do you think you need to force it?

Garbage collection force

we observed garbage collection is happening when we use following code.
try
// System.gc();
new LocalConnection().connect('foo');
new LocalConnection().connect('foo');}
catch(e:*){
Is it good to use in production code?

It is the only known way to force GC in production code, but Adobe does not
guarantee that it will always work.

High cpu usage for garbage collection (uptime vs total gc time)

Hi Team,
We have a very high cpu usage issue in the production.
When we restart the server, the cpu idle time would be around 95% and it comes down as days goes by. Today idle cpu is 30% and it is just 6th day after the server restart.
Environemnt details:
Jrockit version:
Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2_05-b04)
BEA WebLogic JRockit(TM) 1.4.2_05 JVM R24.4.0-1 (build ari-38120-20041118-1131-linux-ia32, Native Threads, GC strategy: parallel)
Gc Algorithm: JRockit Garbage Collection System currently running strategy: Single generational, parallel mark, parallel sweep
Number Of Processors: 4
Max Heap Size: 1073741824
Total Garbage Collection Time: 21:43:56.5
Uptime: 114:33:4.1
Total Garbage Collection Count: 420872
Total Number Of Threads: 198
Number Of Daemon Threads: 191
Can you guys please tell me what would be problem in the server which causing the high cpu usage?
One more thing I would like to know is that why the total number of threads is 198 when we specified the Executor pool size as 25? I agree that weblogic would create some threads for its maintenance but around 160 threads!!! something is wrong I guess.
Santhosh.
[email protected]

Hi,
I'm having a similar problem, but haven't been able to resolve it yet. Troubleshooting is made even harder by the fact that this is only happening on our production server, and I've been unable to reproduce it in the lab.
I'll post whatever findings I have and hopefully we'll be able to find a solution with the help of BEA engineers.
In my case, I have a stand-alone Tomcat server that runs fine for about 1-2 days, and then the JVM suddenly starts using more CPU, and as a result, the server load shoots up (normal CPU utilization is ~5% but eventually goes up to ~95%; load goes from 0.1 to 4+).
What I have found so far is that this corresponds to increased GC activity.
Let me list my environment specs before I proceed, though:
CPU: Dual Xeon 3.06GHz
RAM: 2GB
OS: RHEL4.4 (2.6.9-42.0.2.ELsmp)
JVM build 1.5.0_03-b07 (BEA JRockit(R) (build dra-45238-20050523-2008-linux-ia32, R25.2.0-28))
Tomcat version 5.5.12
JAVA_OPTS="-Xms768m -Xmx768m -XXtlasize16k -XXlargeobjectlimit16k -Xverbose:memory,cpuinfo -Xverboselog:/var/log/tomcat5/jvm.log -Xverbosetimestamp"
Here are excerpts from my verbose log (I'm getting some HT warning, not sure if that's a problem):
[Fri Oct 20 15:54:18 2006][22855][cpuinfo] Detected SMP with 2 CPUs that support HT.
[Fri Oct 20 15:54:18 2006][22855][cpuinfo] Trying to determine if HT is enabled.
[Fri Oct 20 15:54:18 2006][22855][cpuinfo] Trying to read from /dev/cpu/0/cpuid
[Fri Oct 20 15:54:18 2006][22855][cpuinfo] Warning: Failed to read from /dev/cpu/0/cpuid
[Fri Oct 20 15:54:18 2006][22855][cpuinfo] Trying to read from /dev/cpu/1/cpuid
[Fri Oct 20 15:54:18 2006][22855][cpuinfo] Warning: Failed to read from /dev/cpu/1/cpuid
[Fri Oct 20 15:54:18 2006][22855][cpuinfo] HT is: supported by the CPU, not enabled by the OS, enabled in JRockit.
[Fri Oct 20 15:54:18 2006][22855][cpuinfo] Warning: HT enabled even though OS does not seem to support it.
[Fri Oct 20 15:54:55 2006][22855][memory ] GC strategy: System optimized over throughput (initial strategy singleparpar)
[Fri Oct 20 15:54:55 2006][22855][memory ] heap size: 786432K, maximal heap size: 786432K
[Fri Oct 20 16:07:30 2006][22855][memory ] Changing GC strategy to generational, parallel mark and parallel sweep
[Fri Oct 20 16:07:30 2006][22855][memory ] 791.642-791.874: GC 786432K->266892K (786432K), 232.000 ms
[Fri Oct 20 16:08:02 2006][22855][memory ] 824.122: nursery GC 291998K->274164K (786432K), 175.873 ms
[Fri Oct 20 16:09:51 2006][22855][memory ] 932.526: nursery GC 299321K->281775K (786432K), 110.879 ms
[Fri Oct 20 16:10:24 2006][22855][memory ] 965.844: nursery GC 308151K->292222K (786432K), 174.609 ms
[Fri Oct 20 16:11:54 2006][22855][memory ] 1056.368: nursery GC 314718K->300068K (786432K), 66.032 ms
[Sat Oct 21 23:21:09 2006][22855][memory ] 113210.427: nursery GC 734274K->676137K (786432K), 188.985 ms
[Sat Oct 21 23:30:41 2006][22855][memory ] 113783.140: nursery GC 766601K->708592K (786432K), 96.007 ms
[Sat Oct 21 23:36:15 2006][22855][memory ] 114116.332-114116.576: GC 756832K->86835K (786432K), 243.333 ms
[Sat Oct 21 23:48:20 2006][22855][memory ] 114841.653: nursery GC 182299K->122396K (786432K), 175.252 ms
[Sat Oct 21 23:48:52 2006][22855][memory ] 114873.851: nursery GC 195060K->130483K (786432K), 142.122 ms
[Sun Oct 22 00:01:31 2006][22855][memory ] 115632.706: nursery GC 224096K->166618K (786432K), 327.264 ms
[Sun Oct 22 00:16:37 2006][22855][memory ] 116539.368: nursery GC 246564K->186328K (786432K), 173.888 ms
[Sun Oct 22 00:26:21 2006][22855][memory ] 117122.577: nursery GC 279056K->221543K (786432K), 170.367 ms
[Sun Oct 22 00:26:21 2006][22855][memory ] 117123.041: nursery GC 290439K->225833K (786432K), 69.170 ms
[Sun Oct 22 00:29:10 2006][22855][memory ] 117291.795: nursery GC 298947K->238083K (786432K), 207.200 ms
[Sun Oct 22 00:39:05 2006][22855][memory ] 117886.478: nursery GC 326956K->263441K (786432K), 87.009 ms
[Sun Oct 22 00:55:22 2006][22855][memory ] 118863.947: nursery GC 357229K->298971K (786432K), 246.643 ms
[Sun Oct 22 01:08:17 2006][22855][memory ] 119638.750: nursery GC 381744K->322332K (786432K), 147.996 ms
[Sun Oct 22 01:11:22 2006][22855][memory ] 119824.249: nursery GC 398678K->336478K (786432K), 93.046 ms
[Sun Oct 22 01:21:35 2006][22855][memory ] 120436.740: nursery GC 409150K->345186K (786432K), 81.304 ms
[Sun Oct 22 01:21:38 2006][22855][memory ] 120439.582: nursery GC 409986K->345832K (786432K), 153.534 ms
[Sun Oct 22 01:21:42 2006][22855][memory ] 120443.544: nursery GC 410632K->346473K (786432K), 121.371 ms
[Sun Oct 22 01:21:44 2006][22855][memory ] 120445.508: nursery GC 411273K->347591K (786432K), 60.688 ms
[Sun Oct 22 01:21:44 2006][22855][memory ] 120445.623: nursery GC 412391K->347785K (786432K), 68.935 ms
[Sun Oct 22 01:21:45 2006][22855][memory ] 120446.576: nursery GC 412585K->348897K (786432K), 152.333 ms
[Sun Oct 22 01:21:45 2006][22855][memory ] 120446.783: nursery GC 413697K->349080K (786432K), 70.456 ms
[Sun Oct 22 01:34:16 2006][22855][memory ] 121197.612: nursery GC 437378K->383392K (786432K), 165.771 ms
[Sun Oct 22 01:37:37 2006][22855][memory ] 121398.496: nursery GC 469709K->409076K (786432K), 78.257 ms
[Sun Oct 22 01:37:37 2006][22855][memory ] 121398.730: nursery GC 502490K->437713K (786432K), 65.747 ms
[Sun Oct 22 01:44:03 2006][22855][memory ] 121785.259: nursery GC 536605K->478156K (786432K), 132.293 ms
[Sun Oct 22 01:44:04 2006][22855][memory ] 121785.603: nursery GC 568408K->503635K (786432K), 71.751 ms
[Sun Oct 22 01:50:39 2006][22855][memory ] 122180.985: nursery GC 591332K->530811K (786432K), 131.831 ms
[Sun Oct 22 02:13:52 2006][22855][memory ] 123573.719: nursery GC 655566K->595257K (786432K), 117.311 ms
[Sun Oct 22 02:36:04 2006][22855][memory ] 124905.507: nursery GC 688896K->632129K (786432K), 346.990 ms
[Sun Oct 22 02:50:24 2006][22855][memory ] 125765.715-125765.904: GC 786032K->143954K (786432K), 189.000 ms
[Sun Oct 22 02:50:26 2006][22855][memory ] 125767.535-125767.761: GC 723232K->70948K (786432K), 225.000 ms
vvvvv
[Sun Oct 22 02:50:27 2006][22855][memory ] 125768.751-125768.817: GC 712032K->71390K (786432K), 64.919 ms
[Sun Oct 22 02:50:28 2006][22855][memory ] 125769.516-125769.698: GC 711632K->61175K (786432K), 182.000 ms
[Sun Oct 22 02:50:29 2006][22855][memory ] 125770.753-125770.880: GC 709632K->81558K (786432K), 126.000 ms
[Sun Oct 22 02:50:30 2006][22855][memory ] 125771.699-125771.878: GC 708432K->61368K (786432K), 179.000 ms
So, I'm running with the default GC strategy which lets the GC pick the most suitable approach (single space or generational). It seems to switch to generational almost immediately and runs well - most GC runs are in the nursery, and only once in a while it goes through the older space.
Now, if you look at [Sun Oct 22 02:50:27 2006], that's when everything changes. GC starts running every second (later on it's running 3 times a second) doing huge sweeps. It never goes through the nursery again, although the strategy is still generational.
It's all downhill from this point on, and it's a matter of hours (maybe a day) before we restart the server.
I guess my only question is: What would cause such GC behavior?
I would appreciate your ideas/comments!
Thanks,
Tenyo

Forcing �Mark Sweep� Garbage Collection?

Similar Messages

Maybe you are looking for