Weblogic Garbage collection (GC)

Hi All,
I am new to forum. I want to find out if anyone has used Garbage collection argument -XX:+UseCompressedOops ?
I am getting error. Does it need anything else with it?
thanks

Hi,
Using following command " UseCompressedOops " will reduce JVM usage and GC for more details check this blog.
http://blog.leneghan.com/2012/03/reducing-java-memory-usage-and-garbage.html
Regards,
Kal

Similar Messages

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

How to Change the Garbage Collection Algorithm in WLS 9..2

Hi All
I am trying to find out the way to configure the GC algorithm in weblogic 9.2 to type bea.Jmapi.GarbageCollector@.
By default it is showing ‘Nursery, parallel mark, parallel sweep’ . We were trying to change it to generational (two-spaced) with a parallel mark algorithm and a concurrent sweep algorithm or bea.Jmapi.GarbageCollector .
To change the same I modified the memory argument in commenv.cmd to set MEM_ARGS=-Xms128m -Xmx256m -XXsetGC:genparcon
Still Garbage Collection Statistics section in web logic console shows the same default value.
Could anyone tell me if I am missing something?
thanks in advance

There is nothing is WebLogic that will define the JVM GC algorithm, that is up to the JVM settings that are normally configured using params in the start scripts.
If you are using JRockit, you can ask in the forums but the JVM documentation should really be sufficient.
JRockit
Same thing for the Sun JVM, there is lots of information out there on how to change the GC algorithm.
The thing that is nice about JRockit is that you can use the Mission Control tooling to take recordings, look at the GC's and make adjustments easily. Sun has some tooling as well with jvmstat (and visualgc), but I'm not as familiar with it.
http://java.sun.com/performance/jvmstat/
Both of those tools would be much preferred to printing the GC info to a file and trying to parse it in my opinion.

When will wls try to garbage collect ?

The docs for the option "Low memory GC threshold" say that this is the "Threshold
level at which WLS will try to garbage collect once the granularity report has
been met".
My question is: When is this condition met ? If at least once there has been a
granularity report in the log ? Or if the server has been set to Warning state
The problem Im trying to address is that my "Low memory GC threshold" is set to
20% and my server has reached only 1% free memory and garbage collection did not
run, I had to force it via console.
Thanks in advance, Giselle

I am wonder when the WLS activate or passivate session and how can I control it?
 > From documents, sessionWillPassivate in HttpSessionActivationListener will
 be
 > executed when a session is about to passivate on one server (ie. WLS
 instance)
 > and the sessionDidActivate method when the same session has been activated
 on
 > a second server.
 >
 > But I have monitor the behavior for a long time by setting
 PersistentStoreType
 > to file, memory, replicated. sessionDidActivate and sessionWillPassivate
 will
 > never executed. I expected it will passivate and activate when session is
 replicated
 > between servers or persist in files. Any ideas?
 What version of WL? the interface you describe was new in Servlet 2.3, so it
 may not be implemented until 6.1 or even 7.x.
 Peace,
 Cameron Purdy
 Tangosol, Inc.
 http://www.tangosol.com/coherence.jsp
 Tangosol Coherence: Clustered Replicated Cache for Weblogic
 "Karen Law" <[email protected]> wrote in message
 news:3ec86188$[email protected]..
 >

Static class garbage collection

Can garbage collector can garbage collect static classes ?.
My doubt is that when you access a static class , that class is loaded through its class loader ( when first time that class is referenced ).
So when did the garbage collector collects this static class ( assume that static class no longer referred ).
Please do more information,
What are the ways to prevent garbage collector for a particular class ( Assume that i m implementing a singleton for my java runtime)
thanks and regards
Renjith.

Can garbage collector can garbage collect static classes ?. Static classes are nothing special in terms of class loading - they are only different in visibility for linking.
Perhaps you mean static members of classes?
My doubt is that when you access a static class ,
that class is loaded through its class loader ( when
first time that class is referenced ). Classes are always loaded through classloaders. Objects of those classes are allocated from the heap, and the object instances refer to the class object.
Objects (either instances, or classes themselves) are garbage collected when they are no longer live (i.e. no live object refers to them). (This is a somewhat recursive definition, and sometimes, you can have cyclic dependencies that make garbage collection tricky, but the GC, while it has to be conservative for correctness, usually gets it right).
So for a static member to be garbage-collected, the class has to be garbage-collected first. The class cannot be GC'ed until all references to it go away (this includes all dynamically allocated objects of that type, and the class loader that loaded that class).
And yes, class loaders can go away, but only if they are created by your program. The system class loader (which is the default classloader you get if you don't create any class loaders of your own) never goes away, so any class loaded from CLASSPATH will never be unloaded.
(As an example, servlet containers - e.g. Tomcat, Weblogic, etc.) allocate one or more classloaders for each webapp. When the webapp is un-deployed, the classloaders are "orphaned", and they, and any classes loaded by them (from the WEB-INF/lib and WEB-INF/classes directories) are unloaded and garbage-collected. (After all the dynamic objects of those classes are GC'ed, of course).
>
So when did the garbage collector collects this
static class ( assume that static class no longer
referred ).
Please do more information,
What are the ways to prevent garbage collector for a
particular class ( Assume that i m implementing a
singleton for my java runtime)
thanks and regards
Renjith.

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 Garbage Collection take more time on JRockit?

My company use 
BEA WebLogic 8.1.2 
JRockit version 1.4.2 
Window 2003 32bit 
RAM 4 Gig 
 
-Xms = 1300 
-Xmx = 1300 
and running ejb application. 
My problem is why JRockit take more time. How Can I solve this problem. Because my application will down again.
 
This is my infomation on JRockit :
 
Gc Algorithm: JRockit Garbage Collection System currently running strategy: Single generational, parallel mark, parallel sweep.
 
Total Garbage Collection Count: 10340
 
Last GC End: Wed May 10 13:55:37 ICT 2006
 
Last GC Start: Wed May 10 13:55:35 ICT 2006
 
Total Garbage Collection Time: 2:53:13.1
 
GC Handles Compaction: true
 
Concurrent: false
 
Generational: false
 
Incremental: false
 
Parallel: true
 

Hi,
I will suggest you to check a few places where you can see the status
1) SM37 job log (In source system if load is from R/3 or in BW if its a datamart load) (give request name) and it should give you the details about the request. If its active make sure that the job log is getting updated at frequent intervals.
Also see if there is any 'sysfail' for any datapacket in SM37.
2) SM66 get the job details (server name PID etc from SM37) and see in SM66 if the job is running or not. (In source system if load is from R/3 or in BW if its a datamart load). See if its accessing/updating some tables or is not doing anything at all.
3) RSMO see what is available in details tab. It may be in update rules.
4) ST22 check if any short dump has occured.(In source system if load is from R/3 or in BW if its a datamart load)
5) SM58 and BD87 for pending tRFCs and IDOCS.
Once you identify you can rectify the error.
If all the records are in PSA you can pull it from the PSA to target. Else you may have to pull it again from source infoprovider.
If its running and if you are able to see it active in SM66 you can wait for some time to let it finish. You can also try SM50 / SM51 to see what is happening in the system level like reading/inserting tables etc.
If you feel its active and running you can verify by checking if the number of records has increased in the data tables.
SM21 - System log can also be helpful.
Also RSA7 will show LUWS which means more than one record.
Thanks,
JituK

Huge number of garbage collected objects

We're running a system here with the java heap set to 256mb and have noticed
that now and then, garbage collection takes a horribly long time to complete
(in the order of minutes, rather than fractions of a minute!). Something
like 3 million objects are being freed when the server is heavily loaded.
Has anyone else experienced this behaviour? Has anyone tested weblogic with
JProfiler/OptimizeIt and found any troublesome spots where many objects are
created? One potential place where this can be happening is in the servlet
logging. Since there is a timestamp that is a formatted date, my guess is
that a new Date object is being created, which is very expensive and hence
might cause many more objects that need to be garbage collected. Can any
weblogic engineers confirm/deny this?

Use vmstat to determine if you're swapping. sar would work too.
Swapping is definitely dictated by the OS, but an inordinate amount of
swapping activity just means you get to tune the hardware rather along
with the application.
Jason
Original Message <<<<<<<<<<<<<<<<<<On 2/21/00, 12:45:26 PM, "Hani Suleiman"
<[email protected]> wrote regarding Re: Huge number of
garbage collected objects:
Here are the results from running top on that machine:
Memory: 512M real, 14M free, 553M swap in use, 2908M swap free
PID USERNAME THR PRI NICE SIZE RES STATE TIME CPU COMMAND
3035 root 50 59 0 504M 334M sleep 308:42 5.13% java
How to make sure I'm not swapping? I thought that kind of thing was dictated
by the OS...
Rob Woollen <[email protected]> wrote in message
news:[email protected]..
If GC takes on the order of minutes to run then I suspect that you
are
paging. How much physical memory do you have on the machine? Make sure
that
you are not swapping.
-- Rob
Hani Suleiman wrote:
We're running a system here with the java heap set to 256mb and have
noticed
that now and then, garbage collection takes a horribly long time tocomplete
(in the order of minutes, rather than fractions of a minute!).
Something
like 3 million objects are being freed when the server is heavilyloaded.
Has anyone else experienced this behaviour? Has anyone tested weblogicwith
JProfiler/OptimizeIt and found any troublesome spots where many
objects
are
created? One potential place where this can be happening is in theservlet
logging. Since there is a timestamp that is a formatted date, my guessis
that a new Date object is being created, which is very expensive andhence
might cause many more objects that need to be garbage collected. Can
any
weblogic engineers confirm/deny this?

Garbage Collection take long times.....

*** NOTES 19-JUN-2001 10:27:33 [20-JUN-2001 00:27:33 ASST3] websupport
*** Logged by contact: Weber Wang, 2-87705935 ext. 63
Product Name and Version, including Service Pack (if any):
=============================================
weblogic6.0sp2
Platform (OS Version)
=================
solaris2.7
JDK Version (if applicable)
=====================
jdk130
If your problem relates to a 3rd party product (JDBC driver, database, or web/proxy
server), please provide vendor name, product name, version number
==============================================================================================
Detailed Problem Description
======================
we have set java parameter to start up weblogic server ,but got the Garbage Collection
time too long...it cause browser halt...when Garbage Collection
will do a Full GC?and will it degrade weblogic's performance?
java -server -verbose:class -verbose:gc -verbose:jni -XX:newSize=512m -XX:MaxNewSize=512m
-Xms768m -Xmx768m -XX:SurvivorRatio=2
Error Message/Stack Trace
=====================
[Full GC 65065K->27729K(65216K), 1.2891364 secs]
[Full GC 49079K->28008K(65216K), 1.0507784 secs]
[Full GC 65111K->29714K(65216K), 1.1813595 secs]
[Full GC 51063K->29988K(65216K), 1.0506374 secs]
[Full GC 64951K->27867K(65216K), 1.1312621 secs]
[Full GC 49216K->28146K(65216K), 1.0534394 secs]
[Full GC 65095K->29993K(65216K), 1.6070138 secs]
[Full GC 51343K->30182K(65216K), 1.3617954 secs]

I think your young generation size is waaaaay too high - its performance
impact becomes negative at or around 1/2 of the total heap size.
weber <[email protected]> wrote:
*** NOTES 19-JUN-2001 10:27:33 [20-JUN-2001 00:27:33 ASST3] websupport
*** Logged by contact: Weber Wang, 2-87705935 ext. 63
Product Name and Version, including Service Pack (if any):
=============================================
weblogic6.0sp2
Platform (OS Version)
=================
solaris2.7
JDK Version (if applicable)
=====================
jdk130
If your problem relates to a 3rd party product (JDBC driver, database, or web/proxy
server), please provide vendor name, product name, version number
==============================================================================================
Detailed Problem Description
======================
we have set java parameter to start up weblogic server ,but got the Garbage Collection
time too long...it cause browser halt...when Garbage Collection
will do a Full GC?and will it degrade weblogic's performance?
java -server -verbose:class -verbose:gc -verbose:jni -XX:newSize=512m -XX:MaxNewSize=512m
-Xms768m -Xmx768m -XX:SurvivorRatio=2
Error Message/Stack Trace
=====================
[Full GC 65065K->27729K(65216K), 1.2891364 secs]
[Full GC 49079K->28008K(65216K), 1.0507784 secs]
[Full GC 65111K->29714K(65216K), 1.1813595 secs]
[Full GC 51063K->29988K(65216K), 1.0506374 secs]
[Full GC 64951K->27867K(65216K), 1.1312621 secs]
[Full GC 49216K->28146K(65216K), 1.0534394 secs]
[Full GC 65095K->29993K(65216K), 1.6070138 secs]
[Full GC 51343K->30182K(65216K), 1.3617954 secs]--
Dimitri

Avoiding Garbage Collection

Hi,
Does anyone know of a general design pattern that allows an object to remain
in memory without being garbage collected ? I'm not clear whether or not
the singleton pattern fulfills this requirement. I basically want to have a
Global constants class (constants are loaded from a properties file) that
remains in memory so that it can be used by various components. The
constants are loaded from a properties file initialially. So if that class
gets garbage collected, then the next time that class is accessed, it will
have to reload from the props file. This is a performance issue, and I
would like to find a solution around it.
I will probably want to have other services such as a LoggingService,
JNDIService that I want started up, and for it to remain in memory. I know
you can register startup classes with WL, but do those classes remain in
memory ?
I'm been trying to find an answer to these questions. Hopefully someone
will have them.
Thanks.

One way to do it is to bind your constants class into JNDI during
start-up.
-- Rob
Jamie Tsao wrote:
>
Hi,
Does anyone know of a general design pattern that allows an object to remain
in memory without being garbage collected ? I'm not clear whether or not
the singleton pattern fulfills this requirement. I basically want to have a
Global constants class (constants are loaded from a properties file) that
remains in memory so that it can be used by various components. The
constants are loaded from a properties file initialially. So if that class
gets garbage collected, then the next time that class is accessed, it will
have to reload from the props file. This is a performance issue, and I
would like to find a solution around it.
I will probably want to have other services such as a LoggingService,
JNDIService that I want started up, and for it to remain in memory. I know
you can register startup classes with WL, but do those classes remain in
memory ?
I'm been trying to find an answer to these questions. Hopefully someone
will have them.
Thanks.--
Coming Soon: Building J2EE Applications & BEA WebLogic Server
by Michael Girdley, Rob Woollen, and Sandra Emerson
http://learnweblogic.com

Garbage collection , BPEL engine properties configuration , fault policies.

Is the configuration / setup for Garbage collection , BPEL engine properties configuration , fault policies , database adapters, web services done before deploying a BPEL application or after ?
Thanks

Hope this will help you:
http://middlewaremagic.com/weblogic/?p=6388

Full Garbage Collection

Hi Friends,
I'm using weblogic workflow for my project. Last night i got one error, once i gone throw the bea ...i come to know that the error will comes because of "once the application calls webservice and the webservice intern calls the EJB stateless or stateful will fail". But my application is not using any sort of webservices. So i try to find the problem finally i found tht the problem is because of Garbage collection of Heap Size. It is taking 3.8508577 sec's. I feel in this time the JVM thread gets heighest priority and it is killing the application thread which is to be executed as usal.
Can u guide me how to catch this exception so tht my application won;t get affected. The actual error says like this which is related to Garbage Collection...[Full GC 313152K -> 105060K (1004928K), 3.8508577 secs]. I'm using JDK 1.4.
Thaks & Regards
[email protected]

Replies in this thread.

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

Does 5.1 log garbage collection like 4.5.2?

The weblogic 4.5.2 release notes state that the server will log whenever it
garbage collects, see below. Does 5.1 do this?
"We changed the distributed garbage collection server to always indicate
that it is running by adding entries to the Server log file. A typical entry
is:
Thu Aug 19 19:44:28 PDT 1999: <DGCserver>
Freed 1086 objects in 30 ms, 24 exported object remain."

It should. There is a slight possibility that it might not appear as a
feature until service pack No. 4 if the change to version 4.5.2 was not done
until after service pack three was completed.
If you do not see it in service pack No. 4, please report to support.
Thanks,
Michael
Michael Girdley
Product Manager, WebLogic Server & Express
BEA Systems Inc
Mark Johnson <[email protected]> wrote in message
news:396bbb8f$[email protected]..
The weblogic 4.5.2 release notes state that the server will log wheneverit
garbage collects, see below. Does 5.1 do this?
"We changed the distributed garbage collection server to always indicate
that it is running by adding entries to the Server log file. A typicalentry
is:
Thu Aug 19 19:44:28 PDT 1999: <DGCserver>
Freed 1086 objects in 30 ms, 24 exported object remain."

Memory Leak / Strange Garbage Collection

Help!
We are having strange problems that appear to be related to a memory leak. The
strange part is that even if we don't hit the site, it appears to leak. Can someone
please explain the output below: Notice how freespace is decreasing, even with
no direct site activity:
[GC 48857K->35514K(130560K), 0.0136978 secs]
[GC 49018K->35548K(130560K), 0.0144821 secs]
[GC 49052K->35550K(130560K), 0.0128796 secs]
[GC 49054K->35549K(130560K), 0.0121789 secs]
[GC 49053K->35547K(130560K), 0.0126394 secs]
[GC 49051K->35582K(130560K), 0.0161642 secs]
[GC 49086K->35770K(130560K), 0.0209171 secs]
[GC 49247K->36005K(130560K), 0.0188181 secs]
[GC 49509K->36198K(130560K), 0.0129967 secs]
etc...
If I understand the numbers correctly, we have less and less free space available.
If anyone has any insights into this it will be greatly appreciated. We have problems
moving into production.
Our environment: Solaris 8, Jdk1.3.1, WL 5.1
Chris

Chris - turn off verbose GC and and don't worry about it.
Visit java.sun.com and read all about Java and Garbage Collection and JVMs.
Weblogic does 'stuff' all on it's own even when it is not being accessed - just
like your refrigerator runs when are on vacation - (please tell me you don't worry
about that too). Objects get created and deleted. There is no pressing need for
the garbage collector to recover every scrap of unused memory - so it doesn't.
When the JVM does desperately need memory, it will run a Full GC and recover (almost)
all of that.
Then again it's nice to see someone who is curious about how the darn thing works.
:) Mike
"Chris" <[email protected]> wrote:
>
Thanks for the information. I guess I didn't understand it properly.
Is there a
reason why the numbers keep increasing, even with no site activity? It
looks like
there is less and less free space every few minutes....? After running
the whole
night after posting the original message, the numbers now look like:
[GC 55586K->42276K(130560K), 0.0136978 secs]
ie. Just keeps going up. Why does it increase? Thanks for any explanations!
Dimitri Rakitine <[email protected]> wrote:
You are not 'leaking memory' (hopefully!) - these are minor collections
(quickly
copying objects which lived long enough to the old generation portion
of the heap
and reclaiming space used by objects which died young) - wait until
major collection
(when it says [Full GC ...]).
Chris <[email protected]> wrote:
Help!
We are having strange problems that appear to be related to a memoryleak. The
strange part is that even if we don't hit the site, it appears to
leak.
Can someone
please explain the output below: Notice how freespace is decreasing,even with
no direct site activity:
[GC 48857K->35514K(130560K), 0.0136978 secs]
[GC 49018K->35548K(130560K), 0.0144821 secs]
[GC 49052K->35550K(130560K), 0.0128796 secs]
[GC 49054K->35549K(130560K), 0.0121789 secs]
[GC 49053K->35547K(130560K), 0.0126394 secs]
[GC 49051K->35582K(130560K), 0.0161642 secs]
[GC 49086K->35770K(130560K), 0.0209171 secs]
[GC 49247K->36005K(130560K), 0.0188181 secs]
[GC 49509K->36198K(130560K), 0.0129967 secs]
etc...
If I understand the numbers correctly, we have less and less free
space
available.
If anyone has any insights into this it will be greatly appreciated.We have problems
moving into production.
Our environment: Solaris 8, Jdk1.3.1, WL 5.1
Chris--
Dimitri

Weblogic Garbage collection (GC)

Similar Messages

Maybe you are looking for