krishna bulusu

Ranch Hand
+ Follow
since Aug 28, 2006
Cows and Likes
Cows
Total received
0
In last 30 days
0
Total given
0
Likes
Total received
1
Received in last 30 days
0
Total given
0
Given in last 30 days
0
Forums and Threads
Scavenger Hunt
expand Ranch Hand Scavenger Hunt
expand Greenhorn Scavenger Hunt

Recent posts by krishna bulusu

Hi,

Thanks for your replies.
Is there any way to 'request' Explicit GC(System.gc()) if we can't force it?
For our production, it would be very useful for us to clean up the unreachable objects in regular basis instead of having them on our heap and let the GC clean them when it is short by memory.


10 years ago
Hi,

Thanks for your reply.
I will Explain my question in more detail.
We have the below JVM parameters on our production system:

-Dsun.rmi.dgc.client.gcInterval=3600000
-Dsun.rmi.dgc.server.gcInterval=3600000


We observed on the logs that, Full GC is happening in every 1 hour. Below is the sample Log satement.

3780.425: [Full GC [PSYoungGen: 17367K->0K(484544K)] [ParOldGen: 687597K->404076K(1094848K)] 704964K->404076K(1579392K) [PSPermGen: 50827K->50247K(101120K)], 1.3162930 secs]

After 24 hours of the server restart, I have taken the heap dump of my production JVM. Its about 1.5GB.
After given it to the Eclipse Memory Analyzer, the size comes to 140MB!!(Eclipse Memory analyzer parsed it and removes all the unreachable objects.) The Eclipse Memory analyzer shows that, the Unreachable objects size is about 1.3GB!!

Can I assume that, after running the Full GC every hour by below JVM parameters, the unreachable objects should be cleaned up? Does the below JVM parameters forces Full GC which claims the unreachable objects (or) its related to RMI objects only?

-Dsun.rmi.dgc.client.gcInterval=3600000
-Dsun.rmi.dgc.server.gcInterval=3600000
10 years ago
Hi,

We would like to run Full GC for every 1 hour on our production system. What I found was, be setting below JVM parameters, we can force the Full GC on the JVM heap.

-Dsun.rmi.dgc.client.gcInterval=3600000
-Dsun.rmi.dgc.server.gcInterval=3600000


Can somebody tell me the real purpose of the above statements? Would Full GC run every 1 hour and all the unreachable objects gets cleaned by the full GC which was triggered by above parameters?

I read some where that, only RMI objects which are unreachable gets cleaned by the above JVM Parameters.
Please can somebody help me?
10 years ago
Hi Newton,

My question is: Is there are any relation between the Resident size and the heap dump size for java process on Linux systems? For us, the Resident memory size is 2GB where as the heap dump size is about 300MB. Is this normal or do you see any issues with this?

10 years ago
Hi,

Please can somebody help me?

Thanks,
Bala.
10 years ago
Hi,

Thanks for your reply.
I am producing the heap dump by following method:
kill -3 <pid>

After the above command, a heap dump in being produced in hprof format

We are using Eclipse Memory Analyzer tool to analyze the heap dump. Initially, It has shown few leak suspects which I have fixed. Now, the heap seems to be OK. However, the size of the Resident memory is alarming and not matching with the size of the heap dump.


10 years ago
Hi,

We have our production running under Red ha Linux environment. We are using JDK 1.5.19 version. We are using Tomcat 6.0.18 as our web server.
What we observe is, the heap dump size and the resident memory sizes are not matching at all. If the Resident memory(RES) size is at 2GB, the heap dump size is 220MB. We are having a huge performance hit due to this.
Is this normal pattern or are we facing memory leak? We have analyzed the heap dump and fixed few issues in it. However, what we think is, memory is leaking not in the heap but some where else. Please can somebody help us on this.

PS: Sorry for the re post... Nobody is answering this on Java forum
10 years ago
Hi,

We have our production running under Red ha Linux environment. We are using JDK 1.5.19 version. We are using Tomcat 6.0.18 as our web server.
What we observe is, the heap dump size and the resident memory sizes are not matching at all. If the Resident memory(RES) size is at 2GB, the heap dump size is 220MB. We are having a huge performance hit due to this.
Is this normal pattern or are we facing memory leak? We have analyzed the heap dump and fixed few issues in it. However, what we think is, memory is leaking not in the heap but some where else. Please can somebody help us on this.

10 years ago
Please can somebody help me on this...
10 years ago
Hi Bill,

Thanks for your reply. I must admit that tomcat do destroy the inactive sessions after expiration. What I have done is, implemented Session Listener interface and in session destroyed method, I placed a log statement. After some period of time, I found a log statement saying session was destroyed. Thanks for your help on this.

Thanks,
Bala.
10 years ago
Hi,

We are using Tomcat 6.0.18 on Linux environment for our production.
We have enabled SSL by deploying SSL ertificates. We observed that, over a period of time, the memory consumption is increasing and we are facing serious performance issues.
I have taken a heap dump and analyzed it using Eclipse Memory analyzer. What I found was, com.sun.net.ssl.internal.ssl.SSLSocketImpl objects are never Garbage collected.
The leak report by Memory analyzer is as follows:
2,996 instances of com.sun.net.ssl.internal.ssl.SSLSocketImpl", loaded by "<system class loader>" occupy 219,843,760 (62.76%) bytes
Upon drilling down, these objects are being held by finalizer method of GC.
I have got the following similar link:
http://forums.sun.com/thread.jspa?threadID=5266266

Can anybody tell me if there is any memory leak issues exists with Tomcat 6.0.18? I read some where that, the memory leak issue with SSL was fixed on 6.0.20.

10 years ago
Tim,

Thanks for your reply.

I understand what you said. Just tell me what will happen in the below case:
A session object has been created on the memory. User closes the window without performing the log out action. So, there will not be any communication from client(Browser) to this session object.

Would there be any thread running on Tomcat server which checks every session object and cleans it if the session time out period for a particular session object exceeds (or) The session object waits till some communication happens to it indefinitely (May be till next server restart in which case all objects on the memory will be deleted)
10 years ago
Thank you William for your reply. I will give more details now.

What we are doing is: When ever any user logs in, we are storing his session details on DB. If he click on log out link, then, we are calling session.invalidate method which triggers User Counter Listener to call, where we are deleting the session from DB.
My assumption is, when ever the Tomcat server calls invalidate method on any session, the user counter listener class will be invoked as it implements HttpSessionAttributeListener interface. in Attribute removed method, we are deleting the Session information from DB.

Now, What I observed is, if the user closes the window without log out, the session information is present on the DB though the time out period expires!! Can I assume from this that the session is already existed on memory?
Please note, we have configured the session time out period on web.xml file.


10 years ago
Hi,

We are facing Performance issues with the Tomcat server.
I have one question about Tomcat Sessions. When the user logs in, a session will be created by the Tomcat. The session will be invalidated once the user clicks on log out link.
If the user is idle for some period of time and the session time out limit exceeds, then, if the user does some operation on the same session. then, the session will be expired.

My question:
What will happen, if the user closes the browser window without log out? What will happen to the session? Would it be cleaned up by GC after some time or would it be accumulated on the heap in inactive mode. I suspect, this is the issue with our production system. Please can somebody explain this scenario and possible fix for this?
10 years ago