RE: garbage collection problem with class sun.reflect.GeneratedMethodAccessor
From: dharshana vanderbona [mailto:[EMAIL PROTECTED] Subject: Fwd: garbage collection problem with class sun.reflect.GeneratedMethodAccessor After running the system for sometime with around 50 users I noticed that the system is starting to fillup the memory. But strangely even after all the users have disconnected, the amount of used memory did not change (see below).. Thereafter I put %System.gc();% inside a jsp and called it, and I was able to see that it freed up all the memory and brought the application to normal state again... Can someone please let me know what is going wrong here.. Nothing's going wrong - all that you've described is perfectly normal and expected behavior. Garbage collection does not run until it has to, or it's forced, via the System.gc() call. - Chuck THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Garbage Collection
Hi There, Tomcat does not control the garbage collection, it is up to the JVM to decide if and when a garbage collection is performed. The only way you can request a garbage collection is by using the System.gc() method, which the JVM can ignore. For more information on this Topic read the documentation for the JVM that you are using. Pete -Original Message- From: Durfee, Bernard [mailto:[EMAIL PROTECTED] Sent: 12 April 2005 20:12 To: Tomcat Users List Subject: Garbage Collection How is garbage collection controlled in Tomcat 5.5? I ran a bit of an experiment by profiling Tomcat 5.5.7 while running a web application. I ran a load test against the application that finished with the allocated object size just below the heap size. If it grew any more, garbage collection would run. So the load test was done and with Tomcat idle, the garbage collector never ran. It would seem like a good time to run the garbage collector. As is stands now the next person to hit the application will push the heap size over the limit and they will have to wait for garbage collection. Seems like Tomcat should either attempt to trigger the garbage collector when idle. Bernard Durfee - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Garbage Collection
Right, my question was whether or not Tomcat would call System.gc() to 'suggest' to the JVM that garbage collection take place. Tomcat itself is the best authority as to how busy it is. Since Tomcat has been around for a long time I figured that this might have been implemented at some point. Bernard Durfee -Original Message- From: Pete Guyatt [mailto:[EMAIL PROTECTED] Sent: Tuesday, April 12, 2005 3:33 PM To: Tomcat Users List Subject: RE: Garbage Collection Hi There, Tomcat does not control the garbage collection, it is up to the JVM to decide if and when a garbage collection is performed. The only way you can request a garbage collection is by using the System.gc() method, which the JVM can ignore. For more information on this Topic read the documentation for the JVM that you are using. Pete -Original Message- From: Durfee, Bernard [mailto:[EMAIL PROTECTED] Sent: 12 April 2005 20:12 To: Tomcat Users List Subject: Garbage Collection How is garbage collection controlled in Tomcat 5.5? I ran a bit of an experiment by profiling Tomcat 5.5.7 while running a web application. I ran a load test against the application that finished with the allocated object size just below the heap size. If it grew any more, garbage collection would run. So the load test was done and with Tomcat idle, the garbage collector never ran. It would seem like a good time to run the garbage collector. As is stands now the next person to hit the application will push the heap size over the limit and they will have to wait for garbage collection. Seems like Tomcat should either attempt to trigger the garbage collector when idle. Bernard Durfee - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Garbage Collection (UNCLASSIFIED)
Classification: UNCLASSIFIED Caveats: NONE Pete is right. You can always REQUEST that the GC runs, but it is never guaranteed to run. Fadi -Original Message- From: Durfee, Bernard [mailto:[EMAIL PROTECTED] Sent: Tuesday, April 12, 2005 4:06 PM To: Tomcat Users List Subject: RE: Garbage Collection Right, my question was whether or not Tomcat would call System.gc() to 'suggest' to the JVM that garbage collection take place. Tomcat itself is the best authority as to how busy it is. Since Tomcat has been around for a long time I figured that this might have been implemented at some point. Bernard Durfee -Original Message- From: Pete Guyatt [mailto:[EMAIL PROTECTED] Sent: Tuesday, April 12, 2005 3:33 PM To: Tomcat Users List Subject: RE: Garbage Collection Hi There, Tomcat does not control the garbage collection, it is up to the JVM to decide if and when a garbage collection is performed. The only way you can request a garbage collection is by using the System.gc() method, which the JVM can ignore. For more information on this Topic read the documentation for the JVM that you are using. Pete -Original Message- From: Durfee, Bernard [mailto:[EMAIL PROTECTED] Sent: 12 April 2005 20:12 To: Tomcat Users List Subject: Garbage Collection How is garbage collection controlled in Tomcat 5.5? I ran a bit of an experiment by profiling Tomcat 5.5.7 while running a web application. I ran a load test against the application that finished with the allocated object size just below the heap size. If it grew any more, garbage collection would run. So the load test was done and with Tomcat idle, the garbage collector never ran. It would seem like a good time to run the garbage collector. As is stands now the next person to hit the application will push the heap size over the limit and they will have to wait for garbage collection. Seems like Tomcat should either attempt to trigger the garbage collector when idle. Bernard Durfee - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Classification: UNCLASSIFIED Caveats: NONE - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Garbage Collection
Calling System.gc() is considered to be a bad thing since this would trigger a major garbage collection which would take relatively long, compared with a minor collection. Besides this: Tomcat knows that it has nothing to do in right this moment. But does that mean that is always a good idea to make a GC now? No, maybe one millisecond later a new request will arrive and if Tomcat is then in GC, it is busy and cannot handle the request. I think this is the reason why Tomcat doesn't call the GC itself. Christoph Durfee, Bernard wrote: Right, my question was whether or not Tomcat would call System.gc() to 'suggest' to the JVM that garbage collection take place. Tomcat itself is the best authority as to how busy it is. Since Tomcat has been around for a long time I figured that this might have been implemented at some point. Bernard Durfee -Original Message- From: Pete Guyatt [mailto:[EMAIL PROTECTED] Sent: Tuesday, April 12, 2005 3:33 PM To: Tomcat Users List Subject: RE: Garbage Collection Hi There, Tomcat does not control the garbage collection, it is up to the JVM to decide if and when a garbage collection is performed. The only way you can request a garbage collection is by using the System.gc() method, which the JVM can ignore. For more information on this Topic read the documentation for the JVM that you are using. Pete -Original Message- From: Durfee, Bernard [mailto:[EMAIL PROTECTED] Sent: 12 April 2005 20:12 To: Tomcat Users List Subject: Garbage Collection How is garbage collection controlled in Tomcat 5.5? I ran a bit of an experiment by profiling Tomcat 5.5.7 while running a web application. I ran a load test against the application that finished with the allocated object size just below the heap size. If it grew any more, garbage collection would run. So the load test was done and with Tomcat idle, the garbage collector never ran. It would seem like a good time to run the garbage collector. As is stands now the next person to hit the application will push the heap size over the limit and they will have to wait for garbage collection. Seems like Tomcat should either attempt to trigger the garbage collector when idle. Bernard Durfee - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Garbage Collection
I'd rather have a major garbage collection kick off with no users logged in vs. 100 users logged in. My application pulls data from a database and generates charts on the fly. Both of those operations require object creation. So my heap usage grows over time. My usage trends tend to be bunched, rather than constant. So in my case, more predictable garbage collection would be a great benefit. Bernard Durfee -Original Message- From: Christoph Kutzinski [mailto:[EMAIL PROTECTED] Sent: Tuesday, April 12, 2005 4:32 PM To: Tomcat Users List Subject: Re: Garbage Collection Calling System.gc() is considered to be a bad thing since this would trigger a major garbage collection which would take relatively long, compared with a minor collection. Besides this: Tomcat knows that it has nothing to do in right this moment. But does that mean that is always a good idea to make a GC now? No, maybe one millisecond later a new request will arrive and if Tomcat is then in GC, it is busy and cannot handle the request. I think this is the reason why Tomcat doesn't call the GC itself. Christoph Durfee, Bernard wrote: Right, my question was whether or not Tomcat would call System.gc() to 'suggest' to the JVM that garbage collection take place. Tomcat itself is the best authority as to how busy it is. Since Tomcat has been around for a long time I figured that this might have been implemented at some point. Bernard Durfee -Original Message- From: Pete Guyatt [mailto:[EMAIL PROTECTED] Sent: Tuesday, April 12, 2005 3:33 PM To: Tomcat Users List Subject: RE: Garbage Collection Hi There, Tomcat does not control the garbage collection, it is up to the JVM to decide if and when a garbage collection is performed. The only way you can request a garbage collection is by using the System.gc() method, which the JVM can ignore. For more information on this Topic read the documentation for the JVM that you are using. Pete -Original Message- From: Durfee, Bernard [mailto:[EMAIL PROTECTED] Sent: 12 April 2005 20:12 To: Tomcat Users List Subject: Garbage Collection How is garbage collection controlled in Tomcat 5.5? I ran a bit of an experiment by profiling Tomcat 5.5.7 while running a web application. I ran a load test against the application that finished with the allocated object size just below the heap size. If it grew any more, garbage collection would run. So the load test was done and with Tomcat idle, the garbage collector never ran. It would seem like a good time to run the garbage collector. As is stands now the next person to hit the application will push the heap size over the limit and they will have to wait for garbage collection. Seems like Tomcat should either attempt to trigger the garbage collector when idle. Bernard Durfee - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Garbage Collection
If you know that no or only few users are currently logged in, you can trigger System.gc() yourself. I think Tomcat has no reliable way to know how busy its webapps currently are. Durfee, Bernard wrote: I'd rather have a major garbage collection kick off with no users logged in vs. 100 users logged in. My application pulls data from a database and generates charts on the fly. Both of those operations require object creation. So my heap usage grows over time. My usage trends tend to be bunched, rather than constant. So in my case, more predictable garbage collection would be a great benefit. Bernard Durfee -Original Message- From: Christoph Kutzinski [mailto:[EMAIL PROTECTED] Sent: Tuesday, April 12, 2005 4:32 PM To: Tomcat Users List Subject: Re: Garbage Collection Calling System.gc() is considered to be a bad thing since this would trigger a major garbage collection which would take relatively long, compared with a minor collection. Besides this: Tomcat knows that it has nothing to do in right this moment. But does that mean that is always a good idea to make a GC now? No, maybe one millisecond later a new request will arrive and if Tomcat is then in GC, it is busy and cannot handle the request. I think this is the reason why Tomcat doesn't call the GC itself. Christoph Durfee, Bernard wrote: Right, my question was whether or not Tomcat would call System.gc() to 'suggest' to the JVM that garbage collection take place. Tomcat itself is the best authority as to how busy it is. Since Tomcat has been around for a long time I figured that this might have been implemented at some point. Bernard Durfee -Original Message- From: Pete Guyatt [mailto:[EMAIL PROTECTED] Sent: Tuesday, April 12, 2005 3:33 PM To: Tomcat Users List Subject: RE: Garbage Collection Hi There, Tomcat does not control the garbage collection, it is up to the JVM to decide if and when a garbage collection is performed. The only way you can request a garbage collection is by using the System.gc() method, which the JVM can ignore. For more information on this Topic read the documentation for the JVM that you are using. Pete -Original Message- From: Durfee, Bernard [mailto:[EMAIL PROTECTED] Sent: 12 April 2005 20:12 To: Tomcat Users List Subject: Garbage Collection How is garbage collection controlled in Tomcat 5.5? I ran a bit of an experiment by profiling Tomcat 5.5.7 while running a web application. I ran a load test against the application that finished with the allocated object size just below the heap size. If it grew any more, garbage collection would run. So the load test was done and with Tomcat idle, the garbage collector never ran. It would seem like a good time to run the garbage collector. As is stands now the next person to hit the application will push the heap size over the limit and they will have to wait for garbage collection. Seems like Tomcat should either attempt to trigger the garbage collector when idle. Bernard Durfee - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Garbage Collection
BTW: If you are worried about gc pause time: have you trid the concurrent mark sweep garbage collector? Christoph Kutzinski wrote: If you know that no or only few users are currently logged in, you can trigger System.gc() yourself. I think Tomcat has no reliable way to know how busy its webapps currently are. Durfee, Bernard wrote: I'd rather have a major garbage collection kick off with no users logged in vs. 100 users logged in. My application pulls data from a database and generates charts on the fly. Both of those operations require object creation. So my heap usage grows over time. My usage trends tend to be bunched, rather than constant. So in my case, more predictable garbage collection would be a great benefit. Bernard Durfee -Original Message- From: Christoph Kutzinski [mailto:[EMAIL PROTECTED] Sent: Tuesday, April 12, 2005 4:32 PM To: Tomcat Users List Subject: Re: Garbage Collection Calling System.gc() is considered to be a bad thing since this would trigger a major garbage collection which would take relatively long, compared with a minor collection. Besides this: Tomcat knows that it has nothing to do in right this moment. But does that mean that is always a good idea to make a GC now? No, maybe one millisecond later a new request will arrive and if Tomcat is then in GC, it is busy and cannot handle the request. I think this is the reason why Tomcat doesn't call the GC itself. Christoph Durfee, Bernard wrote: Right, my question was whether or not Tomcat would call System.gc() to 'suggest' to the JVM that garbage collection take place. Tomcat itself is the best authority as to how busy it is. Since Tomcat has been around for a long time I figured that this might have been implemented at some point. Bernard Durfee -Original Message- From: Pete Guyatt [mailto:[EMAIL PROTECTED] Sent: Tuesday, April 12, 2005 3:33 PM To: Tomcat Users List Subject: RE: Garbage Collection Hi There, Tomcat does not control the garbage collection, it is up to the JVM to decide if and when a garbage collection is performed. The only way you can request a garbage collection is by using the System.gc() method, which the JVM can ignore. For more information on this Topic read the documentation for the JVM that you are using. Pete -Original Message- From: Durfee, Bernard [mailto:[EMAIL PROTECTED] Sent: 12 April 2005 20:12 To: Tomcat Users List Subject: Garbage Collection How is garbage collection controlled in Tomcat 5.5? I ran a bit of an experiment by profiling Tomcat 5.5.7 while running a web application. I ran a load test against the application that finished with the allocated object size just below the heap size. If it grew any more, garbage collection would run. So the load test was done and with Tomcat idle, the garbage collector never ran. It would seem like a good time to run the garbage collector. As is stands now the next person to hit the application will push the heap size over the limit and they will have to wait for garbage collection. Seems like Tomcat should either attempt to trigger the garbage collector when idle. Bernard Durfee - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Garbage Collection configuration and Memory Leakage
Hi, The memory sizes are checked every day with the ps -o time,etime,pcpu,pmem,vsize,rssize command. This is a sub-optimal method for tracking memory usage for a JVM. The reason is that what you're tracking with the above command is the OS-level memory usage, which includes a lot of stuff beyond the heap and may grow or shrink somewhat independently of webapp behavior. Yoav This e-mail, including any attachments, is a confidential business communication, and may contain information that is confidential, proprietary and/or privileged. This e-mail is intended only for the individual(s) to whom it is addressed, and may not be saved, copied, printed, disclosed or used by anyone else. If you are not the(an) intended recipient, please immediately delete this e-mail from your computer system and notify the sender. Thank you. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Garbage Collection configuration and Memory Leakage
1. No there is no Garbage Collection configuration in tomcat. This is controlled by the JVM. 2. This is not possible. Garbage collection is kicked off when a pool in the JVM fills up and clears up all expired objects. For there to be a memory leak then there must be something keeping a handle on the objects. 3. No, see answer to 2. In your case it does sound like it's the 3rd party app that is causing the memory leak. You can get a java profiler and see which objects are being held on to and here's a couple of links to some garbage collection pages to help you understand it better. http://java.sun.com/developer/technicalArticles/Programming/turbo/ http://java.sun.com/docs/hotspot/gc1.4.2/ -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: 20 October 2004 07:14 To: [EMAIL PROTECTED] Subject: Garbage Collection configuration and Memory Leakage Hi, all We have deployed a third party web application in tomcat which translates HTTP requests from web clients into CORBA commands. We are seeing large increases in memory which never seems to be released. The memory sizes are checked every day with the ps -o time,etime,pcpu,pmem,vsize,rssize command. The third party suggests that the problems could be due to garbage collection configuration in tomcat and would like us first to consult with 'tomcat experts'. If you have expertise with tomcat and are reading this could you please confirm for us: 1. Is there any garbage collection configuration in tomcat? 2. If the answer to 1. is yes, is it possible that the garbage collection configuration in tomcat could be causing a large amount of memory never to be released? 3. Is it possible that the garbage collection configuration in the JVM could be causing a large amount of memory never to be released? The implementation details are Tru64 Unix, tomcat 5.0.19, SDK 1.4.1-1 (for Tru64 Unix from HP). We are aware of other memory leak issues reported in tomcat 5.0.19 and SDK 1.4.1-1 but we have been able to rule out these known problems as the cause of our memory leak. Thanks Kenny Any opinions expressed in this E-mail may be those of the individual and not necessarily the company. This E-mail and any files transmitted with it are confidential and solely for the use of the intended recipient. If you are not the intended recipient or the person responsible for delivering to the intended recipient, be advised that you have received this E-mail in error and that any use or copying is strictly prohibited. If you have received this E-mail in error please notify the beCogent postmaster at [EMAIL PROTECTED] Unless expressly stated, opinions in this email are those of the individual sender and not beCogent Ltd. You must take full responsibility for virus checking this email and any attachments. Please note that the content of this email or any of its attachments may contain data that falls within the scope of the Data Protection Acts and that you must ensure that any handling or processing of such data by you is fully compliant with the terms and provisions of the Data Protection Act 1984 and 1998. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Garbage collection of classes with static variable
On Wed, Apr 14, 2004 at 09:46:12PM +0100, Tiago Matias wrote: : As a side question, if the singleton life cycle can not be easily : controlled or known, what is the best way to perform an one-time : expensive initialization? If it's just general init activity (say, loading a config file), do a web search for ContextListener -QM -- software -- http://www.brandxdev.net tech news -- http://www.RoarNetworX.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Garbage Collection
your heap size remains stable according to the verbose GC. That in itself doesn't tell you if there is a problem or not. Is there some slowness in your jsp? you might want to d/l borland optimizeIt trial version and get a better picture of what is happening. peter Rob Wichterman [EMAIL PROTECTED] wrote: Can anybody tell me if these look like healthy garbage collections. [GC [ParNew: 3968K-0K(4032K), 0.0132890 secs] 25349K-22156K(56072K), 0.0134572 secs] [GC [ParNew: 3952K-0K(4032K), 0.0086222 secs] 26109K-22649K(56072K), 0.0087891 secs] [GC [ParNew: 3953K-0K(4032K), 0.0092634 secs] 26602K-23133K(56072K), 0.0094345 secs] [GC [ParNew: 3967K-0K(4032K), 0.0094125 secs] 27101K-23289K(56072K), 0.0095833 secs] [GC [ParNew: 3961K-0K(4032K), 0.0474236 secs] 27250K-23491K(56072K), 0.0476528 secs] [GC [ParNew: 3966K-0K(4032K), 0.0101857 secs] 27458K-23644K(56072K), 0.0103671 secs] [GC [ParNew: 3968K-0K(4032K), 0.0088548 secs] 27612K-23776K(56072K), 0.0090263 secs] [GC [ParNew: 3968K-0K(4032K), 0.0075491 secs] 27744K-23842K(56072K), 0.0077127 secs] [GC [ParNew: 3967K-0K(4032K), 0.0107583 secs] 27810K-24144K(56072K), 0.0109381 secs] [GC [ParNew: 3967K-0K(4032K), 0.0588864 secs] 28112K-24470K(56072K), 0.0591110 secs] [GC [ParNew: 3964K-0K(4032K), 0.0076312 secs] 28435K-24576K(56072K), 0.0077934 secs] [GC [ParNew: 3967K-0K(4032K), 0.0076016 secs] 28544K-24659K(56072K), 0.0077809 secs] [GC [ParNew: 3967K-0K(4032K), 0.0094214 secs] 28627K-24907K(56072K), 0.0095959 secs] [GC [ParNew: 3967K-0K(4032K), 0.0081766 secs] 28875K-25413K(56072K), 0.0083235 secs] [GC [ParNew: 3964K-0K(4032K), 0.0476766 secs] 29378K-25736K(56072K), 0.0478634 secs] [GC [ParNew: 3967K-0K(4032K), 0.0131406 secs] 29704K-26056K(56072K), 0.0133119 secs] [GC [ParNew: 3967K-0K(4032K), 0.0127321 secs] 30024K-26486K(56072K), 0.0128994 secs] [GC [ParNew: 3967K-0K(4032K), 0.0170908 secs] 30453K-27044K(56072K), 0.0172648 secs] [GC [ParNew: 3946K-0K(4032K), 0.0258431 secs] 30991K-28401K(56072K), 0.0260299 secs] [GC [ParNew: 3967K-0K(4032K), 0.0097711 secs] 32368K-29151K(56072K), 0.0099655 secs] [GC [ParNew: 3967K-0K(4032K), 0.0277493 secs] 33119K-30963K(56072K), 0.0279320 secs] [GC [ParNew: 3967K-0K(4032K), 0.0148470 secs] 34931K-31791K(56072K), 0.0150112 secs] [GC [ParNew: 3961K-0K(4032K), 0.0252186 secs] 35753K-33458K(56072K), 0.0253967 secs] [GC [ParNew: 3956K-0K(4032K), 0.0094682 secs] 37414K-34072K(56072K), 0.0096453 secs] [GC [ParNew: 3967K-0K(4032K), 0.0086307 secs] 38040K-34737K(56072K), 0.0088139 secs] [GC [ParNew: 3961K-0K(4032K), 0.0085751 secs] 38699K-35289K(56072K), 0.0087476 secs] [GC [ParNew: 3967K-0K(4032K), 0.0092369 secs] 39257K-35818K(56072K), 0.0095723 secs] [GC [1 CMS-initial-mark: 35818K(52040K)] 35818K(56072K), 0.0051687 secs] [CMS-concurrent-mark: 0.414/0.414 secs] [CMS-concurrent-preclean: 0.004/0.004 secs] [GC[Rescan (parallel) , 0.0071662 secs][weak refs processing, 0.0076101 secs] [1 CMS-remark: 35818K(52040K)] 3 5879K(56072K), 0.0157375 secs] [CMS-concurrent-sweep: 0.131/0.131 secs] [CMS-concurrent-reset: 0.124/0.124 secs] [GC [ParNew: 3967K-0K(4032K), 0.0108625 secs] 20393K-16549K(56072K), 0.0110341 secs] - Do you Yahoo!? Yahoo! Finance Tax Center - File online. File on time.
RE: Garbage Collection
The weird thing is everything will be running fine for a few hours (or days, very inconsistent) then it seems like the garbage collector cannot keep up with the used space and the heap gets bigger and bigger while nearly nothing gets cleared, when this happens I have noticed the CPU stuck around 60% used, eventually it will crash with (Out of Memory not enough Swap Space). I have used JProfiler to try and find memory issues but the odd thing is we have never been able to duplicate this problem in our testing environment only in production. -Original Message- From: Peter Lin [mailto:[EMAIL PROTECTED] Sent: Tuesday, March 30, 2004 1:08 PM To: Tomcat Users List Subject: Re: Garbage Collection your heap size remains stable according to the verbose GC. That in itself doesn't tell you if there is a problem or not. Is there some slowness in your jsp? you might want to d/l borland optimizeIt trial version and get a better picture of what is happening. peter Rob Wichterman [EMAIL PROTECTED] wrote: Can anybody tell me if these look like healthy garbage collections. [GC [ParNew: 3968K-0K(4032K), 0.0132890 secs] 25349K-22156K(56072K), 0.0134572 secs] [GC [ParNew: 3952K-0K(4032K), 0.0086222 secs] 26109K-22649K(56072K), 0.0087891 secs] [GC [ParNew: 3953K-0K(4032K), 0.0092634 secs] 26602K-23133K(56072K), 0.0094345 secs] [GC [ParNew: 3967K-0K(4032K), 0.0094125 secs] 27101K-23289K(56072K), 0.0095833 secs] [GC [ParNew: 3961K-0K(4032K), 0.0474236 secs] 27250K-23491K(56072K), 0.0476528 secs] [GC [ParNew: 3966K-0K(4032K), 0.0101857 secs] 27458K-23644K(56072K), 0.0103671 secs] [GC [ParNew: 3968K-0K(4032K), 0.0088548 secs] 27612K-23776K(56072K), 0.0090263 secs] [GC [ParNew: 3968K-0K(4032K), 0.0075491 secs] 27744K-23842K(56072K), 0.0077127 secs] [GC [ParNew: 3967K-0K(4032K), 0.0107583 secs] 27810K-24144K(56072K), 0.0109381 secs] [GC [ParNew: 3967K-0K(4032K), 0.0588864 secs] 28112K-24470K(56072K), 0.0591110 secs] [GC [ParNew: 3964K-0K(4032K), 0.0076312 secs] 28435K-24576K(56072K), 0.0077934 secs] [GC [ParNew: 3967K-0K(4032K), 0.0076016 secs] 28544K-24659K(56072K), 0.0077809 secs] [GC [ParNew: 3967K-0K(4032K), 0.0094214 secs] 28627K-24907K(56072K), 0.0095959 secs] [GC [ParNew: 3967K-0K(4032K), 0.0081766 secs] 28875K-25413K(56072K), 0.0083235 secs] [GC [ParNew: 3964K-0K(4032K), 0.0476766 secs] 29378K-25736K(56072K), 0.0478634 secs] [GC [ParNew: 3967K-0K(4032K), 0.0131406 secs] 29704K-26056K(56072K), 0.0133119 secs] [GC [ParNew: 3967K-0K(4032K), 0.0127321 secs] 30024K-26486K(56072K), 0.0128994 secs] [GC [ParNew: 3967K-0K(4032K), 0.0170908 secs] 30453K-27044K(56072K), 0.0172648 secs] [GC [ParNew: 3946K-0K(4032K), 0.0258431 secs] 30991K-28401K(56072K), 0.0260299 secs] [GC [ParNew: 3967K-0K(4032K), 0.0097711 secs] 32368K-29151K(56072K), 0.0099655 secs] [GC [ParNew: 3967K-0K(4032K), 0.0277493 secs] 33119K-30963K(56072K), 0.0279320 secs] [GC [ParNew: 3967K-0K(4032K), 0.0148470 secs] 34931K-31791K(56072K), 0.0150112 secs] [GC [ParNew: 3961K-0K(4032K), 0.0252186 secs] 35753K-33458K(56072K), 0.0253967 secs] [GC [ParNew: 3956K-0K(4032K), 0.0094682 secs] 37414K-34072K(56072K), 0.0096453 secs] [GC [ParNew: 3967K-0K(4032K), 0.0086307 secs] 38040K-34737K(56072K), 0.0088139 secs] [GC [ParNew: 3961K-0K(4032K), 0.0085751 secs] 38699K-35289K(56072K), 0.0087476 secs] [GC [ParNew: 3967K-0K(4032K), 0.0092369 secs] 39257K-35818K(56072K), 0.0095723 secs] [GC [1 CMS-initial-mark: 35818K(52040K)] 35818K(56072K), 0.0051687 secs] [CMS-concurrent-mark: 0.414/0.414 secs] [CMS-concurrent-preclean: 0.004/0.004 secs] [GC[Rescan (parallel) , 0.0071662 secs][weak refs processing, 0.0076101 secs] [1 CMS-remark: 35818K(52040K)] 3 5879K(56072K), 0.0157375 secs] [CMS-concurrent-sweep: 0.131/0.131 secs] [CMS-concurrent-reset: 0.124/0.124 secs] [GC [ParNew: 3967K-0K(4032K), 0.0108625 secs] 20393K-16549K(56072K), 0.0110341 secs] - Do you Yahoo!? Yahoo! Finance Tax Center - File online. File on time. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Garbage Collection
one trick I've used in the past might help. what I do is start tomcat with OptimizeIt. Then I throw varying loads at tomcat and see what happens. Warning though, make sure you have atleast 1gb of RAM. I don't recommend trying this with less than 768mb. In some cases, I will use the production logs to simulate the load in JMeter. JMeter now has a access log sampler, which will read common log format to generate requests. if the bug is the result of a sequence of requests, running a simulation might be the trick to expose it. My original reason for writing the access log sampler for JMeter was to simulate strange unpredictable behavior that seems difficult or impossible to reproduce consistently. peter lin Rob Wichterman [EMAIL PROTECTED] wrote: The weird thing is everything will be running fine for a few hours (or days, very inconsistent) then it seems like the garbage collector cannot keep up with the used space and the heap gets bigger and bigger while nearly nothing gets cleared, when this happens I have noticed the CPU stuck around 60% used, eventually it will crash with (Out of Memory not enough Swap Space). I have used JProfiler to try and find memory issues but the odd thing is we have never been able to duplicate this problem in our testing environment only in production. -Original Message- From: Peter Lin [mailto:[EMAIL PROTECTED] Sent: Tuesday, March 30, 2004 1:08 PM To: Tomcat Users List Subject: Re: Garbage Collection your heap size remains stable according to the verbose GC. That in itself doesn't tell you if there is a problem or not. Is there some slowness in your jsp? you might want to d/l borland optimizeIt trial version and get a better picture of what is happening. peter Rob Wichterman wrote: Can anybody tell me if these look like healthy garbage collections. [GC [ParNew: 3968K-0K(4032K), 0.0132890 secs] 25349K-22156K(56072K), 0.0134572 secs] [GC [ParNew: 3952K-0K(4032K), 0.0086222 secs] 26109K-22649K(56072K), 0.0087891 secs] [GC [ParNew: 3953K-0K(4032K), 0.0092634 secs] 26602K-23133K(56072K), 0.0094345 secs] [GC [ParNew: 3967K-0K(4032K), 0.0094125 secs] 27101K-23289K(56072K), 0.0095833 secs] [GC [ParNew: 3961K-0K(4032K), 0.0474236 secs] 27250K-23491K(56072K), 0.0476528 secs] [GC [ParNew: 3966K-0K(4032K), 0.0101857 secs] 27458K-23644K(56072K), 0.0103671 secs] [GC [ParNew: 3968K-0K(4032K), 0.0088548 secs] 27612K-23776K(56072K), 0.0090263 secs] [GC [ParNew: 3968K-0K(4032K), 0.0075491 secs] 27744K-23842K(56072K), 0.0077127 secs] [GC [ParNew: 3967K-0K(4032K), 0.0107583 secs] 27810K-24144K(56072K), 0.0109381 secs] [GC [ParNew: 3967K-0K(4032K), 0.0588864 secs] 28112K-24470K(56072K), 0.0591110 secs] [GC [ParNew: 3964K-0K(4032K), 0.0076312 secs] 28435K-24576K(56072K), 0.0077934 secs] [GC [ParNew: 3967K-0K(4032K), 0.0076016 secs] 28544K-24659K(56072K), 0.0077809 secs] [GC [ParNew: 3967K-0K(4032K), 0.0094214 secs] 28627K-24907K(56072K), 0.0095959 secs] [GC [ParNew: 3967K-0K(4032K), 0.0081766 secs] 28875K-25413K(56072K), 0.0083235 secs] [GC [ParNew: 3964K-0K(4032K), 0.0476766 secs] 29378K-25736K(56072K), 0.0478634 secs] [GC [ParNew: 3967K-0K(4032K), 0.0131406 secs] 29704K-26056K(56072K), 0.0133119 secs] [GC [ParNew: 3967K-0K(4032K), 0.0127321 secs] 30024K-26486K(56072K), 0.0128994 secs] [GC [ParNew: 3967K-0K(4032K), 0.0170908 secs] 30453K-27044K(56072K), 0.0172648 secs] [GC [ParNew: 3946K-0K(4032K), 0.0258431 secs] 30991K-28401K(56072K), 0.0260299 secs] [GC [ParNew: 3967K-0K(4032K), 0.0097711 secs] 32368K-29151K(56072K), 0.0099655 secs] [GC [ParNew: 3967K-0K(4032K), 0.0277493 secs] 33119K-30963K(56072K), 0.0279320 secs] [GC [ParNew: 3967K-0K(4032K), 0.0148470 secs] 34931K-31791K(56072K), 0.0150112 secs] [GC [ParNew: 3961K-0K(4032K), 0.0252186 secs] 35753K-33458K(56072K), 0.0253967 secs] [GC [ParNew: 3956K-0K(4032K), 0.0094682 secs] 37414K-34072K(56072K), 0.0096453 secs] [GC [ParNew: 3967K-0K(4032K), 0.0086307 secs] 38040K-34737K(56072K), 0.0088139 secs] [GC [ParNew: 3961K-0K(4032K), 0.0085751 secs] 38699K-35289K(56072K), 0.0087476 secs] [GC [ParNew: 3967K-0K(4032K), 0.0092369 secs] 39257K-35818K(56072K), 0.0095723 secs] [GC [1 CMS-initial-mark: 35818K(52040K)] 35818K(56072K), 0.0051687 secs] [CMS-concurrent-mark: 0.414/0.414 secs] [CMS-concurrent-preclean: 0.004/0.004 secs] [GC[Rescan (parallel) , 0.0071662 secs][weak refs processing, 0.0076101 secs] [1 CMS-remark: 35818K(52040K)] 3 5879K(56072K), 0.0157375 secs] [CMS-concurrent-sweep: 0.131/0.131 secs] [CMS-concurrent-reset: 0.124/0.124 secs] [GC [ParNew: 3967K-0K(4032K), 0.0108625 secs] 20393K-16549K(56072K), 0.0110341 secs] - Do you Yahoo!? Yahoo! Finance Tax Center - File online. File on time. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Do you Yahoo!? Yahoo! Finance Tax Center - File
Re: Garbage Collection
Wait a minute!! not enough swap space means IIRC that your JVM is getting *really* big. How big is your memory? What is your -Xmx setting? I would recommend keeping -Xmx to 80% of your physical RAM at a maximum (or less if your machine is not dedicated). Could you please tell us a bit more on your environment (amount of RAM, amount of available RAM at tomcat startup time, idem for swap space, memory-relevant parameters you are passing to the JVM, any third-party native libraries you might be using, and any other detail you consider important). Antonio Fiol Rob Wichterman wrote: The weird thing is everything will be running fine for a few hours (or days, very inconsistent) then it seems like the garbage collector cannot keep up with the used space and the heap gets bigger and bigger while nearly nothing gets cleared, when this happens I have noticed the CPU stuck around 60% used, eventually it will crash with (Out of Memory not enough Swap Space). I have used JProfiler to try and find memory issues but the odd thing is we have never been able to duplicate this problem in our testing environment only in production. -Original Message- From: Peter Lin [mailto:[EMAIL PROTECTED] Sent: Tuesday, March 30, 2004 1:08 PM To: Tomcat Users List Subject: Re: Garbage Collection your heap size remains stable according to the verbose GC. That in itself doesn't tell you if there is a problem or not. Is there some slowness in your jsp? you might want to d/l borland optimizeIt trial version and get a better picture of what is happening. peter Rob Wichterman [EMAIL PROTECTED] wrote: Can anybody tell me if these look like healthy garbage collections. [GC [ParNew: 3968K-0K(4032K), 0.0132890 secs] 25349K-22156K(56072K), 0.0134572 secs] [GC [ParNew: 3952K-0K(4032K), 0.0086222 secs] 26109K-22649K(56072K), 0.0087891 secs] [GC [ParNew: 3953K-0K(4032K), 0.0092634 secs] 26602K-23133K(56072K), 0.0094345 secs] [GC [ParNew: 3967K-0K(4032K), 0.0094125 secs] 27101K-23289K(56072K), 0.0095833 secs] [GC [ParNew: 3961K-0K(4032K), 0.0474236 secs] 27250K-23491K(56072K), 0.0476528 secs] [GC [ParNew: 3966K-0K(4032K), 0.0101857 secs] 27458K-23644K(56072K), 0.0103671 secs] [GC [ParNew: 3968K-0K(4032K), 0.0088548 secs] 27612K-23776K(56072K), 0.0090263 secs] [GC [ParNew: 3968K-0K(4032K), 0.0075491 secs] 27744K-23842K(56072K), 0.0077127 secs] [GC [ParNew: 3967K-0K(4032K), 0.0107583 secs] 27810K-24144K(56072K), 0.0109381 secs] [GC [ParNew: 3967K-0K(4032K), 0.0588864 secs] 28112K-24470K(56072K), 0.0591110 secs] [GC [ParNew: 3964K-0K(4032K), 0.0076312 secs] 28435K-24576K(56072K), 0.0077934 secs] [GC [ParNew: 3967K-0K(4032K), 0.0076016 secs] 28544K-24659K(56072K), 0.0077809 secs] [GC [ParNew: 3967K-0K(4032K), 0.0094214 secs] 28627K-24907K(56072K), 0.0095959 secs] [GC [ParNew: 3967K-0K(4032K), 0.0081766 secs] 28875K-25413K(56072K), 0.0083235 secs] [GC [ParNew: 3964K-0K(4032K), 0.0476766 secs] 29378K-25736K(56072K), 0.0478634 secs] [GC [ParNew: 3967K-0K(4032K), 0.0131406 secs] 29704K-26056K(56072K), 0.0133119 secs] [GC [ParNew: 3967K-0K(4032K), 0.0127321 secs] 30024K-26486K(56072K), 0.0128994 secs] [GC [ParNew: 3967K-0K(4032K), 0.0170908 secs] 30453K-27044K(56072K), 0.0172648 secs] [GC [ParNew: 3946K-0K(4032K), 0.0258431 secs] 30991K-28401K(56072K), 0.0260299 secs] [GC [ParNew: 3967K-0K(4032K), 0.0097711 secs] 32368K-29151K(56072K), 0.0099655 secs] [GC [ParNew: 3967K-0K(4032K), 0.0277493 secs] 33119K-30963K(56072K), 0.0279320 secs] [GC [ParNew: 3967K-0K(4032K), 0.0148470 secs] 34931K-31791K(56072K), 0.0150112 secs] [GC [ParNew: 3961K-0K(4032K), 0.0252186 secs] 35753K-33458K(56072K), 0.0253967 secs] [GC [ParNew: 3956K-0K(4032K), 0.0094682 secs] 37414K-34072K(56072K), 0.0096453 secs] [GC [ParNew: 3967K-0K(4032K), 0.0086307 secs] 38040K-34737K(56072K), 0.0088139 secs] [GC [ParNew: 3961K-0K(4032K), 0.0085751 secs] 38699K-35289K(56072K), 0.0087476 secs] [GC [ParNew: 3967K-0K(4032K), 0.0092369 secs] 39257K-35818K(56072K), 0.0095723 secs] [GC [1 CMS-initial-mark: 35818K(52040K)] 35818K(56072K), 0.0051687 secs] [CMS-concurrent-mark: 0.414/0.414 secs] [CMS-concurrent-preclean: 0.004/0.004 secs] [GC[Rescan (parallel) , 0.0071662 secs][weak refs processing, 0.0076101 secs] [1 CMS-remark: 35818K(52040K)] 3 5879K(56072K), 0.0157375 secs] [CMS-concurrent-sweep: 0.131/0.131 secs] [CMS-concurrent-reset: 0.124/0.124 secs] [GC [ParNew: 3967K-0K(4032K), 0.0108625 secs] 20393K-16549K(56072K), 0.0110341 secs] - Do you Yahoo!? Yahoo! Finance Tax Center - File online. File on time. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] smime.p7s Description: S/MIME Cryptographic Signature
RE: Garbage Collection issues
Howdy, Perhaps you are experiencing higher load, which requires more memory. Or perhaps your application does have a memory leak: those are possible and occur in java, so yes that would a programming error on your part. The garbage collector does much magic, but it can't save you all the time. You may wish to read up on java memory leaks, as they've been discussed at length on this list and on the net in general. Note that when you call Runtime#gc that's only a suggestion to the JVM: many times when you call that the garbage collector may not run at all. Yoav Shapira Millennium ChemInformatics -Original Message- From: Neal [mailto:[EMAIL PROTECTED] Sent: Sunday, November 30, 2003 8:21 PM To: 'Tomcat Users List' Subject: Garbage Collection issues My Tomcat 4.1 (hosted on Linux) seems to have a problem in recent months with crashing due to unavailable free RAM. Specifically I get a java.error.outOfMemory exception. If check the RAM available (Runtime.getRuntime().totalMemory()), I can see it ticking down through the week. If explicitly run garbage collection however my RAM totally frees up and all is well (Runtime.getRuntime().gc();). Why would this happen? Surely this isn't due to a programming error on my part, otherwise, the resources should automatically released whenever the JRE performs periodic garbage collection. Isn't that correct? Anyone have any theories as to what this may mean and what the best solution would be? Thanks. Neal - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] This e-mail, including any attachments, is a confidential business communication, and may contain information that is confidential, proprietary and/or privileged. This e-mail is intended only for the individual(s) to whom it is addressed, and may not be saved, copied, printed, disclosed or used by anyone else. If you are not the(an) intended recipient, please immediately delete this e-mail from your computer system and notify the sender. Thank you. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Garbage Collection issues
When I said that surely it can't be a memory leak in my app I was operating under the assumption that the JRE runs garbage collection periodically anywayis this not true? If I was waisting resources and not releasing them in a way that the GC could take them back when it runs automatically then why would it take them back when I call garbage collection explicitly? To me, this suggested more of a systemic issue. It was suggested by someone last night that I may want to look at some config lines to make sure GC is active and this seemed in line with my assumption. Is there something else here that I may be missing however? Can you see a possible explanation as to why my app's waisted resources would not get cleaned up until I explicitly ran GC? Thanks. Neal Shapira, Yoav [EMAIL PROTECTED] wrote: Howdy, Perhaps you are experiencing higher load, which requires more memory. Or perhaps your application does have a memory leak: those are possible and occur in java, so yes that would a programming error on your part. The garbage collector does much magic, but it can't save you all the time. You may wish to read up on java memory leaks, as they've been discussed at length on this list and on the net in general. Note that when you call Runtime#gc that's only a suggestion to the JVM: many times when you call that the garbage collector may not run at all. Yoav Shapira Millennium ChemInformatics -Original Message- From: Neal [mailto:[EMAIL PROTECTED] Sent: Sunday, November 30, 2003 8:21 PM To: 'Tomcat Users List' Subject: Garbage Collection issues My Tomcat 4.1 (hosted on Linux) seems to have a problem in recent months with crashing due to unavailable free RAM. Specifically I get a java.error.outOfMemory exception. If check the RAM available (Runtime.getRuntime().totalMemory()), I can see it ticking down through the week. If explicitly run garbage collection however my RAM totally frees up and all is well (Runtime.getRuntime().gc();). Why would this happen? Surely this isn't due to a programming error on my part, otherwise, the resources should automatically released whenever the JRE performs periodic garbage collection. Isn't that correct? Anyone have any theories as to what this may mean and what the best solution would be? Thanks. Neal - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] This e-mail, including any attachments, is a confidential business communication, and may contain information that is confidential, proprietary and/or privileged. This e-mail is intended only for the individual(s) to whom it is addressed, and may not be saved, copied, printed, disclosed or used by anyone else. If you are not the(an) intended recipient, please immediately delete this e-mail from your computer system and notify the sender. Thank you. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Do you Yahoo!? Free Pop-Up Blocker - Get it now
Re: Garbage Collection issues
Neal, When I said that surely it can't be a memory leak in my app I was operating under the assumption that the JRE runs garbage collection periodically anywayis this not true? The GC is pretty much free to run whenever it wants. Often, it will not run until you get very close to running out of memory. Actually, most modern GCs run all the time, but do very little work. They free-up short-leved objects and only re-claim a very small amount of memory. After some longer-lived (and dead) objects accumulate on the heap, then the GC does a full GC and the heap goes *way* down (this is likely to be what you see when you force a GC). If I was waisting resources and not releasing them in a way that the GC could take them back when it runs automatically then why would it take them back when I call garbage collection explicitly? Did this forced GC helps situation happen in a dev environment or in production? To me, this suggested more of a systemic issue. It was suggested by someone last night that I may want to look at some config lines to make sure GC is active and this seemed in line with my assumption. Is there something else here that I may be missing however? Can you see a possible explanation as to why my app's wasted resources would not get cleaned up until I explicitly ran GC? As I said, sometimes the GC takes it's sweet time. What, if any, memory settings do you use, and do you use any GC specific settings? For debugging purposes, it's often helpful to enable verbose GC -- check your VM's command-line options for how to enable that. Many production deployments set both the min and max heap sizes to the same power-of-two setting (i.e. 128M, 256M, 1024M, etc.) -chris - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Garbage Collection
It's not tomcat that runs the gc but the jvm. To find out more about when the garbage collection happens, you have to set the verbosegc option of the vm: http://docs.sun.com/db/doc/806-1367/6jalj6mv7?a=view http://www-106.ibm.com/developerworks/java/library/i-garbage3/ To tune the gc you can adjust the values for the gc in the vm: http://java.sun.com/docs/hotspot/gc/ http://developer.java.sun.com/developer/technicalArticles/Programming/turbo/ http://www-106.ibm.com/developerworks/java/library/i-garbage1/?dwzone=java -Original Message- From: Hari Venkatesan [mailto:[EMAIL PROTECTED]] Sent: Monday, January 13, 2003 10:40 PM To: [EMAIL PROTECTED] Subject: Garbage Collection Is there a way to find out how often tomcat runs Garbage Collection and how to optimize it if GC does not happen often Hari -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Garbage Collection in Java: Am I an idiot?
Howdy, Very few things are guaranteed regarding garbage collection when you consider your system as a whole. The container can almost always cache things like JSPs, servlets, and sessions until it feels like releasing them. Some of these parameters you can control via configuration, e.g. session expiration. System.gc() is a suggestion. It doesn't guarantee garbage collection will run. In fact, JDK 1.4 and later can be told to ignore calls to System.gc via a runtime option, so your server admin may set this option, at which point you could rely on System.gc() even as a suggestion to the VM. Have your tried adding -verbose:gc to your runtime options? That will let you know when garbage collection is running and how much memory it collected at each run. Have your tried using another garbage collector, e.g. the incremental (-Xincgc) or concurrent mark-sweep (-XX:+UseConcMarkSweepGC (available beginning with J2SE 1.4.1) ? Yoav Shapira Millennium ChemInformatics -Original Message- From: Michael Nicholson [mailto:[EMAIL PROTECTED]] Sent: Thursday, August 29, 2002 9:08 AM To: Tomcat Users List Subject: OT: Garbage Collection in Java: Am I an idiot? The answer to the (completely rhetorical) question is probably yest, but I've got another question, too. So, I have this moderately large application with jsps, servlets, and an Oracle DB. It does its thing ok, but it never releases memory. There are certainly session variables (probably way too many, but that's (hopefully) a question for another day), but even after the session expires, I'm still using the same amount of memory. I even included a direct call to System.gc() on my first page, hoping to collect the memory from the three day old sessions, but no luck. So, my thoughts/questions: Some connections are still opened (this is what's running on my development server right now: however, the actual development is done in Sun ONE on my desktop, so I'm going through and making sure all of those are closed there... but I'm also trying to debug this memory issue), so maybe these open connections force some of the session scoped beans to persist? Forever? Or am I just missing something completely about garbage collection? So, in short, if I have a session scoped bean that has in it something like a connection or a recordset (which is most likely not a good idea... I now know that), even after the session times out, would that bean continue to exist? And eat up my memory? Sorry for the rambling. Michael Nicholson, Carolina Center for Public Service This e-mail, including any attachments, is a confidential business communication, and may contain information that is confidential, proprietary and/or privileged. This e-mail is intended only for the individual(s) to whom it is addressed, and may not be saved, copied, printed, disclosed or used by anyone else. If you are not the(an) intended recipient, please immediately delete this e-mail from your computer system and notify the sender. Thank you. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Garbage Collection in Java: Am I an idiot?
Hi, I believe that you are configusing the process memory consumed by the java application, with that used by the java image Running system.gc does not return memory to the operating system, is garbage collects the memory that it has allocated. This means that there may be some unused holes in the memory space. Whether the memory is compacted and returned to the OS is down to the VM, and I have not seen that occur. The amount is free memory can be seen from Runtime.getRuntime().freeMemory() You should ensure that the memory restrictions that you give the java VM are ones that you can live with! I presume that you did not actually mean that you had java.sql.Connection objects lying around in your session. If you want to track the objects lying around in your sessions, and some (very rough) guesses as to what memory is being consumed, you could attach a session listener and periodically serialise the session data (that is the rough and approximate bit) and look at the size of the data that was serialised Mike -Original Message- From: Shapira, Yoav [mailto:[EMAIL PROTECTED]] Sent: Thursday 29 August 2002 14:22 To: Tomcat Users List Subject: RE: Garbage Collection in Java: Am I an idiot? Howdy, Very few things are guaranteed regarding garbage collection when you consider your system as a whole. The container can almost always cache things like JSPs, servlets, and sessions until it feels like releasing them. Some of these parameters you can control via configuration, e.g. session expiration. System.gc() is a suggestion. It doesn't guarantee garbage collection will run. In fact, JDK 1.4 and later can be told to ignore calls to System.gc via a runtime option, so your server admin may set this option, at which point you could rely on System.gc() even as a suggestion to the VM. Have your tried adding -verbose:gc to your runtime options? That will let you know when garbage collection is running and how much memory it collected at each run. Have your tried using another garbage collector, e.g. the incremental (-Xincgc) or concurrent mark-sweep (-XX:+UseConcMarkSweepGC (available beginning with J2SE 1.4.1) ? Yoav Shapira Millennium ChemInformatics -Original Message- From: Michael Nicholson [mailto:[EMAIL PROTECTED]] Sent: Thursday, August 29, 2002 9:08 AM To: Tomcat Users List Subject: OT: Garbage Collection in Java: Am I an idiot? The answer to the (completely rhetorical) question is probably yest, but I've got another question, too. So, I have this moderately large application with jsps, servlets, and an Oracle DB. It does its thing ok, but it never releases memory. There are certainly session variables (probably way too many, but that's (hopefully) a question for another day), but even after the session expires, I'm still using the same amount of memory. I even included a direct call to System.gc() on my first page, hoping to collect the memory from the three day old sessions, but no luck. So, my thoughts/questions: Some connections are still opened (this is what's running on my development server right now: however, the actual development is done in Sun ONE on my desktop, so I'm going through and making sure all of those are closed there... but I'm also trying to debug this memory issue), so maybe these open connections force some of the session scoped beans to persist? Forever? Or am I just missing something completely about garbage collection? So, in short, if I have a session scoped bean that has in it something like a connection or a recordset (which is most likely not a good idea... I now know that), even after the session times out, would that bean continue to exist? And eat up my memory? Sorry for the rambling. Michael Nicholson, Carolina Center for Public Service -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
