All Tweens randomly halting (Not Garbage Collection)

I am developing a game with some AS3 tweens. I have encountered the problem of garbage collection affecting tweens before so I have all my tweens referenced at the class level now to ensure that isn't a problem. However, randomly all the current tweens in my game will stop. Other, non-tweened, frame by frame animations continue. It's just like the garbage collection problem but the tweens shouldn't be being collected...
The code I am using for tweens:
Var declaration at the top of the class:
private var gateTween:Tween;
This code in a function:
gateTween = new Tween(currentGate, "x", None.easeOut, 800, 380, 1.5, true);
gateTween.addEventListener(TweenEvent.MOTION_FINISH, horseJump);
Any ideas would be appriciated.

I have Swing based java project. Im setting all the
references to null as and when i dont need them, and
then im calling System.gc() also.
However it seems the memory is not being released,
when i check in the task manager, memory usage does
not reduce. It seems garbage collection is not
happening.Actually I have a small class - where in I try to do this:-
public class TestDebug extends Object{
/** Creates a new instance of TestDebug */
public TestDebug() {
* @param args the command line arguments
public static void main(String[] args) {
System.out.println("Trying to debug this");
TestDebug testDebug = new TestDebug();
testDebug.finalize();
System.out.println("Lasting print");
public void finalize(){
System.out.println("Finalize called");
System.gc();
System.out.println("Finalize finished");
But it is also true that you should never try to force it - It has its own way to do it.
For Example try to execute a big code(so that you can find JVM doing the GC) as "java -verbose:gc class-name"
You will find at some points during the execution process - that the JVM actually runs the GC on its own- but when not that is not defined.It is a low priority thread running under JVM.

Similar Messages

  • WLS not garbage collecting enough?

    WLS 5.1 SP5
    SunOS 5.6 (2.6)
    JDK 1.2.2_005a (with the JVMARGS directive set as per BEA's docs. The
    JVMARGS directive solved the SIGBUS 10 for us when requesting the
    AdminMain servlet)
    We tried some stress testing of our web app by running about 100 to 200
    virtual clients requesting the same URL (servlet that forwards to a
    JSP). These virtual clients are actually Java threads running
    simultaneously.
    After each test, we notice that, via WL console, the heap usage of WL
    increased. However, after leaving WL server by itself (no HTTP requests
    coming to it) for a long time (say 30 minutes to 1 hour), we noticed
    that the heap usage has not gone down, except for about 1%. As soon as
    we explicitly tell WLS to garbage collect via the WL console, then the
    heap usage goes down ... sometimes even as low as just 10% when we tell
    it to gc again just after a gc a few seconds earlier.
    Is this proper behaviour by WLS? ... or does this have something to do
    with the JVMARGS directive? Why doesn't it gc even after a long time?
    Thanks in advance,
    John Salvo
    Homepage: http://homepages.tig.com.au/~jmsalvo/

    There are a number of problems with memory usage and garbage collection. Going to WLS 5.1 will fix
    some of them. You should also consider having your application call System.runFinalization(); and
    System.gc() from time to time.
    Mike
    "Jim Zhou" <[email protected]> wrote:
    I see the same behavior in my stress test/pre-production run. I think it's
    normal behavior. The GC will kick in when the heap size gets 100%, you might
    see a pause in your WLS because all threads will stop for the GC ( you
    should see CPU really busy when GC is in ). JDK 1.2 should have better GC
    algorithm than JDK 1.1. Usually for people still using JDK1.1.x, tuning the
    heap size for tolerable GC pause is a pain., the tuning guide want you to
    run multiple WLS instances in a box to stagger the effects of GC pause. If
    you use JDK 1.2, you probably set your heap size comparable to your box's
    memory.
    In one of my stress test, I set heap size to 256m, I see on my console the
    heap gets full every 30 seconds, and it take 1 or 2 seconds to GC. But if
    your heap is 2G, it might take longer.
    WLS 4.51 SP11
    Solaris 2.6
    JDK 1.2.2_06.
    Regards,
    Jim Zhou.
    Jesus M. Salvo Jr. <[email protected]> wrote in message
    news:[email protected]...
    WLS 5.1 SP5
    SunOS 5.6 (2.6)
    JDK 1.2.2_005a (with the JVMARGS directive set as per BEA's docs. The
    JVMARGS directive solved the SIGBUS 10 for us when requesting the
    AdminMain servlet)
    We tried some stress testing of our web app by running about 100 to 200
    virtual clients requesting the same URL (servlet that forwards to a
    JSP). These virtual clients are actually Java threads running
    simultaneously.
    After each test, we notice that, via WL console, the heap usage of WL
    increased. However, after leaving WL server by itself (no HTTP requests
    coming to it) for a long time (say 30 minutes to 1 hour), we noticed
    that the heap usage has not gone down, except for about 1%. As soon as
    we explicitly tell WLS to garbage collect via the WL console, then the
    heap usage goes down ... sometimes even as low as just 10% when we tell
    it to gc again just after a gc a few seconds earlier.
    Is this proper behaviour by WLS? ... or does this have something to do
    with the JVMARGS directive? Why doesn't it gc even after a long time?
    Thanks in advance,
    John Salvo
    Homepage: http://homepages.tig.com.au/~jmsalvo/

  • This byte array is not garbage collected?

    imageBytes[] does not seem to ever be garbage collected. I've pinpointed a SINGLE LINE that, when commented out, will prevent the memory leak. What could possibly be wrong with this line?
    Running this code results in a "OutOfMemoryError: Java heap space" after roughly a minute on my machine. I'm using JRE version 1.5.0_08.
    import javax.imageio.ImageIO;
    import java.awt.*;
    import java.awt.image.*;
    import java.io.*;
    // creates images to send to ImageConsumer
    public class ImageProducer {
         static BufferedImage bufferedImage;
         static Robot robo;
         static byte[] imageBytes;
         public static void main(String args[]) {
              try {
                   robo = new Robot();
              } catch(Exception e) {
                   e.printStackTrace();
              PipedOutputStream pos = new PipedOutputStream();
              new ImageConsumer(pos).start();
              bufferedImage = robo.createScreenCapture(new Rectangle(Toolkit.getDefaultToolkit().getScreenSize()));
              try {
                   ObjectOutputStream oostream = new ObjectOutputStream(pos);
                   ByteArrayOutputStream baos = new ByteArrayOutputStream();
                   ImageIO.write(bufferedImage, "JPG", baos);
                   baos.flush();
                   imageBytes = baos.toByteArray();
                   while (true) {
                        ImageIO.write(bufferedImage, "JPG", baos);
                        baos.flush();
                        // THIS SEEMS TO BE WHERE THE MEMORY LEAK OCCURS: imageBytes
                        // If you comment the following line out, there will be no
                        // memory leak. Why?  I ask that you help me solve this.
                        imageBytes = baos.toByteArray();
                        baos.reset();
                        oostream.writeObject(imageBytes);
                        pos.flush();
              } catch (Exception e) {
                   e.printStackTrace();
    // This thread reads the image data into bImg
    class ImageConsumer extends Thread {
         BufferedImage bImg;
         PipedInputStream pis;
         ImageConsumer(PipedOutputStream pos) {
              try {
                   pis = new PipedInputStream(pos);
              } catch (IOException e) { e.printStackTrace();}
         public void run() {
              try {
                   ObjectInputStream oinstream = new ObjectInputStream(pis);
                   while (true) {
                        byte[] imageBytes = (byte[])oinstream.readObject();
                        ByteArrayInputStream bais = new ByteArrayInputStream(imageBytes);
                        bImg = ImageIO.read(bais);
              } catch (Exception e) {e.printStackTrace();}
    }

    while (true) {
         ImageIO.write(bufferedImage, "JPG", baos);
         baos.flush();
         // THIS SEEMS TO BE WHERE THE MEMORY LEAK OCCURS: imageBytes
         // If you comment the following line out, there will be no
         // memory leak. Why? I ask that you help me solve this.
         imageBytes = baos.toByteArray();
         baos.reset();
         oostream.writeObject(imageBytes);
         pos.flush();
    }I have only briefly gone through the code, but why are you flushing it right before calling that line. Won't the byte array returned always be empty right after flushing the stream?

  • Garbage Collection Help

    My understanding of garbage collection is that resources utilized by an object are released when no reference to the object exist. I accomplish this by ensuring that all references to an unneeded object are null.
    My question/concern is this. If I have an object "A" that has references to other objects "B", "C", and "D", will the all objects be elibible for garbage collection when the reference to object A is set to null? I suspect that objects "B", "C", and "D" persist until the virtual machine is terminated.
    Is the practice of creating a method within a class to make all inner objects eligible for garbage collection prior to setting the object reference to null. (i.e. set objects "B", "C", and "D" to null prior to setting "A" to null).
    Maybe I am just paranoid??

    My understanding of garbage collection is that
    resources utilized by an object are released when no
    reference to the object existThat's not correct. Objects can have references that point to them and still be garbage collected. For example:
    Vector v = new Vector();
    v.add(new Object());
    v = null;
    After this code is executed, the Vector object has a reference to the "new Object()" created. However, the Vector itself is not reachable, and therefore the "new Object()" is unreachable, and therefore both are collected.
    The garbage collector collects unreachable objects.
    I accomplish this by
    ensuring that all references to an unneeded object are
    null.It is quite rare that setting a reference to null is needed to make an object unreachable. Don't do it -- it makes your code slower, less readable, and harder to modify.
    My question/concern is this. If I have an object "A"
    that has references to other objects "B", "C", and
    "D", will the all objects be elibible for garbage
    collection when the reference to object A is set to
    null? I suspect that objects "B", "C", and "D"
    persist until the virtual machine is terminated.Yes -- all will be collected when A becomes unreachable. As noted earlier, you shouldn't need to set any reference to null for this to happen.
    Is the practice of creating a method within a class to
    make all inner objects eligible for garbage collection
    prior to setting the object reference to null. (i.e.
    set objects "B", "C", and "D" to null prior to setting
    "A" to null).
    Maybe I am just paranoid??Yes. Just let the garbage collector do its job and collect unreachable objects. You should almost never need to write any code to "help" the garbage collector.

  • Garbage Collection and Constant CPU Usage

    Hello,
    We have a load balanced environment running ColdFusion 10 Enterprise with 5 instances currently running. Currently we only have one instance being actively used but have been encountering a problem within a time frame of 12 to 36 hours (calculated on the times we have had to restart CF to come back online) the garbage collection is running almost constantly and CPU holds at 50% until the server just becomes unresponsive until the CF instance is restarted.
    I have been monitoring the server via VisualVM to watch the CPU and Heap usage since I have found that running the server monitoring systems build into CF 10 Enterprise accelerate the problem to cause a crash within 4 to 5 hours.
    This issue has been occuring regardless if there is heavy load or not on the server. I have been seeing some odd behaviour when running CF Stat where I am seeing 4 Requests Queued and Running Requests never shows anything other than 0. I increased the Minimum Heap Size to 512 MB and Maximum Heap Size to 1024 MB and below is our JVM arguments
    -server -XX:MaxPermSize=192m -XX:+UseParallelGC -Xbatch -Dcoldfusion.home={application.home} -Dcoldfusion.rootDir={application.home} -Dcoldfusion.libPath={application.home}/lib -Dorg.apache.coyote.USE_CUSTOM_STATUS_MSG_IN_HEADER=true -Dcoldfusion.jsafe.defaultalgo=FIPS186Random -Dcom.sun.management.jmxremote.port=8701 -Dcom.sun.management.jmxremote.ssl=false -Dcom.sun.management.jmxremote.authenticate=false
    We are running on a Windows 2008 64 Bit and IIS 7.5 on both of the load balanced servers and have updated the server to ColdFusion 10 Update 2. I am aware of the issues that are being fixed in Update 3 that was removed last week by Adobe due to bugs introduced.
    If anyone has any insight in how to fix this issue, I would be greatly appreciative.  This is affecting a production server that did not show these problems when we put the servers under load when we did pre launch settings.

    Further from your images - while it shows CF CPU at 50% the GC activity is 0%.
    So could be your not garbage collecting more than necessary and something else CF wise is taking CPU time.
    What would be interesting is the Jconsole Memory tab Details section. It shows the time spent in minor and major GC's.  eg:
    HTH, Carl.

  • Garbage Collection is not destruction?

    Garbage Collection is not destruction?
    This is one of the point from Thinking In Java 4th edition Chapter 5.Can someone please explain me this point.Does that mean that Garbage Collection does not destroy objects.If yes,then what is it role?
    And also please explain something about finalize().I tried to read it but couldn't understand.
    Thanks for your help.

    personal opinion really. I do call garbage collection destruction, the memory occupied by the objects in question is reclaimed. It is a discussion point however as it is from the perspective of the JVM; from the perspective of the application the object is "destroyed" as soon as you cut all references to it.
    What to explain about finalize()? It is invoked right before an object is garbage collected, possibly allowing you to do some last minute clean up jobs, like letting go of resource handles and such. The general rule about it is that in 99.99% of the cases you need not touch it. If you have a design where you need it, it is best to assume the design is wrong and you need to change it. For example in the case of closing resources, it is better to have a close() method that needs to be invoked manually.
    If you do use it, you better be really sure that you know what you are doing as you may cause performance problems or even hard to trace unexpected behavior.

  • Oracle JVM Garbage Collection not executing

    I am experiencing a problem with garbage collection when running a java stored procedure in an 9.2.0.3.0 Oracle database running on a Windows 2k computer.
    I have created a simple java class that represents a tree structure. Each instance of the class has a reference to it's parent and a Vecotor of all it's children. Each instance also has a Vector to hold name value pairs. I ran a program that creates 30 instances with 50 children each for a total of 1500 instances. Each instance has 30 properties(name value pairs).
    By using the debugger in JDeveloper and breakpoints I can watch the javaw.exe process's use of RAM.
    Start up: 6,788mb
    After creation of 1500 instances: 17,720
    After releasing all objects and calling System.gc(): 7,156
    I deploy the package to my Oracle database and perform the exact same routine using breakpoints and test procedures in plsql Developer. Using the breakpoints and watching the oracle.exe process's use of RAM I see:
    Start up: 81,116mb
    After creation of 1500 instances: 94,952
    After releasing all objects and calling System.gc(): 95,036
    When run in Oracle the resources are not released. Is there somthing special that needs to be called to get the garbage collector to do it's job when running in an Oracle database?
    Execution Instructions and source:
    run app.main from jdeveloper and app.main2 as a plsql stored procedure. I have included my test procedure at the end and the plsql stored procedure package declarations. I used debuggers and breakpoints to watch the process, there is probably a way to do this by outputting the current memory being used by I didn't know how. If you use debuggers and breakpoints then when running in JDeveloper put your breakpoints on the 3 assignments of breakpointVar in SimpleClass.main(...). When running the stored procedure test block put them on the 3 assignments of breakpoint_var in there.
    package mypackage2;
    public class app {
    private static SimpleClass topObject;
    public static void main(String[] args) {
    int breakpointVar;
    breakpointVar = 0;
    main2(30, 50);
    breakpointVar = 1;
    release();
    breakpointVar = 2;
    public static void main2(int numParents, int numChildren){
    SimpleClass temp;
    SimpleClass child;
    topObject = new SimpleClass();
    for(int i = 0; i < numParents; i ++){
    temp = new SimpleClass();
    addProperties(temp, 30);
    topObject.addChild(temp);
    for(int j = 0; j < numChildren; j++){
    child = new SimpleClass();
    addProperties(child, 30);
    temp.addChild(child);
    public static void release(){
    topObject.releaseAllDecendents();
    topObject.release();
    System.gc();
    private static void addProperties(SimpleClass toAddTo, int numProps){
    cimxProperty toAdd;
    for(int i = 0; i < numProps; i ++){
    toAdd = new cimxProperty("prop "+i,"value "+i);
    toAddTo.addProperty(toAdd);
    package mypackage2;
    import java.util.Vector;
    public class SimpleClass {
    private Vector _children;
    private Vector _props;
    private SimpleClass _parent;
    public SimpleClass() {
    _children = new Vector(10, 5);
    _props = new Vector(10, 5);
    _parent = null;
    public void addChild(SimpleClass toAdd) {
    toAdd._parent = this;
    _children.add(toAdd);
    public SimpleClass getChild(int index){
    return (SimpleClass)_children.get(index);
    public void addProperty(cimxProperty toAdd){
    _props.add(toAdd);
    public cimxProperty getProperty(int index) {
    return (cimxProperty)_props.get(index);
    public void releaseAllDecendents()
    SimpleClass temp;
    //remove all references to the the parent object from the children.
    for(int i = 0; i < _children.size(); i ++)
    temp = (SimpleClass)this._children.get(i);
    temp.releaseAllDecendents();
    temp._parent = null;
    temp._props.clear();
    temp._children.clear();
    temp = null;
    this._children.clear();
    public void release() {
    this._parent = null;
    this._children.clear();
    this._props.clear();
    package mypackage2;
    public class cimxProperty
    private static String _dateFormat = "MM/DD/YYYY HH:MI:SS";
    private String name;
    private String value;
    private String dataType;
    public cimxProperty()
    name = "";
    value = "";
    dataType = "";
    public cimxProperty(String Name, String Value)
    name = Name;
    value = Value;
    dataType = "UNKNOWN";
    public cimxProperty(String Name, String Value, String DataType)
    name = Name;
    value = Value;
    dataType = DataType;
    public String toString()
    return name + "["+dataType + "]: " + value;
    public void setName(String name)
    this.name = name;
    public String getName()
    return name;
    public void setValue(String value)
    this.value = value;
    public String getValue()
    return value;
    public void setDataType(String DataType)
    this.dataType = DataType;
    public String getDataType()
    return dataType;
    CREATE OR REPLACE PACKAGE JAVA_MEMORY_TEST AUTHID CURRENT_USER AS PROCEDURE release; PROCEDURE main2(p_num_parents IN NUMBER, p_num_children IN NUMBER); END JAVA_MEMORY_TEST;
    CREATE OR REPLACE PACKAGE BODY JAVA_MEMORY_TEST AS PROCEDURE release AS LANGUAGE JAVA NAME 'mypackage2.app.release()'; PROCEDURE main2(p_num_parents IN NUMBER, p_num_children IN NUMBER) AS LANGUAGE JAVA NAME 'mypackage2.app.main2(int, int)'; END JAVA_MEMORY_TEST;
    declare
    number breakpoint_var
    begin
    -- Call the procedure
    breakpoint_var := 0;
    java_memory_test.main2(30, 50);
    breakpoint_var := 1;
    java_memory_test.release();
    breakpoint_var := 2;
    end;

    When run in Oracle the resources are not released. Is there somthing special that needs to
    be called to get the garbage collector to do it's job when running in an Oracle database?Curious - I was always under the impression that you can not force garbage collection. All you could do was request it, and the JVM was free to do that when it was "good 'n ready", usually in a separate thread.
    I gather this from the API docs for system.gc() where it says "Calling this method suggests that the Java virtual machine expend effort ..." and the word "suggests" imlies that it is not required to run.

  • URL class is not being garbage collected

    I have created two instances of the URL class to specify a file location for each image. I use com.symantec.itools.javax.swing.icons.ImageIcon class to display images specified by each URL instance as icons inside a button. The setImageLocation method(URL location) of the ImageIcon class sets the location to be displayed by this icon. The following is the code snippets used to create the ImageIcon instances:
    private URL greenIconURL;
    private URL redIconURL;
    com.symantec.itools.javax.swing.icons.ImageIcon green_icon = new com.symantec.itools.javax.swing.icons.ImageIcon();
    com.symantec.itools.javax.swing.icons.ImageIcon red_icon = new com.symantec.itools.javax.swing.icons.ImageIcon();
    try
    greenIconURL = new java.net.URL
    ("file:./images/greenline.gif");
    green_icon.setImageLocation(greenIconURL);
    catch (java.net.MalformedURLException error) { }
    try
    redIconURL = new java.net.URL
    ("file:./images/redline.gif");
    red_icon.setImageLocation(redIconURL);
    catch (java.net.MalformedURLException error) { }
    I am using JProbe 5.0.1 Memory to determine the loitering objects when I remove the button from the JInternalFrame. I am using Java 1.2.2_08 version. The JProbe Memory Leak Doctor indicates that each URL instance has a reference to an entry in a HashMap table. The reference graph from the root set has a reference to SoftCache to HashMap to HashMap$Entry. To make this URL instance eligible for garbage collection, JProbe Memory Leak Doctor indicates I must remove the entry from the HashMap. How do I get access to this HashMap to remove the entry? If this is a problem with the version of the JDK, please let me know. Thank you in advance for your assistance.

    <root>Statics
    -->sun.misc.SoftCache->java.util.HashMap->java.util.Has
    Map$Entry[]->java.util.HashMap$Entry->java.net.URL
    I do not an instance of HashMap in my class.
    Therefore, the HashMap is either created by URLclass
    or the
    com.symantec.itools.javax.swing.icons.ImageIcon
    class.SoftCache seems to have a normal HashMap inside
    it/* Hash table mapping keys to ValueCells */
    private Map hash;but if that is the HashMap in JProbe
    information then the URL would have to be a key in
    the map - otherwise there'd be another object in the
    chain of class SoftCache.ValueCell
    are you certain that the java.net.URL's in that
    hashmap are your ones?
    out of curiosity - are you certain that the URL's are
    the/a problem (are you getting an OutOfMemoryError?)
    asjfThe button that contains the URL's is the only one on the JInternalFrame. The JProbe Memory Debugger displays the java.net package name, the URL class name, the count (2), and the Count Change (+2). When I remove the button from the JInternalFrame, the aforementioned numbers on the Instance Summary remain the same. The snapshot of the Java Heap reveals that the two instances of the URL class are still there. The Memory Leak Doctor shows the reference graph from the root set:
    <root>Statics->SoftCache->HashMap->HashMap$Entry[]->HashMap$Entry->URL
    When I right click on the arrow between HashMap$Entry[] and HashMap$Entry to remove the reference, I receive the message: "Congratulations this object can be garbage collected..." It appears like private instance of Map in SoftCache is holding a strong reference.
    I am not getting an OutOfMemoryError exception.

  • Garbage Collection not releasing memory properly

    Hello, In my web application memory is not releasing properly, after some point of time application throw out of memory error, we are using tomcat5, jdk5, my heap size is half of the RAM.Garbage Collection not releasing memory properly.

    sabre150 wrote:
    punter wrote:
    georgemc wrote:
    Yep. Couldn't be a problem with your code, it must be that garbage collection doesn't work and nobody else noticed. Raise a bug with Sun.Are you serious ?You need to replace your sarcasm detector.I have blowed my sarcasm meter and limping in the blindness !!!! :(

  • 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

  • Entity Beans not getting garbage collected

    Hi,
    I am developing an application that is using EJBs utilizing several common design patterns (i.e. Session Facade, DAO, and Fast Lane Reader). All of the patterns used have come from books by Sun Microsystems Press.
    As I have understood the pattern, the Session Facade pattern uses Stateless Session Beans (SLSB) to implement a desired functionality and accesses the entity beans locally. The results from the entity beans are placed into Value Objects and passed back to the client separating any direct access with the entity beans from the client. In my case, I am using BMP for my entity beans.
    The problem I am seeing with Optimizeit is that none of my entity beans are getting garbage collected despite no references to them. The SLSB creates what entities it needs to perform a task at the local level, puts the data into a value object and goes out of scope.
    Shouldn't the entity beans get removed if the object that references them has gone away or am I missing something?
    Is there a proper way to set an entity bean (or any EJB for that matter) for garbage collection.
    thanks in advance for any help...

    You might even discover that entity beans can get created even before you use them.
    Your application server creates "pools" of bean instances that it can use when it needs to. It is part of this role, and is done in order to optimize performances.
    You cannot force them to be garbage collected. Even if you stop referencing them, the app server will.
    When your create references to a bean, it (usually) won't create an instance. It will take an existing one, and load data into it, using ejbCreate or ejbActivate.
    Hope this helps.
    /Stephane

  • Help needed!! Novice with Garbage Collection problems.

    Hi Guys,
    Really hoping somebody can help me here. I am a relative novice when it comes to all things Java but i am slowly trying to learn. I have come across an issue which i have identified but i am just not sure what to do about it.
    Ok, in a nut shell the issue seems to be revolving around the frequency of garbage collection. From the default-err.log file i am seeing (on average) an Allocation Failure occur every 2 secs. Here is a sample from the log with verbose:gc active:
    <AF[4986]: Allocation Failure. need 208480 bytes, 78 ms since last AF>
    <AF[4986]: managing allocation failure, action=2 (559165976/1342176248)>
    <GC: Mon Oct 11 11:51:12 2004
    <GC(4986): freed 4101528 bytes in 1559 ms, 41% free (563267504/1342176248)>
    <GC(4986): mark: 1301 ms, sweep: 258 ms, compact: 0 ms>
    <GC(4986): refs: soft 0 (age >= 32), weak 0, final 0, phantom 0>
    <AF[4986]: completed in 1563 ms>
    <AF[4987]: Allocation Failure. need 208536 bytes, 78 ms since last AF>
    <AF[4987]: managing allocation failure, action=2 (559138336/1342176248)>
    <GC: Mon Oct 11 11:51:14 2004
    <GC(4987): freed 4105128 bytes in 1563 ms, 41% free (563243464/1342176248)>
    <GC(4987): mark: 1293 ms, sweep: 270 ms, compact: 0 ms>
    <GC(4987): refs: soft 0 (age >= 32), weak 0, final 0, phantom 0>
    <AF[4987]: completed in 1563 ms>
    As you can see, allocation failures are occuring all the time, and with 2secs between events, and each GC taking around 1.5secs, i am having massive problems with the response of the server. It seems that the javaw.exe process is just pegged at 100% CPU the whole time and then it will eventually grind to a halt, and the users will get terrible response times.
    OK, the questions are:
    - Even to me (a novice) the above extract from the log doesnt look good. Am i right?
    - what would be causing this? (i know - how long is a peice of string but i am hoping somebody can point me in the right direction so i can look some more)
    - what can i do about it? Is there any parameters i can put into the java args to help me out?
    Currently i am running -Xms of 128meg and an -Xmx of 1024m with no other settings. There are at the moment about 200users logged onto this server concurrently, and it seems to die a couple of hours into them all being logged on. I then have to kick everybody out and reboot to get it in a working state again.
    I am in some serious need of help from some gurus!! any help would be invaluable, thanks heaps guys.
    Tim

    Hi Again guys, thanks for all your replies.
    I have been working my butt of on this issue and i just cant seem to get anywhere... probably due to my complete lack of knowledge on this whole GC thing! :)
    One thing that i have noticed that seems to be very consistant is the fact that as soon as i get an "action=2" in my default-err.log from an allocation failure, thats when the system goes nuts and tends to not recover.
    At all other times it is an action=1, and the system seems to be running OK, but as soon as i get action=2, the time between GC events drop from seconds to miliseconds, and the bytes required just skyrockets. It keeps on this upward spiral till i just have to reboot the box.
    From all my reading, i have found that an action=2 means "2 - The Garbage Collector has tried to allocate out of the wilderness, and failed."
    This is the only item in the logs that i see is directly related to the server performance.
    Can anybody please explain to me (in laymans terms) what the action=2 means, what may cause it and what i should be looking at changing to fix it?
    The extract from the log files (in my first post in this thread) are still valid, as are the min/max memory settings.
    Any help at all would be invaluable.
    Thanks very much.
    Tim

  • Hotspot core dumping during JVM garbage collection ?

    We have an application which calls a 3rd party supplied server API which has recently been upgraded to use Java 1.5
    We are getting the following error reported by our client application. The application is also now running Java 1.5 but references many classes in jar files which would have quite old code in.
    The supplier of the API has stated that the problem requires us to recompile all our jar files using v 1.5 ( including things like jconnect and jms ?!?!? ). This sounds like a bit of a cop-out to me, not to mention being impossible since we don't have the source for things like jconnect.
    I suspect that there is a garbage collection problem at the bottom of all this, but I'm not sure how I can "prove" this, nor do I currently have any real clue as to how to fix any GC problem that may exist.
    The application is supposed to wait for a message on a MQSeries queue and then transforms it via Xalan XSLT and sends it to a Server application. I've tried playing around with heap sizes etc but that just seems to make it worse. If I leave it at the settings that the previous version used then the client at least manages to process a couple of messages before core dumping. There doesn't seem to be a consistent trigger event to cause the core dump ( it's not a message arriving on a queue for example ) but it does seem to be fairly consistent timewise, i.e. after
    Any ideas gratefully accepted.
    Here's a logfile excerpt from my applications showing the Hotspot error message :
    =====================================================================================
    08-Jul-2008 10:01:05 Waiting for messages from COLT.BBFS
    08-Jul-2008 10:02:05 Waiting for messages from COLT.BBFS
    08-Jul-2008 10:03:05 Waiting for messages from COLT.BBFS
    405.815: [GC [PSYoungGen: 17331K->9244K(37632K)] 111702K->103615K(192128K), 0.1615910 secs]
    405.977: [Full GC#
    # An unexpected error has been detected by HotSpot Virtual Machine:
    #  SIGBUS (0xa) at pc=0xfe141348, pid=2600, tid=8
    # Java VM: Java HotSpot(TM) Server VM (1.5.0_03-b07 mixed mode)
    # Problematic frame:
    # V  [libjvm.so+0x141348]
    # An error report file with more information is saved as hs_err_pid2600.log
    # If you would like to submit a bug report, please visit:
    # http://java.sun.com/webapps/bugreport/crash.jsp
    =====================================================================================
    The logfile referred to in the error message contains the following.
    =====================================================================================
    # An unexpected error has been detected by HotSpot Virtual Machine:
    # SIGBUS (0xa) at pc=0xfe141348, pid=2600, tid=8
    # Java VM: Java HotSpot(TM) Server VM (1.5.0_03-b07 mixed mode)
    # Problematic frame:
    # V [libjvm.so+0x141348]
    --------------- T H R E A D ---------------
    Current thread (0x001484d8): VMThread [id=8]
    siginfo:si_signo=10, si_errno=0, si_code=1, si_addr=0x0000080f
    Registers:
    O0=0x00487588 O1=0xfe7d6454 O2=0x000079b0 O3=0x00007800
    O4=0x00008868 O5=0x00147d48 O6=0xf8781460 O7=0xfe0f7938
    G1=0xe52aaae8 G2=0x00000003 G3=0x00000003 G4=0x001484d8
    G5=0xf8781d98 G6=0x00000002 G7=0xf8781d98 Y=0x805683e2
    PC=0xfe141348 nPC=0xfe14134c
    Top of Stack: (sp=0xf8781460)
    0xf8781460: fe786000 00c6ba20 fe10013c e54bab68
    0xf8781470: 0000080f e54bab6c 0000080f 00000004
    0xf8781480: 00487588 00000134 e54bab6c 00000004
    0xf8781490: 00000001 00000000 f87814c0 fe17aef4
    0xf87814a0: fe6485b4 fe7d899c 001484d8 0011da40
    0xf87814b0: 00148988 00148c10 00148d7c f8781880
    0xf87814c0: 007c3389 007c3c0e 00000f87 00008868
    0xf87814d0: 00008800 00487588 fe141310 fe7d6454
    Instructions: (pc=0xfe141348)
    0xfe141338: ec 06 c0 1a 80 a5 a0 00 22 40 00 0a ba 07 60 01
    0xfe141348: f2 05 a0 00 ae 0e 60 03 80 a5 e0 03 22 40 00 05
    Stack: [0xf8702000,0xf8781d98), sp=0xf8781460, free space=509k
    Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
    V [libjvm.so+0x141348]
    V [libjvm.so+0x17aefc]
    V [libjvm.so+0x2d557c]
    V [libjvm.so+0x300ef8]
    V [libjvm.so+0x301e84]
    V [libjvm.so+0x2ff950]
    V [libjvm.so+0x29df30]
    V [libjvm.so+0x362b44]
    V [libjvm.so+0x6436f0]
    VM_Operation (0xe03012b0): parallel gc system gc, mode: safepoint, requested by thread 0x0031bca0
    --------------- P R O C E S S ---------------
    Java Threads: ( => current thread )
    0x00b2c028 JavaThread "Thread-4" [_thread_in_native, id=85]
    0x007f5048 JavaThread "Thread-0" [_thread_blocked, id=84]
    0x00c27cf0 JavaThread "Notification Delivery" [_thread_blocked, id=81]
    0x0026fa08 JavaThread "RMI LeaseChecker" daemon [_thread_blocked, id=73]
    0x00821048 JavaThread "RMI RenewClean-[162.11.2.32:44425]" daemon [_thread_blocked, id=70]
    0x0031bca0 JavaThread "GC Daemon" daemon [_thread_blocked, id=67]
    0x00cd5d28 JavaThread "RMI Reaper" [_thread_blocked, id=66]
    0x003c9300 JavaThread "Timer-0" daemon [_thread_blocked, id=65]
    0x00929fe0 JavaThread "RMI TCP Accept-0" daemon [_thread_in_native, id=64]
    0x0089bf18 JavaThread "SeedGenerator Thread" daemon [_thread_blocked, id=42]
    0x00c47248 JavaThread "Pool thread #7" daemon [_thread_blocked, id=38]
    0x00c466a0 JavaThread "Pool thread #6" daemon [_thread_blocked, id=37]
    0x00311850 JavaThread "Pool thread #5" daemon [_thread_blocked, id=36]
    0x00287a40 JavaThread "Pool thread #4" daemon [_thread_blocked, id=35]
    0x00286e98 JavaThread "Pool thread #3" daemon [_thread_blocked, id=34]
    0x00c134b0 JavaThread "Pool thread #2" daemon [_thread_blocked, id=33]
    0x00ad09e0 JavaThread "Pool thread #1" daemon [_thread_blocked, id=32]
    0x00286cd8 JavaThread "PoolThreadManager" daemon [_thread_blocked, id=31]
    0x00c129e0 JavaThread "Channel Reaper" daemon [_thread_blocked, id=30]
    0x00c669e8 JavaThread "ORB Daemon Thread" daemon [_thread_blocked, id=29]
    0x00b10170 JavaThread "Worker for ServerProtocol: (iiop) /0.0.0.0:20168" daemon [_thread_blocked, id=22]
    0x008a17e0 JavaThread "Syn~ Client" daemon [_thread_blocked, id=21]
    0x003dc378 JavaThread "PoolScavenger0" daemon [_thread_blocked, id=20]
    0x0015a928 JavaThread "Low Memory Detector" daemon [_thread_blocked, id=15]
    0x00159880 JavaThread "CompilerThread1" daemon [_thread_blocked, id=14]
    0x00158a18 JavaThread "CompilerThread0" daemon [_thread_blocked, id=13]
    0x00157b98 JavaThread "AdapterThread" daemon [_thread_blocked, id=12]
    0x00156dc8 JavaThread "Signal Dispatcher" daemon [_thread_blocked, id=11]
    0x0014ccd8 JavaThread "Finalizer" daemon [_thread_blocked, id=10]
    0x0014ad90 JavaThread "Reference Handler" daemon [_thread_blocked, id=9]
    0x00038238 JavaThread "main" [_thread_in_native, id=1]
    Other Threads:
    =>0x001484d8 VMThread [id=8]
    0x0015c3b0 WatcherThread [id=16]
    VM state:at safepoint (normal execution)
    VM Mutex/Monitor currently owned by a thread: ([mutex/lock_event])
    [0x00037728/0x00037758] Threads_lock - owner thread: 0x001484d8
    [0x00033650/0x00037ba8] Heap_lock - owner thread: 0x0031bca0
    Heap
    PSYoungGen total 37632K, used 9244K [0xf2eb0000, 0xf7ba0000, 0xf8400000)
    eden space 28352K, 0% used [0xf2eb0000,0xf2eb0000,0xf4a60000)
    from space 9280K, 99% used [0xf4a60000,0xf5367080,0xf5370000)
    to space 25216K, 0% used [0xf6300000,0xf6300000,0xf7ba0000)
    PSOldGen total 154496K, used 94371K [0xe8400000, 0xf1ae0000, 0xf2eb0000)
    object space 154496K, 61% used [0xe8400000,0xee028e78,0xf1ae0000)
    PSPermGen total 35584K, used 18260K [0xe4400000, 0xe66c0000, 0xe8400000)
    object space 35584K, 51% used [0xe4400000,0xe55d5158,0xe66c0000)
    Dynamic libraries:
    0x00010000      /dsdvlp/java/jvm/jdk1.5.0_03/bin/java
    0xff350000      /usr/lib/libthread.so.1
    0xff340000      /usr/lib/libdl.so.1
    0xff200000      /usr/lib/libc.so.1
    0xff390000      /usr/platform/SUNW,Sun-Fire-880/lib/libc_psr.so.1
    0xfe000000      /dsdvlp/java/jvm/jdk1.5.0_03/jre/lib/sparc/server/libjvm.so
    0xff1e0000      /usr/lib/libsocket.so.1
    0xff2d0000      /usr/lib/libsched.so.1
    0xff1b0000      /usr/lib/libCrun.so.1
    0xff160000      /usr/lib/libm.so.1
    0xff080000      /usr/lib/libnsl.so.1
    0xff060000      /usr/lib/libmp.so.2
    0xff030000      /dsdvlp/java/jvm/jdk1.5.0_03/jre/lib/sparc/native_threads/libhpi.so
    0xfdfc0000      /dsdvlp/java/jvm/jdk1.5.0_03/jre/lib/sparc/libverify.so
    0xfdf80000      /dsdvlp/java/jvm/jdk1.5.0_03/jre/lib/sparc/libjava.so
    0xfdf50000      /dsdvlp/java/jvm/jdk1.5.0_03/jre/lib/sparc/libzip.so
    0xfb7e0000      /usr/lib/locale/en_GB.ISO8859-1/en_GB.ISO8859-1.so.2
    0xe4190000      /dsdvlp/java/jvm/jdk1.5.0_03/jre/lib/sparc/libnet.so
    0xe3bd0000      /dsdvlp/lib/5/libSolarisNatives.so
    0xe3e90000      /dsdvlp/java/jvm/jdk1.5.0_03/jre/lib/sparc/librmi.so
    VM Arguments:
    jvm_args: -Djava.ext.dirs=/dsdvlp/java/tmijar/firs7/lib/cli:/dsdvlp/java/tmijar/firs7/lib/cli/ext:/dsdvlp/java/tmijar/firs7/lib/cmn/OpenORB:/dsdvlp/java/tmijar/firs7/lib/cmn/OpenORB/ext:/dsdvlp/java/tmijar/firs7/lib/cmn:/dsdvlp/java/tmijar/firs7/lib/cmn/ext:/dsdvlp/java/tmijar/firs7/daemonlib -Duser.dir=/dsdvlp/java/tmijar/firs7 -Dopenorb.config=file:/dsdvlp/java/tmijar/firs7/configs/OpenORB/config/SynOpenORB.xml -Dopenorb.home=file:/dsdvlp/java/tmijar/firs7/configs/OpenORB -Dcom.coexis.syn.general.orbbinding=com.coexis.syn.general.orbbinding.openorb.OpenORBBinding_1_4 -Dsun.rmi.dgc.client.gcInterval=360000 -Dsun.rmi.dgc.server.gcInterval=360000000 -Xms32m -Xmx256m -Dcom.coexis.syn.clientcommandsconfiglocation=file://localhost//dsdvlp/java/tmijar/firs7/configs/clientcommands.xml -Dcom.coexis.syn.clientconfiglocation=file://localhost//dsdvlp/java/tmijar/firs7/configs/fsbbtd_client.xml -XX:+PrintGCTimeStamps -XX:+PrintGCDetails
    java_command: com.coexis.syn.mqmessaging.daemon.RunDaemon -p /dsdvlp/bin/5/lndsfsd_fsbbtd.properties start
    Environment Variables:
    JAVA_HOME=/dsdvlp/java/jvm/jdk150
    CLASSPATH=.:/dsdvlp/java/jar/jconnect520.jar:/dsdvlp/java/jar/vbjapp340.jar:/dsdvlp/java/jar/vbjorb340.jar:/dsdvlp/java/jar/javax_jndi120.jar
    PATH=/usr/local/etc:/usr/lang:/usr/openwin/bin:/usr/ucb:/bin:/usr/etc:/usr/local/5/bin:/dsdvlp/bin/5:/dsdvlp/bin/4:/home/app/sybase/5/bin:/home/app/sybase/5/localscripts:/home/app/sybase/5/sqr:/home/app/lang:/home/app/lang/SC2.0.1:/usr/ccs/bin:/usr/local/opt/Acrobat3/bin:/dsdvlp/bin:.
    LD_LIBRARY_PATH=/dsdvlp/java/jvm/jdk1.5.0_03/jre/lib/sparc/server:/dsdvlp/java/jvm/jdk1.5.0_03/jre/lib/sparc:/dsdvlp/java/jvm/jdk1.5.0_03/jre/../lib/sparc:/usr/lib:/usr/openwin/lib:/usr/local/5/lib:/dsdvlp/lib/5:/dstest/lib/5:/home/app/sybase/5/lib:/dstest/cats/sun4/lib:/tmitest/Opus/opus/lib
    SHELL=/bin/csh
    DISPLAY=CLI00184.mfil.local:1.0
    OS=5
    --------------- S Y S T E M ---------------
    OS: Solaris 8 2/02 s28s_u7wos_08a SPARC
    Copyright 2002 Sun Microsystems, Inc. All Rights Reserved.
    Assembled 18 December 2001
    uname:SunOS 5.8 Generic_117350-20 sun4u (T1 libthread)
    rlimit: STACK 8192k, CORE 9216k, NOFILE 4096, AS infinity
    load average:2.24 2.67 2.68
    CPU:total 4 has_v8, has_v9, has_vis1, has_vis2, is_ultra3
    Memory: 8k page, physical 8388608k(166384k free)
    vm_info: Java HotSpot(TM) Server VM (1.5.0_03-b07) for solaris-sparc, built on Apr 13 2005 03:31:26 by unknown with unknown Workshop:0x550

    The very first suggestion I have is to move your VM to a more recent update of 1.5.0.
    It looks like you are crashing with 5.0u3, and I'm pretty sure 5.0u16 is available. You
    don't want to waste your time chasing a bug that's already been fixed.

  • High Eden Java Memory Usage/Garbage Collection

    Hi,
    I am trying to make sure that my Coldfusion Server is optomised to the max and to find out what is normal limits.
    Basically it looks like at times my servers can run slow but it is possible that this is caused by a very old bloated code base.
    Jrun can sometimes have very high CPU usage so I purchased Fusion Reactor to see what is going on under the hood.
    Here are my current Java settings (running v6u24):
    java.args=-server -Xmx4096m -Xms4096m -XX:MaxPermSize=256m -XX:PermSize=256m -Dsun.rmi.dgc.client.gcInterval=600000 -Dsun.rmi.dgc.server.gcInterval=600000 -Dsun.io.useCanonCaches=false -XX:+UseParallelGC -Xbatch ........
    With regards Memory, the only memory that seems to be running a lot of Garbage Collection is the Eden Memory Space. It climbs to nearly 1.2GB in total just under every minute at which time it looks like GC kicks in and the usage drops to about 100MB.
    Survivor memory grows to about 80-100MB over the space of 10 minutes but drops to 0 after the scheduled full GC runs. Old Gen memory fluctuates between 225MB and 350MB with small steps (~50MB) up or down when full GC runs every 10 minutes.
    I had the heap set to 2GB initally in total giving about 600MB to the Eden Space. When I looked at the graphs from Fusion Reactor I could see that there was (minor) Garbage Collection about 2-3 times a minute when the memory usage maxed out the entire 600MB which seemed a high frequency to my untrained eye. I then upped the memory to 4GB in total (~1.2GB auto given to Eden space) to see the difference and saw that GC happened 1-2 times per minute.
    Is it normal in Coldfusion that the Eden memory would grow so quickly and have garbage collection run so often? i.e do these graphs look normal?
    Also should I somehow redistribute the memory available to give the Eden memory more since it seems to be where all the action is?
    Any other advice for performance improvements would be much appreciated.
    Note: These graphs are not from a period where jrun had high CPU.
    Here are the graphs:
    PS Eden Space Graph
    PS Survivor Space Graph
    PS Old Gen Graph
    PS Perm Gen Graph
    Heap Memory Graph
    Heap/Non Heap Memory Graph
    CPU Graph
    Request Average Execution Time Graph
    Request Activity Graph
    Code Cache Graph

    Hi,
    >Is it normal in Coldfusion that the Eden memory would grow so quickly and have garbage collection run so often?
    Yes normal to garbage collect Eden often. That is a minor garbage collection.
    >Also should I somehow redistribute the memory available to give the Eden memory more since it seems to be where all the action is?
    Sometimes it is good to set Eden (Eden and its two Survivor Spaces combined make up New or Young Generation part of JVM heap) to a smaller size. I know your thinking - what make it less, but I want to make it bigger. Give less a try (sometimes less = more, bigger not = better) and monitor the situation. I like to use -Xmn switch, some sources say to use other method/s. Perhaps you could try java.args=-server -Xmx4096m -Xms4096m -Xmn172m etc. I better mention make a backup copy of jvm.config before applying changes. Having said that now you know how you can set the size to bigger if you want.
    I think the JVM is perhaps making some poor decisions with sizing the heap. With Eden growing to 1Gb then being evacuated not many objects are surviving and therefore not being promoted to Old Generation. This ultimately means the object will need to be loaded again latter to Eden rather than being referenced in the Old generation part of the heap. Adds up to poor performance.
    >Any other advice for performance improvements would be much appreciated.
    You are using Parallel garbage collector. Perhaps you could enable that to run multi-threaded reducing the time duration of the garbage collections, jvm args ...-XX:+UseParallelGC -XX:ParallelGCThreads=N etc where N = CPU cores (eg quad core = 4).
    HTH, Carl.

  • 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

Maybe you are looking for

  • Spry menu displays as bullets [was; NEED HELP PLEASE]

    Thank you for taking the time to help me with this: when ever I create the spry menu bar in Dreamweaver it sets it as bullets, it isnt noticeable in dreamweaver or when I test it in safari,firefox, etc.. but as soon as I upload it to the ftp host it

  • Get rid of Adobe Reader FOREVER & still read all PDFs online?

    I have this problem. I hate ADOBE ACROBAT READER. I install it when I have to, and more and more it seems that if I want to look at a PDF online, Preview doesn't get the chance because the Adobe Reader butts in and reports that it can't find an Adobe

  • Why can I only text 10 people with the IPhone 4s

    Why can I only text 10 people at a time with the IPhone 4s?

  • WLC 5508 - Clients disconnecting

    I am running WLC 5508 7.2.111.3 with some 2602i AP. Last week one user reported his new macbook pro 2013 was encountering connectivity issues.His older macbook pro 2009 was working perfectly. The user is sitting in the middle of 2nd floor having equa

  • How can I update my PowerBook Pro from OS X 10.5.8?

    I'd like to upgrade some of my software, but I need to upgrade my operating system first.  I have an 2.4 GHz Intel Dual Core 2 Processor,   2BG 667 MHz DDR2 SDRAM. and 21 GB free on my HD.  Do I need to update to 10.6, then 10.7, then 10.8 etc or can