Frequent Garbage Collection Issues

Hi,
I am using Weblogic 8.1 SP6. Recently we have increase in the traffic and as a result I have seen this pattern w.r.t GC.
While using the monitoring tab of the weblogic console I have seen that at a regular interval of about 20 secs there is a forced GC from JVM and causing the app to not respond for about 5-6 secs. We thought that some of the JVM parameters were not set properly and we raised the parameters.
It worked fine, it is started doing every 1 minute instead of 20 secs. Is there any way we can check if any java objects are not removed from JVM heap or if there are some other configurations we need to check about the system?
John

Regarding objects in the Java heap that are not properly being collected, look
at the trouble shooting guide under memory leaks.
http://java.sun.com/javase/6/webnotes/trouble/index.html

Similar Messages

Full garbage collection issue, not releasing/flagging memory

I have the following problem running on a multi-cpu windows server with Java 1.4.2_05 using WebLogic 8.1:
During a lifecyle of the web application (under load, but not to heavy) memory usage seems ok and garbage collection is called regularly. Suddenly, the used heap starts to rize very fast and after a while, even a full garbage collection cylce, does not release any memory anymore.
I am sure that, from our coding, we release memory ok, and normally we should only use about 5 to 10 mb for each user max (with0 normal defnew garbage collections).
I tried changing the garbage collection parameters, but this does not solve the problem. Best scenario was with the concurrent collector and I got this output at +/- the end:
[GC 100202K->93511K(115628K), 0.0091472 secs]
[GC 148480K->139612K(163808K), 0.0225914 secs]
[Full GC[Unloading class sun.reflect.GeneratedSerializationConstructorAccessor289]
[Unloading class sun.reflect.GeneratedSerializationConstructorAccessor290]
[Unloading class sun.reflect.GeneratedSerializationConstructorAccessor273]
153750K->133006K(164064K), 1.2434402 secs]
[GC 148939K->137948K(203264K), 0.0223085 secs]
[GC 188789K->177116K(203264K), 0.0180729 secs]
[Full GC[Unloading class sun.reflect.GeneratedSerializationConstructorAccessor312]
[Unloading class sun.reflect.GeneratedSerializationConstructorAccessor322]
[Unloading class sun.reflect.GeneratedSerializationConstructorAccessor309]
189788K->170264K(203264K), 1.1851945 secs]
[Full GC 203228K->203227K(203264K), 1.2876122 secs]
[Full GC 203263K->203233K(203264K), 1.3354548 secs]
[Full GC 203263K->203258K(203264K), 1.2873518 secs]
<Jan 17, 2007 9:40:40 AM EST> <Error> <HTTP> <BEA-101017> <[ServletContext(id=33114655,name=console,context-path=/console)] Root cause of ServletException.
java.lang.OutOfMemoryError
>
[Full GC 203263K->203233K(203264K), 1.2814516 secs]
[Full GC 203233K->203231K(203264K), 1.6029044 secs]
[Full GC 203263K->203242K(203264K), 1.3081352 secs]
<Jan 17, 2007 9:41:51 AM EST> <Emergency> <WebLogicServer> <BEA-000210> <The WebLogic Server is no longer listening for connections.>
[Full GC 203263K->203247K(203264K), 1.3161194 secs]
[Full GC 203263K->203249K(203264K), 1.2954988 secs]
[Full GC 203263K->203247K(203264K), 1.6423404 secs]
<Jan 17, 2007 9:41:57 AM EST> <Alert> <WebLogicServer> <BEA-000218> <Server shutdown has been requested by <WLS Kernel>>
[Full GC 203263K->203250K(203264K), 1.3161025 secs]
Another strange item is: I maximized the amount of memory it uses to 512m with the Xmx parameter, I am almost sure that that one is used, but it never gets higher than 203M? Does anyone know why this is?
Another strange item: the monitoring in the weblogic code indicates 32MB of usage (relative memory usage seems to be ok, but the quanity indication is just plain wrong) with 15 threads running.
This problem does not exist when using JBoss 4.0.2 or 4.0.3 (standard j2ee settings).
If anyone has an idea or can help me, I would appreciate it very very much. :)

Hi ,
Is this issue resolved ?
we are facing same problem.
1. We have checked the CPU and memory utilization everything is normal
2. GC logs showing FULL GC calls continuously
3. After restart the resin server system is working normally.
Environment detail
Resin ./resin-pro-3.0.18 on suse Linux
Java JDK1.4.2_08
Please suggest

Garbage collection issue as3

Having real problems with garbage collection in as3
Currently working on a project that is using a main movie
clip to load other movie clips dynamicly, using loadURL.these sub
movieclips are rather heavy in size, and function as standalone
modules.
Our problem is that when we removeChild of the sub clips it
is still present in memory (which from what I have read is normal
untill garbage collection cycle is fired) however it doesn't seem
to ever get removed.
how can we safely load movieclips and remove all references
to them to make them eligible for garbage collection? current
approach we are using is to publicly state the loader the say new
loader() in an attempt to recycle rather that to try to send for
garbage collection

Hi ajmcfarlane,
This is my first post here. I'm fairly new to AS3 still and
have been getting my education from a number of places. The best
education i have found is from the book located at
http://www.learningactionscript3.com/
Rich Shupe address this problem of removing the child from
memory. I Downloaded your file and found 2 problems and resolved
one of them. By now you might have already solved this anyway.
To remove the child from the Display List use -->
removeChild(myChildObject);
To remove the object from memory use --> myChildObject =
null;
You did these two steps but in the incorrect order, just by
moving the 'myChildObject = null' under the removeChild code makes
it work.
I found running a few trace statements after fixing the first
problem, i found the second problem. The error of trying to remove
a child when it is no longer there.
You just need to rework the design so that the order of
events fires as you want. Below is the traces i used and the output
that is received.
function Click1(e:MouseEvent){
trace("four ", loadedcontent);
modLoader.unload();
modLoader = null;
function unloadCompleteHandler(event:Event):void{
trace("one ", loadedcontent);
removeChild(loadedcontent);
trace("two ", loadedcontent);
loadedcontent = null;
trace("three ", loadedcontent);
output
Loaded mem: 20668 KB
four [object MainTimeline]
one [object MainTimeline]
two [object MainTimeline]
three null
unLoaded mem: 23352 KB
So you can see the click event is firing of the unload first,
when i think you want that last.
I hope this has been of some help :)

Does frequent garbage collection affect performance

Hi,
I have written code in a filter for all the servlets in the application.
Depending on the servlet requested I set the objects to null after
it has finished its work.
My question is that since the filter will be executed each time a
servlet is requested,could it result in affecting performance ?

Styna wrote:
I'm writing off my own experience so take my advice with a grain of salt.
The battery is known to 'degrade' when reaching excessive temperatures. Apple recommends keeping the temperature between to 32 degrees Fahrenheit and 95 degrees Fahrenheit.
I used to game heavily on my phone which would get hot. After a year, I noticed that I had to fully charge my phone 3 times a day in order to make it through a day with light usage. Also, I noticed that the phone would die when the battery percentage display would be at all sorts of numbers, 37%, 43%, 7%, and sometimes stay on 1% for 5 minutes while running a processor-intensive game.
After taking my phone to the Apple store for a diagnostic, Apple confirmed issues with the battery. There's no way to know if having my phone stay hot for long periods of time damaged the battery or if I just had a defective battery.
My recommendation is if you know you will be gaming heavily to take the case (if you have one) off your phone and to be in a cool environment to try to keep the phone from getting too hot.
Your battery failed not because of temperature, but you used it up. The battery is spec'd for 400 full charge/discharge cycles. If you fully drain the battery every day that's about 14 months. If you drain it more than once a day that's less time. The phone has a thermal protection circuit that will shut it down if it gets hot enough to damage anything. And actually Lithium batteries do not degrade at higher temperatures. Electric cars and plugin hybrids use the same battery technology (like the Tesla, Chevy Volt, Prius Plugin, Nissan Leaf) and they run much hotter than iPhones. And last 10 years.

Garbage Collection Issue for Tree Component

Dear:
When I created a new Tree instance dynamically by following code, and clicked any tree node randomly and then I removed it via another button, but I found this instance couldn’t be removed by GC, if I just created this tree without mouse action, it can be removed by GC.
Tree Component:
-- TreeView
<mx:canvas>
<mx:Tree dataProvider="{data}" />   // data is a XML staments
</mx:canvas>
Create Tree:
           public function createView(event:Event):void{
              var view:TreeView = new TreeView ();
              view.name="myTree";
              addChild(view);
              view=null;
Remove Tree:
           public function deleteView(event:Event):void{
              var view:TreeView= TreeView( _con.getChildByName("myTree"));
              removeChild(view);
Could someone give me some suggestion?
Thanks a lot

Hi ajmcfarlane,
This is my first post here. I'm fairly new to AS3 still and
have been getting my education from a number of places. The best
education i have found is from the book located at
http://www.learningactionscript3.com/
Rich Shupe address this problem of removing the child from
memory. I Downloaded your file and found 2 problems and resolved
one of them. By now you might have already solved this anyway.
To remove the child from the Display List use -->
removeChild(myChildObject);
To remove the object from memory use --> myChildObject =
null;
You did these two steps but in the incorrect order, just by
moving the 'myChildObject = null' under the removeChild code makes
it work.
I found running a few trace statements after fixing the first
problem, i found the second problem. The error of trying to remove
a child when it is no longer there.
You just need to rework the design so that the order of
events fires as you want. Below is the traces i used and the output
that is received.
function Click1(e:MouseEvent){
trace("four ", loadedcontent);
modLoader.unload();
modLoader = null;
function unloadCompleteHandler(event:Event):void{
trace("one ", loadedcontent);
removeChild(loadedcontent);
trace("two ", loadedcontent);
loadedcontent = null;
trace("three ", loadedcontent);
output
Loaded mem: 20668 KB
four [object MainTimeline]
one [object MainTimeline]
two [object MainTimeline]
three null
unLoaded mem: 23352 KB
So you can see the click event is firing of the unload first,
when i think you want that last.
I hope this has been of some help :)

Garbage Collection issue

We have a high volume application that processes around 1mil messages (avg size of messsage is 4K). The processing done by mostly short-lived objects. We cleanup those objects as soon as we are done with them by setting to null.
Incremental GC's run initially and seems to be reclaiming the total space. After a while, FULL GC kicks in , taking lot of time to run , pausing main application threads. At some point, application runs out of memory.
Application is running on sun sparc 12 cpu machine with 4G of memory.
Here are the JVM options used:
java -server -Xnoclassgc -XX:+UseParallelGC -verbose:gc -ms512m -mx2048m
Here is the snapshot GC console output:
[GC 1037106K->934696K(1323992K), 0.8224376 secs]
[GC 1073960K->972315K(1323992K), 0.8492167 secs]
[GC 1111579K->1009308K(1323992K), 0.9097631 secs]
[GC 1148572K->1046394K(1323992K), 0.8439699 secs]
[GC 1185658K->1084905K(1323992K), 0.8705303 secs]
[GC 1224168K->1122494K(1323992K), 0.8552342 secs]
[GC 1261758K->1159081K(1323992K), 0.8970201 secs]
[GC 1298343K->1195721K(1335000K), 1.1827162 secs]
[Full GC 1195721K->989634K(1335000K), 24.3578172 secs]
[GC 1184065K->1044938K(1849840K), 0.9831921 secs]
[GC 1239366K->1096178K(1849840K), 0.9747165 secs]
[GC 1290609K->1147124K(1849840K), 0.9470200 secs]
[GC 1341556K->1199331K(1849840K), 1.0176226 secs]
[GC 1393763K->1251271K(1849840K), 1.1659994 secs]
[GC 1445703K->1303021K(1849840K), 1.1822156 secs]
[GC 1497453K->1355071K(1849840K), 1.1616752 secs]
[GC 1549502K->1406485K(1849840K), 1.3026876 secs]
[GC 1600914K->1458371K(1849840K), 1.1999966 secs]
[GC 1652803K->1508827K(1849840K), 1.1635613 secs]
[GC 1703259K->1559797K(1849840K), 1.1399380 secs]
[GC 1754229K->1608405K(1849840K), 1.1470171 secs]
[Full GC 1195721K->989634K(1335000K), 24.3578172 secs]
[GC 1184065K->1044938K(1849840K), 0.9831921 secs]
[GC 1239366K->1096178K(1849840K), 0.9747165 secs]
[GC 1290609K->1147124K(1849840K), 0.9470200 secs]
[GC 1341556K->1199331K(1849840K), 1.0176226 secs]
[GC 1393763K->1251271K(1849840K), 1.1659994 secs]
[GC 1445703K->1303021K(1849840K), 1.1822156 secs]
[GC 1497453K->1355071K(1849840K), 1.1616752 secs]
[GC 1549502K->1406485K(1849840K), 1.3026876 secs]
[GC 1600914K->1458371K(1849840K), 1.1999966 secs]
[GC 1652803K->1508827K(1849840K), 1.1635613 secs]
[GC 1703259K->1559797K(1849840K), 1.1399380 secs]
[GC 1754229K->1608405K(1849840K), 1.1470171 secs]
^[[2~[GC 1802837K->1658413K(1852912K), 1.2599031 secs]
[Full GC 1658413K->1322684K(1852912K), 31.4556695 secs]
[GC 1541948K->1382396K(2090304K), 1.0559670 secs]
[GC 1601659K->1441184K(2090304K), 1.1171899 secs]
[GC 1660448K->1499921K(2090304K), 1.1041055 secs]
[GC 1719184K->1560243K(2090304K), 1.1842856 secs]
[GC 1779504K->1617751K(2090304K), 1.0513258 secs]
[GC 1837015K->1674981K(2090304K), 1.1666812 secs]
[Full GC 1894245K->1551657K(2090304K), 37.6117940 secs]
[GC 1770921K->1613369K(2090304K), 1.0356318 secs]
[GC 1832632K->1669436K(2090304K), 1.1144191 secs]
[Full GC 1888700K->1648994K(2090304K), 39.3942882 secs]
[Full GC 1868258K->1694146K(2090304K), 40.3389419 secs]
[Full GC 1913410K->1738377K(2090304K), 42.7415051 secs]
[Full GC 1957638K->1780351K(2090304K), 42.5810629 secs]
[Full GC 1999615K->1830407K(2090304K), 44.5052564 secs]
As you could see, Full GC is taking long time.
Whats the best way to tune JVM in this scenerio ?

Added your recommended option tags in test server and here is the snapshot of GC activity - as you could see Full GC has not been called at all:
53897K->353897K(434368K), 0.0779606 secs]
1727.386: [GC 1727.387: [DefNew: 84800K->84800K(84800K), 0.0000577 secs]1727.387: [CMS: 269254K->268788K(349568K), 11.5143598 secs] 354054K->353588K(434368K), 11.5182741 secs]
1753.687: [GC 1753.689: [DefNew: 84800K->84800K(84800K), 0.0000447 secs]1753.689: [CMS: 269318K->269318K(349568K), 0.0791392 secs] 354118K->354118K(434368K), 0.0833374 secs]
1768.458: [GC 1768.459: [DefNew: 84800K->84800K(84800K), 0.0000425 secs]1768.459: [CMS: 269181K->269181K(349568K), 0.1021508 secs] 353981K->353981K(434368K), 0.1057072 secs]
1783.647: [GC 1783.648: [DefNew: 84800K->84800K(84800K), 0.0000590 secs]1783.649: [CMS: 269330K->268956K(349568K), 11.0677651 secs] 354130K->353756K(434368K), 11.0710862 secs]
1809.767: [GC 1809.769: [DefNew: 84800K->84800K(84800K), 0.0000575 secs]1809.769: [CMS: 269438K->269042K(349568K), 11.3660772 secs] 354238K->353842K(434368K), 11.3705901 secs]
1836.227: [GC 1836.231: [DefNew: 84800K->84800K(84800K), 0.0000587 secs]1836.232: [CMS: 269616K->269091K(349568K), 11.3381937 secs] 354416K->353891K(434368K), 11.3452536 secs]
1861.800: [GC 1861.802: [DefNew: 84800K->84800K(84800K), 0.0000557 secs]1861.802: [CMS: 269409K->269409K(349568K), 0.0788080 secs] 354209K->354209K(434368K), 0.0824389 secs]
1876.985: [GC 1876.986: [DefNew: 84800K->84800K(84800K), 0.0000517 secs]1876.986: [CMS: 269595K->269595K(349568K), 0.0831590 secs] 354395K->354395K(434368K), 0.0860654 secs]
1891.873: [GC 1891.874: [DefNew: 84800K->84800K(84800K), 0.0000482 secs]1891.874: [CMS: 269724K->269724K(349568K), 0.0708213 secs] 354524K->354524K(434368K), 0.0736807 secs]
1906.779: [GC 1906.780: [DefNew: 84800K->84800K(84800K), 0.0000456 secs]1906.780: [CMS: 269933K->269933K(349568K), 0.0755266 secs] 354733K->354733K(434368K), 0.0796340 secs]
1921.445: [GC 1921.447: [DefNew: 84800K->84800K(84800K), 0.0000448 secs]1921.447: [CMS: 269975K->269975K(349568K), 0.0819310 secs] 354775K->354775K(434368K), 0.0851893 secs]
1936.274: [GC 1936.276: [DefNew: 84800K->84800K(84800K), 0.0000696 secs]1936.276: [CMS: 269854K->269854K(349568K), 0.0907438 secs] 354654K->354654K(434368K), 0.0950534 secs]
1950.935: [GC 1950.937: [DefNew: 84800K->84800K(84800K), 0.0000566 secs]1950.937: [CMS: 269775K->269775K(349568K), 0.1000276 secs] 354575K->354575K(434368K), 0.1030710 secs]
1965.190: [GC 1965.192: [DefNew: 84800K->84800K(84800K), 0.0000839 secs]1965.192: [CMS: 269985K->269544K(349568K), 10.7150874 secs] 354785K->354344K(434368K), 10.7188375 secs]
1990.031: [GC 1990.033: [DefNew: 84800K->84800K(84800K), 0.0000733 secs]1990.033: [CMS: 270100K->269651K(349568K), 11.2685995 secs] 354900K->354451K(434368K), 11.2728810 secs]
2016.264: [GC 2016.265: [DefNew: 84800K->84800K(84800K), 0.0000450 secs]2016.265: [CMS: 270106K->270106K(349568K), 0.0698348 secs] 354906K->354906K(434368K), 0.0727872 secs]
2030.980: [GC 2030.982: [DefNew: 84800K->84800K(84800K), 0.0000954 secs]2030.982: [CMS: 270238K->269788K(349568K), 10.9844057 secs] 355038K->354588K(434368K), 10.9880408 secs]
2056.197: [GC 2056.199: [DefNew: 84800K->84800K(84800K), 0.0000710 secs]2056.199: [CMS: 270270K->269834K(349568K), 11.2985424 secs] 355070K->354634K(434368K), 11.3019009 secs]
2081.879: [GC 2081.882: [DefNew: 84800K->84800K(84800K), 0.0000630 secs]2081.882: [CMS: 270160K->270160K(349568K), 0.0996453 secs] 354960K->354960K(434368K), 0.1043853 secs]
2096.863: [GC 2096.865: [DefNew: 84800K->84800K(84800K), 0.0000719 secs]2096.865: [CMS: 270345K->269982K(349568K), 11.0743990 secs] 355145K->354782K(434368K), 11.0788176 secs]
2122.374: [GC 2122.375: [DefNew: 84800K->84800K(84800K), 0.0000527 secs]2122.375: [CMS: 270485K->270485K(349568K), 0.0760466 secs] 355285K->355285K(434368K), 0.0793288 secs]
2136.892: [GC 2136.894: [DefNew: 84800K->84800K(84800K), 0.0000544 secs]2136.894: [CMS: 270570K->270078K(349568K), 10.9475307 secs] 355370K->354878K(434368K), 10.9508848 secs]
2162.131: [GC 2162.132: [DefNew: 84800K->84800K(84800K), 0.0000566 secs]2162.132: [CMS: 270387K->270387K(349568K), 0.0721499 secs] 355187K->355187K(434368K), 0.0751687 secs]
2176.539: [GC 2176.540: [DefNew: 84800K->84800K(84800K), 0.0000695 secs]2176.540: [CMS: 270573K->270194K(349568K), 10.8633072 secs] 355373K->354994K(434368K), 10.8664201 secs]
You think the problem is fixed ?

Garbage Collection Problem

Hi All,
I am facing some problem with frequent Garbage Collection application running in the background. Issue in production system. Frequently GC is happening, which is affecting the performance. Is there any work around. Issue is affecting the employees and data is inconsistent.
Please help on this asap.
Regards,
Soorya

Hi,
>>>I am facing some problem with frequent Garbage Collection application running in the background.
usually issues with GC are not that simple
also you need to check what kind of GC is happening first then you can start checking why
but my guess would be there is something wrong with the flow and this is causing the GC to work in a wrong way
(if it was working before)
when I did GC checks for my clients it was at least one day of work sometimes to find out what was wrong + repairs later on
Regards,
Michal Krawczyk

Revisited: static synchronized vs garbage collected

A forum thread (http://forum.java.sun.com/thread.jsp?forum=4&thread=466049&start=0&range=15&hilite=false&q=) from last November addressed issues involving the relative merits of using static methods vs. the garbage collection issues that might attend conventional object instantiation. The discussion extended into use of synchronized code and threading, but from it, I've failed to gather an understanding of a few subtleties.
I understand the dangers of using class-level variables within servlets, however, I'm still puzzled as to the thread-safety of 1) static class-level variables in servlets, and 2) using static methods residing in "utility" type classes from within servlets. I also realize these matters are not confined to servlets, but extend to any multi-threaded environment. I'm particularly unclear as to when, or if, the methods of the static class-level variable/objects need to be synchronized; with the same question applied to the static methods of the "utility" classes.
From the forum thread mentioned above, it would seem that synchronization is NOT needed since parameters and method-level variables are specific to the executing threads. I believe this essentially means that static methods should not rely on the state of their containing class (under most applications). In a situation where the method's code is not trivial or "lightweight" (e.g. database access), would not the overhead associated with the swapping in and out of thread-specific variables lead to performance issues?
My particular situation involves an ecommerce site running websphere. We are experiencing sporadic episodes where the VM starts running low on memory, will occasionally recover but will also occasionally crash. In pursuing this wild goose, my first suspicion was a thread deadlocking problem since it's not reliably reproducible. Most of the log entries point to a static method in one of these "utility" classes, yet I can find no non-static class level variables either in the utility or the servlet. However, none of these static methods are synchronized.
Sorry for the ramble, and thanks for any help.
Regards,
Joe

Because static variables, by their very nature, are only instantiated once, you MUST syncronise them to be safe in a multi threaded environment, otherwise you will get unexpected results.
As you rightly mention, servlets also optimise the instantiation of class level variables and effectively make them static as well, so they are shared amongst all instaniations of a servlet.

How to encourage jvm to garbage collect?

Hello,
I am working with an application that would benefit from more frequent garbage collection. It is running on a hefty machine, with multiple processors and more than 4 gigs of memory available for the JVM. Right now, we are setting the max heap size to 3 gigs.
The problem is that objects are accumulating, but are not being collected. During a particular operation that I am profiling, over 1 gig of objects are created, but are never collected. If I do a manual garbage collect (using jprofiler), they are all collected. There is no good way to load these objects in another way, or to create fewer objects.
I have spent a few days playing with -XX:MaxNewSize, -XX:NewSize, -XX:MaxHeapFreeRatio, -XX:TargetSurvivorRatio, and even -XX:+UseParNewGC. Unfortunately, I am unable to encourage the JVM to collect these objects automatically.
Are there any tricks that I am missing? Does anyone know any good way to encourage the JVM to collect garbage after a certain threshhold in the new generation?
Thanks,
--Jeff

You can try this!
How do I set the JVM's heap size?
On machines with limited memory (less than 384MB), it is recommended that you set the initial heap size lower than the default. Open the configuration file etc/netbeans.confin a text editor and modify the options in netbeans_default_optionssetting. Decrease the option -J-Xmx128mto -J-Xmx96m and the option -J-XX:MaxPermSize=96mto -J-XX:MaxPermSize=64m. Save the file and restart the IDE.
Bear in mind that UI responsiveness may be affected when the heap utilization gets close to its limit. Should you encounter an OutOfMemoryError, you need to increase Xmx or XX:MaxPermSize back to the default, or even higher.
Similarly when running on a machine with more memory it might be useful to increase the maximum size of the heap, especially when working with larger projects. Use the page linked below to get more details on this topic.
Applies to: NetBeans 4.x, 5.0
Platforms: All

Aggressive Heap and garbage collection in 1.4.2

We are trying to monitor the memory usage and the garbage collection for one of our application servers. We are using JDK 1.4.2 b-19 on solaris 8. The machine has 4 900 Mhz CPUs and 8GB ram. The VM options are:
-server -XX:+AggressiveHeap -Xms3512m -Xmx3512m -verbose:gc
-XX:+PrintHeapAtGC -XX:+PrintTenuringDistribution -XX:+PrintGCTimestamps.The first full GC kicks in when the old generation gets full which is understandable. After that however, the full gc kicks in much more frequently and even the gc pauses are fairly long. Below are some of the output from gc.
For the first GC the old generation was almost full.
PSYoungGen total 1379840K, used 1324288K
PSOldGen total 2123648K, used 2103378K
For the second GC, young generation is 25MB out of 1300MB and old generation is 1100MB out of 2100MB. Still the full gc kicked in and took 23 secs.
PSYoungGen total 1356608K, used 25856K
PSOldGen total 2123648K, used 1169626K
I understand that the adaptive sizing is kicking in (by default) but it should make life better not worse. If the full GC could wait till the old generation gets full again, I will get lesser number of full gc pauses and few and far in between.
Any idea as to what I can do?
thanks
vinay
{Heap before GC invocations=108:
Heap
PSYoungGen      total 1379840K, used 1324288K [0x1a000000, 0x73e20000, 0x73e20000)
eden space 228096K, 100% used [0x1a000000,0x27ec0000,0x27ec0000)
from space 1151744K, 95% used [0x27ec0000,0x6ad40000,0x6e380000)
to   space 92800K, 0% used [0x6e380000,0x6e380000,0x73e20000)
PSOldGen        total 2123648K, used 2103378K [0x73e20000, 0xf5800000, 0xf5800000)
object space 2123648K, 99% used [0x73e20000,0xf4434af8,0xf5800000)
PSPermGen       total 31872K, used 31768K [0xf5800000, 0xf7720000, 0xf9800000)
object space 31872K, 99% used [0xf5800000,0xf7706200,0xf7720000)
2842.142: [Full GC 3427666K->1083494K(3503488K), 26.6495189 secs]
Heap after GC invocations=108:
Heap
PSYoungGen      total 1379840K, used 0K [0x1a000000, 0x73e20000, 0x73e20000)
eden space 1287040K, 0% used [0x1a000000,0x1a000000,0x688e0000)
from space 92800K, 0% used [0x6e380000,0x6e380000,0x73e20000)
to   space 92800K, 0% used [0x688e0000,0x688e0000,0x6e380000)
PSOldGen        total 2123648K, used 1083494K [0x73e20000, 0xf5800000, 0xf5800000)
object space 2123648K, 51% used [0x73e20000,0xb6039978,0xf5800000)
PSPermGen       total 63744K, used 31768K [0xf5800000, 0xf9640000, 0xf9800000)
object space 63744K, 49% used [0xf5800000,0xf7706200,0xf9640000)
{Heap before GC invocations=114:
Heap
PSYoungGen      total 1356608K, used 25856K [0x1a000000, 0x73e20000, 0x73e20000)
eden space 1240576K, 0% used [0x1a000000,0x1a000000,0x65b80000)
from space 116032K, 22% used [0x6ccd0000,0x6e610000,0x73e20000)
to   space 116032K, 0% used [0x65b80000,0x65b80000,0x6ccd0000)
PSOldGen        total 2123648K, used 1169626K [0x73e20000, 0xf5800000, 0xf5800000)
object space 2123648K, 55% used [0x73e20000,0xbb456858,0xf5800000)
PSPermGen       total 65536K, used 31773K [0xf5800000, 0xf9800000, 0xf9800000)
object space 65536K, 48% used [0xf5800000,0xf7707578,0xf9800000)
3153.022: [Full GC 1195482K->1149586K(3482688K), 23.3155823 secs]
Heap after GC invocations=114:
Heap
PSYoungGen      total 1359040K, used 0K [0x1a000000, 0x73e20000, 0x73e20000)
eden space 1245440K, 0% used [0x1a000000,0x1a000000,0x66040000)
from space 113600K, 0% used [0x6cf30000,0x6cf30000,0x73e20000)
to   space 113600K, 0% used [0x66040000,0x66040000,0x6cf30000)
PSOldGen        total 2123648K, used 1149586K [0x73e20000, 0xf5800000, 0xf5800000)
object space 2123648K, 54% used [0x73e20000,0xba0c4830,0xf5800000)
PSPermGen       total 65536K, used 31773K [0xf5800000, 0xf9800000, 0xf9800000)
object space 65536K, 48% used [0xf5800000,0xf7707578,0xf9800000)
}

We also had similar issues...If you are using RMI it might cause Full GC. This is the snippet from http://java.sun.com/docs/hotspot/gc/
<snip>
Garbage can't be collected in these distributed applications without occasional local collection, so RMI forces periodic full collection. The frequency of these collections can be controlled with properties. For example,
java -Dsun.rmi.dgc.client.gcInterval=3600000
-Dsun.rmi.dgc.server.gcInterval=3600000
</snip>
By default this is 1 min. So try changing this and try it out.

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

Garbage collection Java Virtual Machine : Hewlett-Packard Hotspot release 1.3.1.01

"Hi,
I try and understand the mechanism of garbage collection of the Java Virtual Machine : Hewlett-Packard Hotspot release 1.3.1.01.
There is description of this mechanism in the pdf file : "memory management and garbage collection" available at the paragraph "Java performance tuning tutorial" at the page :
http://h21007.www2.hp.com/dspp/tech/tech_TechDocumentDetailPage_IDX/1,1701,1607,00.html
Regarding my question :
Below is an extract of the log file of garbage collections. This extract has 2 consecutive garbage collections.
(each begins with "<GC:").
<GC: 1 387875.630047 554 1258496 1 161087488 0 161087488 20119552 0 20119552
334758064 238778016 335544320
46294096 46294096 46399488 5.319209 >
<GC: 5 387926.615209 555 1258496 1 161087488 0 161087488 0 0 20119552
240036512 242217264 335544320
46317184 46317184 46399488 5.206192 >
There are 2 "full garbage collections", one of reason "1" and one of reason "5".
For the first one "Old generation After " =238778016
For the second "Old generation After " =238778016
Thus, "Old generation Before garbage collection" of the second is higher than "Old generation After garbage collection". Why?
I expected all objects to be allocated in the "Eden" space. And therefore I did not expect to s

I agree but my current Hp support is not very good on JVM issues.
Rob Woollen <[email protected]> wrote:
You'd probably be better off asking this question to HP.
-- Rob
Martial wrote:
The object of this mail is the Hewlett-Packard 1.3.1.01 Hotspot JavaVirtual Machine
release and its garbage collection mechanism.
I am interested in the "-Xverbosegc" option for garbage collectionmonitoring.
I have been through the online document :
http://www.hp.com/products1/unix/java/infolibrary/prog_guide/java1_3/hotspot.html#-Xverbosegc
I would like to find out more about the garbage collection mechanismand need
further information to understand the result of the log file generatedwith the
"-Xverbosegc"
For example here is an extract of a garbage collection log file generatedwith
Hewlett-Packard Hotspot Java Virtual Machine. Release 1.3.1.01.
These are 2 consecutive rows of the files :
<GC: 5 385565.750251 543 48 1 161087488 0 161087488 0 0 20119552 264184480255179792
335544320 46118384 46118384 46137344 5.514721 >
<GC: 1 385876.530728 544 1258496 1 161087488 0 161087488 20119552 020119552 334969696
255530640 335544320 46121664 46106304 46137344 6.768760 >
We have 2 full garbage collections, one of Reason 5 and the next oneof Reason
1.
What happened between these 2 garbage collections as we got : "Oldgeneration
After" of row 2 is higher than "Old generation Before" of row 1? Iexpected Objects
to be initially allocated in eden and so we could not get "old generation2modified
between the end of one garbage collection and before the next one.
Could you please clarify this issue and/or give more information aboutgarbage
collection mechanisms with the Hewlett-Packard Hotspot Java VirtualMachine. Release
1.3.1.01.

Garbage Collection Advice

We currently have a garbage collection related performance issue that I could do with some advice on.
We use Jakarta Tomcat with an application that has approximately 1300 jsp's. When a new set of jsp's are rolled out we see a degradation in performance. Using jvmstat I've ascertained that this performance degradation is due to excessive garbage collection partulcarly in the young generation where it appears to be almost constantly collecting. What advice would you give?
ie More young generation space? fewer survivor cycles? bigger eden or survivor space?
Any suggestions would be much appreciated.

Hi
See
http://java.sun.com/docs/hotspot/gc1.4.2/
http://java.sun.com/docs/hotspot/gc1.4.2/example.html
The steps should be, as in example.html
1. Determine the size u would allocate.
2. Then try the alternate collectors.
1300 jsps, do take note of MaxPermSize too.
Hope this helps.

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.

Preventing garbage-collection of a RMIRegistered server object

I am developping a client/server RMI application, and keep facing occasional ObjectNotFioundException: no such object in table, when the client tries to invoke method on the server stub retrived from the RMIRegistry.
The Javadoc and online documentation say this means the server object has been GC'ed since it has been registered in the RMIRegistry.
Following the advice found at: http://www.nabble.com/java.rmi.NoSuchObjectException:-no-such-object-in-table-t260095.html,
I register the server in a RMIRegistry I obtain through LocateRegistry.getRegistry(), and not createRegistry().
But I still face these exceptions.
Assuming the issue is really due to the server object being garbage-collected, I tried to keep a static reference to the server but it didn't help (the Main class was probably garbage-collected itself).
As a last hope, I've set up a "keep-alive" thread in the server VM, that keeps a direct reference to the server object (not the stub), and regularly invokes something on it. With this mechanism I never face the exception.
This solution looks obviously clumsy.
Is there a neater way to prevent garbage collection of the server object?
Note that I use dynamic stubs (Java5-style).

Without seeing some code, I'm not sure what you are doing. Also the link you supplied is broken.
You always need to keep a live reference to your implementation class. How you do this is your business. Using a separate thread is over-kill.
I set a reference to the implementation class in the start up class and use a never ending wait() to make sure the start up class thread (with the main()) lives forever.

Frequent Garbage Collection Issues

Similar Messages

Maybe you are looking for