Re: memory usage
On Fri, Mar 18, 2005 at 07:43:41PM +0100, t.n.a. wrote: : rough measurements). The memory usage seems to grow up to a 100 MB : (Cayenne accesses a single table of about fifty attributes and a 1000 : rows - don't ask) and sometimes - I can't reproduce the problem now - : the app brakes when trying to open a new page. The exception says : something about not having enough memory. : Ring any bells, anyone? Yes -- if a Java app is out of memory, 1/ invest in a profiler to see whether there's a resource leak 2/ increase the heap such that the JVM has more space in which to create objects btw, please post a *new* message when writing to the list. Replying to an old (unrelated) message confuses thread-aware mailers, which makes your question harder to find (and thus answer). -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: Memory Usage - Tomcat 5.0.25
Nandish Rudra wrote: Hello Everyone, I am writing about this error from yesterday. I used JProfiler to monitor my memory usage. And am now sure that each and every static object is trashed when the application is undeployed and the profiler shows that memory is free and all instance of the objects are GC'd. This works on a Windows 2000 setup of Tomcat 5.0.25 with Java 2 SDK version 1.4.2_04 and Ant 1.6.1, but fails miserably on GNU Linux 2.4.20-8 setup. this happens with both tomcat 5.0.25 and 5.0.27 Any ideas why something like this could be happening. Nandish Rudra ECI Conference call Service LLC. -Original Message- From: Shapira, Yoav [mailto:[EMAIL PROTECTED] Sent: Monday, August 09, 2004 1:35 PM To: Tomcat Users List Subject: RE: Memory Usage - Tomcat 5.0.25 Hi, I have a couple of ideas. One is that your webapp maintain static or shared references to objects that prevent them from being garbage collected, and therefore memory from returning to the heap. Another is that a webapp undeploy is not guaranteed to reclaim all memory used by the webapp anyways so to count on this behavior is not smart. It is expected that every time you reload your webapp the overall memory usage of the server will go up a bit, as not all objects are gone (for example, if you have a static reference than the old classloader and anything that references it strongly will remain in memory). Yoav Shapira Millennium Research Informatics -Original Message- From: Nandish Rudra [mailto:[EMAIL PROTECTED] Sent: Monday, August 09, 2004 1:17 PM To: Tomcat Users List (E-mail) Subject: Memory Usage - Tomcat 5.0.25 Hello, I am having some memory issues while deploing/undeploying web applications to Tomcat. I am using Tomcat 5.0.25 with Java 2 SDK version 1.4.2_04 and Ant 1.6.1 on GNU Linux 2.4.20-8. I use ant to compile my web application and Tomcat's catalina-ant.jar to deploy it automatically. Here is my problem. When I undeploy/remove an application, Tomcat does not reclaim the memory being used by the web application and when the application is re-deployed/re-installed a significant increase in memory is seen. This increase is obviously the memory usage by the new instance of the web application. Does anyone have any idea as to why this is happening? Try looking at jvmstat (http://developers.sun.com/dev/coolstuff/jvmstat/) My own tests with show that its the permanent space of objects that gets filled up and not reclaimed after each reload. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Memory Usage - Tomcat 5.0.25
Hi, LONG-snip / Does anyone have any idea as to why this is happening? Try looking at jvmstat (http://developers.sun.com/dev/coolstuff/jvmstat/) My own tests with show that its the permanent space of objects that gets filled up and not reclaimed after each reload. Yup, that's as expected. Yoav Shapira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Memory Usage - Tomcat 5.0.25
Hi, I have a couple of ideas. One is that your webapp maintain static or shared references to objects that prevent them from being garbage collected, and therefore memory from returning to the heap. Another is that a webapp undeploy is not guaranteed to reclaim all memory used by the webapp anyways so to count on this behavior is not smart. It is expected that every time you reload your webapp the overall memory usage of the server will go up a bit, as not all objects are gone (for example, if you have a static reference than the old classloader and anything that references it strongly will remain in memory). Yoav Shapira Millennium Research Informatics -Original Message- From: Nandish Rudra [mailto:[EMAIL PROTECTED] Sent: Monday, August 09, 2004 1:17 PM To: Tomcat Users List (E-mail) Subject: Memory Usage - Tomcat 5.0.25 Hello, I am having some memory issues while deploing/undeploying web applications to Tomcat. I am using Tomcat 5.0.25 with Java 2 SDK version 1.4.2_04 and Ant 1.6.1 on GNU Linux 2.4.20-8. I use ant to compile my web application and Tomcat's catalina-ant.jar to deploy it automatically. Here is my problem. When I undeploy/remove an application, Tomcat does not reclaim the memory being used by the web application and when the application is re-deployed/re-installed a significant increase in memory is seen. This increase is obviously the memory usage by the new instance of the web application. Does anyone have any idea as to why this is happening? Regards, NR - 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: Memory Usage - Tomcat 5.0.25
Hello Yaov, You are correct I do have a few static varibles that point to running threads and some other objects. When the application is shutdown I ensure that each thread is destroyed and all static varibales are set to null, including thread identifiers, this should let my call to GC clear the memory. You are also right in saying that i should not depend on undeploy to reclaim all memory that the webapp was using, and I don't. Like I mentioned I do make sure all static variables get set to null before the application shuts down. It would be understandable if not all memory utilized by the webapp is reclaimed, but in my case absolutely no memory is being reclaimed. For example, say, i start tomcat and it starts with 30M initial memory usage without the application. Now when i deploy the application the size jumps by 8M to 38M. As the app is undeploy and re-deploy the memory usage jumps from 38M to 46-47M. Now this, if I am not wrong, is not how things should be. I would appreciate anymore suggestion that you or anyone may have. Regards, Nandish -Original Message- From: Shapira, Yoav [mailto:[EMAIL PROTECTED] Sent: Monday, August 09, 2004 1:35 PM To: Tomcat Users List Subject: RE: Memory Usage - Tomcat 5.0.25 Hi, I have a couple of ideas. One is that your webapp maintain static or shared references to objects that prevent them from being garbage collected, and therefore memory from returning to the heap. Another is that a webapp undeploy is not guaranteed to reclaim all memory used by the webapp anyways so to count on this behavior is not smart. It is expected that every time you reload your webapp the overall memory usage of the server will go up a bit, as not all objects are gone (for example, if you have a static reference than the old classloader and anything that references it strongly will remain in memory). Yoav Shapira Millennium Research Informatics -Original Message- From: Nandish Rudra [mailto:[EMAIL PROTECTED] Sent: Monday, August 09, 2004 1:17 PM To: Tomcat Users List (E-mail) Subject: Memory Usage - Tomcat 5.0.25 Hello, I am having some memory issues while deploing/undeploying web applications to Tomcat. I am using Tomcat 5.0.25 with Java 2 SDK version 1.4.2_04 and Ant 1.6.1 on GNU Linux 2.4.20-8. I use ant to compile my web application and Tomcat's catalina-ant.jar to deploy it automatically. Here is my problem. When I undeploy/remove an application, Tomcat does not reclaim the memory being used by the web application and when the application is re-deployed/re-installed a significant increase in memory is seen. This increase is obviously the memory usage by the new instance of the web application. Does anyone have any idea as to why this is happening? Regards, NR - 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Memory Usage
Hi, We've setup Tomcat to use a max of 256Mb. I've been tracking memory usage using: System.runFinalization(); System.gc(); Be aware that the above two lines are misleading, as they are suggestions and not guaranteed to actually do anything. What I've noticed is that the the 'T' value (Total Memory) slowly increases, but never goes back down. According to the Runtime javadoc, this is the total amount of memory in the JVM. Will this continue to increase? What happens when it hits the Maximum memory amount? Should I be concerned about this? It will continue to increase as needed until and unless it hits a specified boundary, e.g. the amount you specify in -Xmx plus system memory overhead (e.g. the stack and symbol table). If all available memory is allocated and more memory is requested, you will get a java.lang.OutOfMemoryError. Should you be concerned about this? Of course ;) You should always know how much memory your system requires to handle its expected loads, and you should configure your system according to this knowledge. For example, why did you pick 256MB maximum? Yoav Shapira 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: Memory Usage
If System.runFinalization() and System.gc() are misleading... what should I use instead, to force to garbage collection? So, the amount of memory the JVM uses, will always increase? How do I get it to decrease? 256 was an arbitrary choice. Is there some formula I should be using (based on projected traffic)? bort Shapira, Yoav [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] Hi, We've setup Tomcat to use a max of 256Mb. I've been tracking memory usage using: System.runFinalization(); System.gc(); Be aware that the above two lines are misleading, as they are suggestions and not guaranteed to actually do anything. What I've noticed is that the the 'T' value (Total Memory) slowly increases, but never goes back down. According to the Runtime javadoc, this is the total amount of memory in the JVM. Will this continue to increase? What happens when it hits the Maximum memory amount? Should I be concerned about this? It will continue to increase as needed until and unless it hits a specified boundary, e.g. the amount you specify in -Xmx plus system memory overhead (e.g. the stack and symbol table). If all available memory is allocated and more memory is requested, you will get a java.lang.OutOfMemoryError. Should you be concerned about this? Of course ;) You should always know how much memory your system requires to handle its expected loads, and you should configure your system according to this knowledge. For example, why did you pick 256MB maximum? Yoav Shapira 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: Memory Usage
Hi, Now you're starting to ask the right questions. If System.runFinalization() and System.gc() are misleading... what should I use instead, to force to garbage collection? You can't force garbage collection, and it is terrible design to rely on particular garbage collection timing. Instead, know that the JVM is pretty damn good at doing GC, and take throughout your code to not keep any unneeded references and limit the scope of references as much as possible. So, the amount of memory the JVM uses, will always increase? How do I get it to decrease? The amount of memory the JVM uses will monotonically increase up to the heap limit you set for it via -Xmx plus overhead space e.g. the stack and symbol tables. You can't get it to decrease. You will find this page helpful, I believe: http://jakarta.apache.org/tomcat/faq/memory.html 256 was an arbitrary choice. Is there some formula I should be using (based on projected traffic)? There's no formula in mathematical terms, but there IS a standard procedure to follow: 1. Establish the maximum expected number of concurrent users your system should handle, and the average page response time when handling this number of users. 2. Write a stress test plan using your favorite tool, e.g. JMeter, to simulate the load determined in #1. 3. Run the tool against your system without any tuning options. If you run out of memory, increase available memory (-Xmx) and repeat. If you run out of memory but you're fairly sure your system has enough, consider running with a profiler to see if there are leaks or other unnecessary memory usage patterns. Yoav Shapira 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: Memory Usage
bort wrote: If System.runFinalization() and System.gc() are misleading... what should I use instead, to force to garbage collection? So, the amount of memory the JVM uses, will always increase? How do I get it to decrease? You can't get it to decrease, but if you have the memory large enough so that it doesn't have to request any more from the system, it won't continue to grow. If it is growing without bounds you probably have a memory leak. JDK1.5.0beta seems to have an improved garbage collection tuning built in, and that may be of some help, but if you have a leak then all you can do it find it. You may want to learn more about garbage collection. You could use these references: http://java.sun.com/docs/hotspot/gc1.4.2/faq.html http://www-106.ibm.com/developerworks/java/library/j-jtp11253/ http://java.sun.com/docs/hotspot/gc1.4.2/ 256 was an arbitrary choice. Is there some formula I should be using (based on projected traffic)? The links above, esp the third one, should help you to determine what is a good size. -- Love is mutual self-giving that ends in self-recovery. Fulton Sheen James Black[EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Memory Usage
Hi, JDK1.5.0beta seems to have an improved garbage collection tuning built Care to elaborate or provide a reference? Thanks, Yoav Shapira Millennium Research Informatics 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: Memory Usage
Shapira, Yoav wrote: Hi, JDK1.5.0beta seems to have an improved garbage collection tuning built Care to elaborate or provide a reference? Thanks, http://java.sun.com/j2se/1.5.0/docs/relnotes/features.html#vm_selftune Based on my own experience, doing various performance related tests with Tomcat 5, running under JDK1.5 I find it interesting to watch the size of the java application decrease, over time. I don't set anything for the heap except -mx512M, so I can see how it performs. When I run my unit tests inside of JProfiler I also can watch the total heap decrease, while the unit test is running. -- Love is mutual self-giving that ends in self-recovery. Fulton Sheen James Black[EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Memory Usage
Hi, Great, exactly what I wanted. Thanks, Yoav Shapira Millennium Research Informatics -Original Message- From: James Black [mailto:[EMAIL PROTECTED] Sent: Monday, March 15, 2004 2:21 PM To: Tomcat Users List Subject: Re: Memory Usage Shapira, Yoav wrote: Hi, JDK1.5.0beta seems to have an improved garbage collection tuning built Care to elaborate or provide a reference? Thanks, http://java.sun.com/j2se/1.5.0/docs/relnotes/features.html#vm_selftune Based on my own experience, doing various performance related tests with Tomcat 5, running under JDK1.5 I find it interesting to watch the size of the java application decrease, over time. I don't set anything for the heap except -mx512M, so I can see how it performs. When I run my unit tests inside of JProfiler I also can watch the total heap decrease, while the unit test is running. -- Love is mutual self-giving that ends in self-recovery. Fulton Sheen James Black[EMAIL PROTECTED] - 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: Memory Usage
Thank you for the information! James Black [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] bort wrote: If System.runFinalization() and System.gc() are misleading... what should I use instead, to force to garbage collection? So, the amount of memory the JVM uses, will always increase? How do I get it to decrease? You can't get it to decrease, but if you have the memory large enough so that it doesn't have to request any more from the system, it won't continue to grow. If it is growing without bounds you probably have a memory leak. JDK1.5.0beta seems to have an improved garbage collection tuning built in, and that may be of some help, but if you have a leak then all you can do it find it. You may want to learn more about garbage collection. You could use these references: http://java.sun.com/docs/hotspot/gc1.4.2/faq.html http://www-106.ibm.com/developerworks/java/library/j-jtp11253/ http://java.sun.com/docs/hotspot/gc1.4.2/ 256 was an arbitrary choice. Is there some formula I should be using (based on projected traffic)? The links above, esp the third one, should help you to determine what is a good size. -- Love is mutual self-giving that ends in self-recovery. Fulton Sheen James Black[EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Memory Usage
Thanks for the information! Shapira, Yoav [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] Hi, Now you're starting to ask the right questions. If System.runFinalization() and System.gc() are misleading... what should I use instead, to force to garbage collection? You can't force garbage collection, and it is terrible design to rely on particular garbage collection timing. Instead, know that the JVM is pretty damn good at doing GC, and take throughout your code to not keep any unneeded references and limit the scope of references as much as possible. So, the amount of memory the JVM uses, will always increase? How do I get it to decrease? The amount of memory the JVM uses will monotonically increase up to the heap limit you set for it via -Xmx plus overhead space e.g. the stack and symbol tables. You can't get it to decrease. You will find this page helpful, I believe: http://jakarta.apache.org/tomcat/faq/memory.html 256 was an arbitrary choice. Is there some formula I should be using (based on projected traffic)? There's no formula in mathematical terms, but there IS a standard procedure to follow: 1. Establish the maximum expected number of concurrent users your system should handle, and the average page response time when handling this number of users. 2. Write a stress test plan using your favorite tool, e.g. JMeter, to simulate the load determined in #1. 3. Run the tool against your system without any tuning options. If you run out of memory, increase available memory (-Xmx) and repeat. If you run out of memory but you're fairly sure your system has enough, consider running with a profiler to see if there are leaks or other unnecessary memory usage patterns. Yoav Shapira 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: Memory Usage/Common Lib
Hi, Scenario 1: Each application is deployed with the three jars under their respective WEB-INF/lib directories. Scenario 2: Nothing is placed in the respective WEB-INF/lib directories. Rather the three jars are placed in tomcat's common/lib directory. Would the memory usage of tomcat differ in the two cases? I'm assuming yes, since in the first case the classes need to be loaded three times more. In the second scenario, the classes from the jars would only be loaded up once. Therefore Scenario 1, in terms of memory allocated to the classloaded would be 3x more? I would like to get some feedback to confirm or deny this. You're just about right. The memory allocated to the classloaders would be 3x more, as they must be separate and can have no overlap. However, in most real-life scenarios the independence and portability obtained by the WEB-INF/lib setup is far more valuable than the minor memory cost. I say minor even though it's 3x because it's 3x only for classes loaded, not the heap, which usually dwarfs the classloader memory by orders of magnitude. Yoav Shapira 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: Memory Usage/Common Lib
Scenario 1 will use more memory than scenarion 2. The ratio depends on the internal architecture of the classes. (What kind of object they create, where they store it) If you just look at the core size that is needed to load the classes it roughly directly proportional to the number of webapp in scenario 2. But apart from that most classes need additional memory. (If the libray store all object in the session, the storage for this would change for both variants. If they store it in the classes it will make a difference) -Original Message- From: Lipov, Felix [mailto:[EMAIL PROTECTED] Sent: Wednesday, March 10, 2004 2:55 PM To: Tomcat Users List Subject: Memory Usage/Common Lib I have application a, b, c. Each application uses x.jar, y.jar and z.jar. Scenario 1: Each application is deployed with the three jars under their respective WEB-INF/lib directories. Scenario 2: Nothing is placed in the respective WEB-INF/lib directories. Rather the three jars are placed in tomcat's common/lib directory. Would the memory usage of tomcat differ in the two cases? I'm assuming yes, since in the first case the classes need to be loaded three times more. In the second scenario, the classes from the jars would only be loaded up once. Therefore Scenario 1, in terms of memory allocated to the classloaded would be 3x more? I would like to get some feedback to confirm or deny this. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Memory usage raises when reloading a context
Howdy, It's normal: the classloader and associated objects can't get recycled and classes are stored in the permanent area. You can tweak the JVM's MaxPermSize if you'd like. As you noted, restarting your context all the time is not a typical production scenario. Yoav Shapira Millennium ChemInformatics -Original Message- From: Vitor Buitoni [mailto:[EMAIL PROTECTED] Sent: Wednesday, February 04, 2004 6:58 AM To: Tomcat Users List Subject: Memory usage raises when reloading a context Every time that i reload a context (through the tomcat manager) the memory usage of the tomcat grows up a bit, and it doesn't go down again. Every time the context is reloaded the memory usage raises, until the jvm begins to throw OutOfMemory errors. Then i have to restart tomcat (of course). Although this isn't a big problem in a production environment, where the applications keep running without reloads, here in our development environment this is becoming a problem, since every time we make a modification we have to reload the application. I downloaded jvmstat to monitor the jvm, and i noticed that when an application is reloaded, the overall heap usage increases and the jvm gc moves a lot of objects to the heap's permanent area. I think that this might be the main problem. Because even if the old area increases, it will sometime get garbage collected and the memory freed. And this i could confirm using jvmstat. But the objects that are in the permanent area will never be garbage collected. Is this behaviour normal? Or maybe it's a problem with my specific configuration? I'm using tomcat 5.0.16, sun jvm 1.4.2_03-b02, redhat 9. Thanks! Vitor - 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: Memory Usage, Leakage and java.lang.OutofMemory
Howdy, Once you get an OutOfMemoryError, your JVM is in an unpredictable state and must be restarted. This is not specific to tomcat. Reloading the webapp will not do any good. Find the leak with a profiler and fix it ;) Yoav Shapira Millennium ChemInformatics -Original Message- From: Mike Curwen [mailto:[EMAIL PROTECTED] Sent: Wednesday, September 17, 2003 11:17 AM To: [EMAIL PROTECTED] Subject: Memory Usage, Leakage and java.lang.OutofMemory So let's say that I have a web app that is slowly but surely leaking. Eventually, I will get a java.lang.OutOfMemory error. With how Tomcat is internally architected, or with how the JVM operates, does this cause a problem for all other applications running under Tomcat? Is there now no more memory for *anything* running under Tomcat (and let's not forget Tomcat itself)? Or if I just 'reload' the problem webapp, will that 'release' all the memory that is currently being hogged by this app? --- Mike Curwen204-885-7733 Intermediate Programmer www.gb-im.com --- ___ __ __ / ___| | __ ) |_ _| | \/ | | | _ | _ \ _ | | | |\/| | | |_| | | |_) | |_| | | | | | | \| |/ |___| |_| |_| - 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: Memory Usage, Leakage and java.lang.OutofMemory
Reloading the webapp may help. AFAIK it reloads all classes that are bound to the webapp classsloader and thus may free some memory that is hold by those classes. (Not that I think that it's a good idea to rely on that) -Original Message- From: Shapira, Yoav [mailto:[EMAIL PROTECTED] Sent: Wednesday, September 17, 2003 5:18 PM To: Tomcat Users List Subject: RE: Memory Usage, Leakage and java.lang.OutofMemory Once you get an OutOfMemoryError, your JVM is in an unpredictable state and must be restarted. This is not specific to tomcat. Reloading the webapp will not do any good. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Memory usage Tomcat 4.1.24
The recently installed Tomcat 4.1.24 on startup takes about 60M of memory. Is it my configuration. I have not noticed previous versions consuming so much. I have 6 or so applications in webapps - mainly struts - documentaion, examples etc. Using j2sdk1.4.0. Regards - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Memory usage
Checkout jvmstat on http://developers.sun.com/techtopics/emergingtech/ -Original Message- From: Luc Foisy [mailto:[EMAIL PROTECTED] Sent: Thursday, July 10, 2003 3:19 PM To: Tomcat User List (E-mail) Subject: Memory usage Is there a quick and easy way to figure out the actual memory use of everything related to the tomcat server? - 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: Memory usage
Hi, You could turn on verbose garbage collection and it will give you detailed info on the gc'ing. It will show you how much memory it is using... like a kinda before the collection and after the collection reading. This isn't something you want to run in production (for a long time at least). add -verbosegc to your JAVA_OPTS -e On Thu, 10 Jul 2003, Luc Foisy wrote: Is there a quick and easy way to figure out the actual memory use of everything related to the tomcat server? - 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: Memory usage
I use 'ps' to figure it out (are you using linux?) I do something like: ps aux | grep tomcat i grep tomcat because that is the user my tomcat runs as... you could also use 'top' __ Do you Yahoo!? SBC Yahoo! DSL - Now only $29.95 per month! http://sbc.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Memory Usage and Garbage Collection
Hi Steve, The real decision you need to make is how common are the common parts of your JSPs, and how much content is within the JSPs. If most of your JSPs are simply blocks of content surrounded by the same boiler plate JSP code, then perhaps it is worth while to make those JSPs a single JSP that then loads the different content at runtime based upon the request. But the real consideration is simply the amount of content that you're delivering within the JSPs. Consider this: If you have 500 JSP's that each have 20K of text (which is quite a bit of text if you think about it), then that's only 20MB of memory for the content. The calculation is 500 files x 20,000 characters x 2 for unicode (unicode characters, which Java uses, are 2 bytes). So, using brute force, back-of-napkin calculations, 512MB of memory would store 25000 of those documents. Also, if your document count is mostly static from day to day, i.e. you aren't adding large numbers of new documents each day, then you can easily pre-compute your overall memory burden simply for the documents, and scale appropriately. So, I doubt the JSPs alone are causing your memory problems, it's probably something else. Hope this was helpful, Regards, Will Hartung ([EMAIL PROTECTED]) - Original Message - From: Turoff, Steve [EMAIL PROTECTED] To: Will Hartung [EMAIL PROTECTED] Sent: Tuesday, January 14, 2003 10:07 AM Subject: RE: Memory Usage and Garbage Collection Will, I too am experiencing memory problems and I think your explanation below might apply to me. I'm using Tomcat 4.1 on RedHat Linux. Over the course of a few days, I notice, (using top) that the amount of physical memory used by the java processes continually increases until it exceeds the maximum that I've set (-Xmx512m) and then will generate an java.lang.OutOfMemoryError in $CATALINA_HOME/logs/localhost_log.-MM-DD.txt. I believe the problem is that my JSPs are dynamic, but I'm not sure exactly what differentiates a static JSP from a dynamic JSP. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Memory Usage and Garbage Collection
Will, I too am experiencing memory problems and I think your explanation below might apply to me. I'm using Tomcat 4.1 on RedHat Linux. Over the course of a few days, I notice, (using top) that the amount of physical memory used by the java processes continually increases until it hits the maximum that I've set (-Xmx512m) and then will generate an outOfMemory error. I believe the problem is that my JSPs are dynamic, but I'm not sure exactly what differentiates a static JSP from a dynamic JSP. I have several hundred JSPs - each one looks like: !-- BEGIN SAMPLE PAGE -- jsp:useBean id=thisPage class=PHN.PHNPage scope=session / jsp:setProperty name=thisPage property=section value=foo / %@ include file=/templates/header.jsp % I am body content. Some pages use the following java: a href=/a.pdfDocument a/a (PDF file - %= new File(/a.pdf).length()/1024 % %@ include file=/templates/footer.jsp % !-- END SAMPLE PAGE -- header.jsp looks something like this: !-- BEGIN HEADER.JSP -- % String host = http://; + request.getServerName(); String requestURI = request.getRequestURI(); String pageType = request.getParameter(pageType); String section = thisPage.getSection(); % A bunch of HTML % if (section.equals(foo)) { % %@ include file=/nav/foo.jsp % % } % !-- END HEADER.JSP -- footer.jsp is similar. So are my JSPs dynamic? If so, can I solve my memory problems by switching them to XML docs and using a single JSP page (along with XSLT) to render the pages? Thanks much for your help. Steve -Original Message- From: Will Hartung [mailto:[EMAIL PROTECTED]] Sent: Friday, January 03, 2003 4:54 PM To: Tomcat Users List Subject: Re: Memory Usage and Garbage Collection From: Brandon Cruz [EMAIL PROTECTED] Sent: Friday, January 03, 2003 2:23 PM Subject: RE: Memory Usage and Garbage Collection 1)For every single request to a servlet or JSP page, a new instance of that class is created? For example, if there is one JSP page and ten people access that one page over the course of a day, 10 separate instances of the same class are created and will never be gc'd until the webapp or tomcat is restarted? No no no. Ever so confusing. Here's the rub. First, consider that JSP == Servlet. Second, Servlet == Java Class. When a request comes in for a Servlet, the Servlet class is loaded. Then (assuming we're not using a Single Threaded Model Servlet), a new instance of that Servlet is created to handle the request. These instances of the Servlet will inevitably be GC'd in time. However, what will NOT be GC'd is the CLASS of the Servlet. Once the class is loaded, the class stays around until restart. This is because the ClassLoader for the Servlet hangs on to it. For most applications this is not a problem, as Servlets are roughly equivalent to CGI programs. However, where Servlets are similar to CGI programs, some are equating JSPs with HTML files (or, perhaps better, SHTML files). Most normal sites would have very few CGI programs, but may have loads of HTML or SHTML files. But, since JSPs are actually Servlets in cheap clothing, the JSP == HTML file is not a valid assumption to make. Whereas Servlets are usually mostly just logic, JSPs tend to be mostly content. So, when the server loads the Servlet class generated by the JSP, it loads and caches more content than logic. If Apache remembered and cached every HTML file that went through it, you'd end up potentially caching your entire web tree in RAM. If you happen to have enough RAM to support this, it's not a problem. But if your content is growing every day, and old data doesn't go away, you will eventially run out of RAM and Bad Things will happen. Our site has ~1200 JSPs but all told they only add up to about 6MB, and they're static. So, if all of those managed to get sucked into RAM, the space they would take wouldn't even make a 256MB Tomcat instance blink, so it's not a problem for us. But another fella was generating dynamic JSPs, and would thereby eventually starve out his heap because Tomcat wasn't expiring Servlets. The real question is whether JSPs should be considered Different Enough from normal Servlets to warrant adding code to scavenge them. Regards, Will Hartung ([EMAIL PROTECTED]) -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Memory Usage and Garbage Collection
Thanks for that explanation, But i was just curious to know if weakmaps or similar gc interacting cache be used to keep the mem size in control. Servers with high mem size would continue to keep the cache of jsp's for performance whereas the ones with lesser mem size would still not give the outofmemory error. saurabh [EMAIL PROTECTED] 01/04/03 01:12AM On Fri, 3 Jan 2003, Saurabh Arora wrote: Date: Fri, 03 Jan 2003 02:33:17 -0700 From: Saurabh Arora [EMAIL PROTECTED] Reply-To: Tomcat Users List [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: RE: Memory Usage and Garbage Collection Just wanted to know, does the current implementation of tomcat 4.1.18 also has the same problem of keeping the jsp's in memory. or it was only present in 4.0.4 It's not a *problem* -- it's a *feature* :-). This is one of the keys to maintaining good performance on repeatedly requested pages. Yes, Tomcat 4.1.x maintains a reference to every JSP page that has ever been requested (same as every servlet that has ever been requested) until that webapp is reloaded or removed, or you shut down Tomcat. Given this, designing webapps where you auto-generate hundreds of different JSP pages (which was the choice of the originator of this message thread) is not what you really want to do. Instead, you'd want to use a single JSP page for each basic *style* of output (essentially the JSP page would be a formatting template) that pulls in the unique information for a particular report (from the database, from XML, or whatever) dynamically. Then, a given webpp would likely have 5-10 JSP pages, instead of hundreds. Just as an example, assume that your application back-end gave you the data you need in some XML format, and you want to offer your user the chance to format this data in ten different ways. If you create an XSLT stylesheet to transform the data for each of the ten formats, you can do this all with a *single* JSP page that takes an XML data source and an XSLT stylesheet, applies the transformation, and renders the result. (JSTL has a tag that will do all the grunt work for you.) If you really really want to auto-generate all the reports ahead of time, go ahead and generate static HTML pages -- don't waste your time generating JSP that then has to get compiled, loaded, and executed. As a side benefit, the output will get served a little faster because there is less overhead in serving static files. If you really really really want to generate hundreds of JSP pages, then plan on buying enough memory to hold them all and be done with it. Fortunately, this is not usually a break the bank decision (I just upgraded my development PC to a gigabyte of memory for less than $100 :-). If you really really really really want to generate hundreds of JSP pages, and don't (or can't) afford the memory to hold them all, you only have yourself to blame for the results. saurabh Craig -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Memory Usage and Garbage Collection
So the instance, and it's string, can still be GC'd, right? Nope. There is still a live reference to each OtherObject instance sitting in the static HashMap cache. Therefore, this instance cannot be GC'd, even though *you* have released your own reference to it. And, if the OtherObject class is loaded from Tomcat's common/lib directory (for example), there is no way to ***ever*** GC this instance, because the public API of the OtherObject class doesn't offer any way to clear the cache. Wouldn't it be the responsibility of the Factory to worry about releasing objects to the GC? I mean, if it implements caching, it should have some sort of policy when an instantiated (and, thus, cached) object is a candidate for GC. Obvious guidelines are: - if it is not used - if it has last been used less recently than some limit One can also think of a non-linear function, which checks the available memory or has it's internal memory limit. Nix. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Memory Usage and Garbage Collection
Hi Craig, please see intermixed. On 2 Jan 2003 at 18:18, Craig R. McClanahan wrote: Instances can be garbage collected IF AND ONLY IF there are no live references to that object in a static/instance/local variable of some other object that is also in memory. Only instances that are no longer referenced from other object instances can be recycled. Please consider the following service() or doGet() or so of a servlet: public void service(ServletRequest request, ServletResponse response) throws IOException { OtherObject otherObject = new OtherObject(); otherObject.doThisAndThat(request, response); } Do I have to place the following otherObject = null; before the end of service(). Doesn't otherObject be gc-ed otherwise? I've never done this. What about the object instances, which otherObject.doThisAndThat() creates? So far I've thought there are no live references if otherObject gets gc-ed. In the case at hand, Tomcat (obviously) has references to all the servlets that it has loaded. Therefore, those servlet instances cannot be garbage collected. Furthermore, any object that is referenced by static or instance variables of your servlet class can *also* not be garbage collected, because live references still exist. Same thing for session attributes. OK, this is obvious. Andreas deleted the latter parts... -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Memory Usage and Garbage Collection
Just wanted to know, does the current implementation of tomcat 4.1.18 also has the same problem of keeping the jsp's in memory. or it was only present in 4.0.4 saurabh [EMAIL PROTECTED] 01/03/03 02:26PM Hi Craig, please see intermixed. On 2 Jan 2003 at 18:18, Craig R. McClanahan wrote: Instances can be garbage collected IF AND ONLY IF there are no live references to that object in a static/instance/local variable of some other object that is also in memory. Only instances that are no longer referenced from other object instances can be recycled. Please consider the following service() or doGet() or so of a servlet: public void service(ServletRequest request, ServletResponse response) throws IOException { OtherObject otherObject = new OtherObject(); otherObject.doThisAndThat(request, response); } Do I have to place the following otherObject = null; before the end of service(). Doesn't otherObject be gc-ed otherwise? I've never done this. What about the object instances, which otherObject.doThisAndThat() creates? So far I've thought there are no live references if otherObject gets gc-ed. In the case at hand, Tomcat (obviously) has references to all the servlets that it has loaded. Therefore, those servlet instances cannot be garbage collected. Furthermore, any object that is referenced by static or instance variables of your servlet class can *also* not be garbage collected, because live references still exist. Same thing for session attributes. OK, this is obvious. Andreas deleted the latter parts... -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Memory Usage and Garbage Collection
Hi, There's clearly some misconceptions on the topic of garbage collection ;) These questions come up very often it seems, on this list and others. Please consider the following service() or doGet() or so of a servlet: public void service(ServletRequest request, ServletResponse response) throws IOException { OtherObject otherObject = new OtherObject(); otherObject.doThisAndThat(request, response); } Do I have to place the following otherObject = null; before the end of service(). Doesn't otherObject be gc-ed otherwise? I've never done this. You don't have to do this. The otherObject's reference count is increase by one when you assign it. When the method (service() above) returns, the reference count for otherObject is reduced by one. If the reference count is zero, otherObject can be garbage collected. What about the object instances, which otherObject.doThisAndThat() creates? So far I've thought there are no live references if otherObject gets gc-ed. If otherObject creates local objects, they'll be GCed. If it modifies static objects, those objects stay in a different place anyways and don't get GCed when otherObject does. Back to what Craig mentioned earlier: earlier in the Java life time, classes could get GCed themselves. That really earns you very little, so it was removed. Nowadays demands on classloaders and their hierarchies can get very complicated, so re-introducing class GC would be difficult anyways. A JSP is compiled into a servlet and then loaded into memory. Its bytecode is present only once, and takes up relatively little space (usually). You won't gain much from destroying that bytecode and de-allocating its memory. Same thing for normal servlets obviouisly. What you need to do is tune your garbage collection. With some exceptions, full GCs shouldn't run all the time. Depending on your collector, partial GCs can run all the time. You'd expect that from incremental and concurrent collectors. If you're running on multiple CPUs and have a parallel collector but only one System.out log, you'd expect to see GC output there nearly all the time. So you should start playing with your heap (-Xmx), new generation size and ration (XX:NewSize, XX:MaxNewSize, XX:NewRatio), collector policy (-Xincgc, -Xconcgc, XX:UseParNewGC, etc.) and other parameters to see which gives you the best behavior. Don't -Xmx over the physical RAM size. See the VM options page at: http://java.sun.com/docs/hotspot/VMOptions.html One principle to keep in mind is that memory is cheap, or at least considered cheap when it comes to GC performance tuning. The java heap is greedy overall, and this is intended to increaser performance. That's why it won't de-allocate space (and never return space to the OS) until necessary with the default mark/sweep collector. Make sure to record your verbose:gc output between runs so that you can compare behavior. This is not typically easy to tell by instinctive feel. Yoav Shapira Millennium ChemInformatics -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Memory Usage and Garbage Collection
Hi thank you, your reply calms me down again. I guess I got a bit confused by the preceding discussion. Andreas On 3 Jan 2003 at 8:59, Shapira, Yoav wrote: Hi, There's clearly some misconceptions on the topic of garbage collection ;) These questions come up very often it seems, on this list and others. Please consider the following service() or doGet() or so of a servlet: public void service(ServletRequest request, ServletResponse response) throws IOException { OtherObject otherObject = new OtherObject(); otherObject.doThisAndThat(request, response); } Do I have to place the following otherObject = null; before the end of service(). Doesn't otherObject be gc-ed otherwise? I've never done this. You don't have to do this. The otherObject's reference count is increase by one when you assign it. When the method (service() above) returns, the reference count for otherObject is reduced by one. If the reference count is zero, otherObject can be garbage collected. What about the object instances, which otherObject.doThisAndThat() creates? So far I've thought there are no live references if otherObject gets gc-ed. If otherObject creates local objects, they'll be GCed. If it modifies static objects, those objects stay in a different place anyways and don't get GCed when otherObject does. Back to what Craig mentioned earlier: earlier in the Java life time, classes could get GCed themselves. That really earns you very little, so it was removed. Nowadays demands on classloaders and their hierarchies can get very complicated, so re-introducing class GC would be difficult anyways. A JSP is compiled into a servlet and then loaded into memory. Its bytecode is present only once, and takes up relatively little space (usually). You won't gain much from destroying that bytecode and de-allocating its memory. Same thing for normal servlets obviouisly. What you need to do is tune your garbage collection. With some exceptions, full GCs shouldn't run all the time. Depending on your collector, partial GCs can run all the time. You'd expect that from incremental and concurrent collectors. If you're running on multiple CPUs and have a parallel collector but only one System.out log, you'd expect to see GC output there nearly all the time. So you should start playing with your heap (-Xmx), new generation size and ration (XX:NewSize, XX:MaxNewSize, XX:NewRatio), collector policy (-Xincgc, -Xconcgc, XX:UseParNewGC, etc.) and other parameters to see which gives you the best behavior. Don't -Xmx over the physical RAM size. See the VM options page at: http://java.sun.com/docs/hotspot/VMOptions.html One principle to keep in mind is that memory is cheap, or at least considered cheap when it comes to GC performance tuning. The java heap is greedy overall, and this is intended to increaser performance. That's why it won't de-allocate space (and never return space to the OS) until necessary with the default mark/sweep collector. Make sure to record your verbose:gc output between runs so that you can compare behavior. This is not typically easy to tell by instinctive feel. Yoav Shapira Millennium ChemInformatics -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Memory Usage and Garbage Collection
On Fri, 3 Jan 2003, Andreas Probst wrote: Hi Craig, please see intermixed. On 2 Jan 2003 at 18:18, Craig R. McClanahan wrote: Instances can be garbage collected IF AND ONLY IF there are no live references to that object in a static/instance/local variable of some other object that is also in memory. Only instances that are no longer referenced from other object instances can be recycled. Please consider the following service() or doGet() or so of a servlet: public void service(ServletRequest request, ServletResponse response) throws IOException { OtherObject otherObject = new OtherObject(); otherObject.doThisAndThat(request, response); } Do I have to place the following otherObject = null; before the end of service(). Doesn't otherObject be gc-ed otherwise? I've never done this. The otherObject reference goes away as soon as the service() method returns, so you don't have to actually release it yourself. HOWEVER, you also need to understand what the constructor of this class did, and what the doThisAndThat() method did -- it's still possible for that class to cause memory leaks which you don't know anything about, or possibly can't do anything about. What about the object instances, which otherObject.doThisAndThat() creates? So far I've thought there are no live references if otherObject gets gc-ed. Let's look at a simple case and a complex case: SIMPLE CASE: OtherObject has a single instance variable that is initialized to a String: public class OtherObject { private String id; public OtherObject(String id) { this.id = id; } public String getId() { return (this.id); } } In this case, the only reference to the String pointed at by id is in this instance of OtherObject. Therefore, when you release your reference to the OtherObject instance and the id string that was passed in (because the service() method ended), both the OtherObject instance and the foo String instance are available for GC. COMPLEX CASE: OtherObject is a little trickier in its initialization -- it provides a factory pattern method that creates at most one instance of OtherObject for a particular identifier string. (This is a *very* common design pattern -- in fact, Tomcat implements something sort of like this to ensure that there is at most one instance of each servlet class.) public class OtherObject { // Private constructor -- use the factory method instead private OtherObject(String id) { this.id = id; } // Private instance variable -- one per instance private String id; // Public getter for the id property public String getId() { return (this.id); } // Static cache of previously created instances private static HashMap cache = new HashMap(); // Factory method for creating OtherObject instances that // guarantees to create only one for a particular id string public static OtherObject getOtherObject(String id) { synchronized (cache) { OtherObject instance = (OtherObject) cache.get(id); if (instance == null) { instance = new OtherObject(id); cache.put(id, instance); } return (instance); } } } To use the factory method, you'd say something like this: OtherObject otherObject = OtherObject.getOtherObject(idstring); instead of: OtherObject otherObject = new OtherObject(idstring); and, no matter how many times you call this with the same parameter value, you'd get the same instance back (basically a singleton pattern with lazy instantiation). Now, your otherObject reference still goes away at the end of the service() method, right? Yep. So the instance, and it's string, can still be GC'd, right? Nope. There is still a live reference to each OtherObject instance sitting in the static HashMap cache. Therefore, this instance cannot be GC'd, even though *you* have released your own reference to it. And, if the OtherObject class is loaded from Tomcat's common/lib directory (for example), there is no way to ***ever*** GC this instance, because the public API of the OtherObject class doesn't offer any way to clear the cache. Note also that there is nothing that your servlet can do about this -- you can't even know if its happening without consulting the documentation and/or the source code for the classes you are calling. But the code above will cause a slowly increasing consumption of memory over time (assuming that you're asking for different id values), even though *you* are not maintaining any live references to these objects. Craig -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Memory Usage and Garbage Collection
On Fri, 3 Jan 2003, Saurabh Arora wrote: Date: Fri, 03 Jan 2003 02:33:17 -0700 From: Saurabh Arora [EMAIL PROTECTED] Reply-To: Tomcat Users List [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: RE: Memory Usage and Garbage Collection Just wanted to know, does the current implementation of tomcat 4.1.18 also has the same problem of keeping the jsp's in memory. or it was only present in 4.0.4 It's not a *problem* -- it's a *feature* :-). This is one of the keys to maintaining good performance on repeatedly requested pages. Yes, Tomcat 4.1.x maintains a reference to every JSP page that has ever been requested (same as every servlet that has ever been requested) until that webapp is reloaded or removed, or you shut down Tomcat. Given this, designing webapps where you auto-generate hundreds of different JSP pages (which was the choice of the originator of this message thread) is not what you really want to do. Instead, you'd want to use a single JSP page for each basic *style* of output (essentially the JSP page would be a formatting template) that pulls in the unique information for a particular report (from the database, from XML, or whatever) dynamically. Then, a given webpp would likely have 5-10 JSP pages, instead of hundreds. Just as an example, assume that your application back-end gave you the data you need in some XML format, and you want to offer your user the chance to format this data in ten different ways. If you create an XSLT stylesheet to transform the data for each of the ten formats, you can do this all with a *single* JSP page that takes an XML data source and an XSLT stylesheet, applies the transformation, and renders the result. (JSTL has a tag that will do all the grunt work for you.) If you really really want to auto-generate all the reports ahead of time, go ahead and generate static HTML pages -- don't waste your time generating JSP that then has to get compiled, loaded, and executed. As a side benefit, the output will get served a little faster because there is less overhead in serving static files. If you really really really want to generate hundreds of JSP pages, then plan on buying enough memory to hold them all and be done with it. Fortunately, this is not usually a break the bank decision (I just upgraded my development PC to a gigabyte of memory for less than $100 :-). If you really really really really want to generate hundreds of JSP pages, and don't (or can't) afford the memory to hold them all, you only have yourself to blame for the results. saurabh Craig -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Memory Usage and Garbage Collection
Hi Craig, thank you very much for this complete explanation. That's perfectly understandable and the GC-behaviour which I had expected before. I must have understood something wrong in this thread's discussion, which went on yesterday. Again, thank you very much for your helpful responses (not only this one). Andreas On 3 Jan 2003 at 11:31, Craig R. McClanahan wrote: On Fri, 3 Jan 2003, Andreas Probst wrote: Hi Craig, please see intermixed. On 2 Jan 2003 at 18:18, Craig R. McClanahan wrote: Instances can be garbage collected IF AND ONLY IF there are no live references to that object in a static/instance/local variable of some other object that is also in memory. Only instances that are no longer referenced from other object instances can be recycled. Please consider the following service() or doGet() or so of a servlet: public void service(ServletRequest request, ServletResponse response) throws IOException { OtherObject otherObject = new OtherObject(); otherObject.doThisAndThat(request, response); } Do I have to place the following otherObject = null; before the end of service(). Doesn't otherObject be gc-ed otherwise? I've never done this. The otherObject reference goes away as soon as the service() method returns, so you don't have to actually release it yourself. HOWEVER, you also need to understand what the constructor of this class did, and what the doThisAndThat() method did -- it's still possible for that class to cause memory leaks which you don't know anything about, or possibly can't do anything about. What about the object instances, which otherObject.doThisAndThat() creates? So far I've thought there are no live references if otherObject gets gc-ed. Let's look at a simple case and a complex case: SIMPLE CASE: OtherObject has a single instance variable that is initialized to a String: public class OtherObject { private String id; public OtherObject(String id) { this.id = id; } public String getId() { return (this.id); } } In this case, the only reference to the String pointed at by id is in this instance of OtherObject. Therefore, when you release your reference to the OtherObject instance and the id string that was passed in (because the service() method ended), both the OtherObject instance and the foo String instance are available for GC. COMPLEX CASE: OtherObject is a little trickier in its initialization -- it provides a factory pattern method that creates at most one instance of OtherObject for a particular identifier string. (This is a *very* common design pattern -- in fact, Tomcat implements something sort of like this to ensure that there is at most one instance of each servlet class.) public class OtherObject { // Private constructor -- use the factory method instead private OtherObject(String id) { this.id = id; } // Private instance variable -- one per instance private String id; // Public getter for the id property public String getId() { return (this.id); } // Static cache of previously created instances private static HashMap cache = new HashMap(); // Factory method for creating OtherObject instances that // guarantees to create only one for a particular id string public static OtherObject getOtherObject(String id) { synchronized (cache) { OtherObject instance = (OtherObject) cache.get(id); if (instance == null) { instance = new OtherObject(id); cache.put(id, instance); } return (instance); } } } To use the factory method, you'd say something like this: OtherObject otherObject = OtherObject.getOtherObject(idstring); instead of: OtherObject otherObject = new OtherObject(idstring); and, no matter how many times you call this with the same parameter value, you'd get the same instance back (basically a singleton pattern with lazy instantiation). Now, your otherObject reference still goes away at the end of the service() method, right? Yep. So the instance, and it's string, can still be GC'd, right? Nope. There is still a live reference to each OtherObject instance sitting in the static HashMap cache. Therefore, this instance cannot be GC'd, even though *you* have released your own reference to it. And, if the OtherObject class is loaded from Tomcat's common/lib directory (for example), there is no way to ***ever*** GC this instance, because the public API of the OtherObject class doesn't offer any way to clear the cache. Note also that there is nothing that your servlet can do about this -- you can't even know if its happening without consulting the documentation and/or the source code for the classes you are calling. But the code above will cause a slowly increasing
RE: Memory Usage and Garbage Collection
Craig, From what you have been saying... 1)For every single request to a servlet or JSP page, a new instance of that class is created? For example, if there is one JSP page and ten people access that one page over the course of a day, 10 separate instances of the same class are created and will never be gc'd until the webapp or tomcat is restarted? 2)If this is true, it looks to me like any java application in the world eventually has to be restarted as more and more people access it. Buying more memory would prolong the time to restart the application, but eventually all the instances created will take up all the available RAM. Is this correct? Brandon -Original Message- From: Craig R. McClanahan [mailto:[EMAIL PROTECTED]] Sent: Friday, January 03, 2003 1:43 PM To: Tomcat Users List Subject: RE: Memory Usage and Garbage Collection On Fri, 3 Jan 2003, Saurabh Arora wrote: Date: Fri, 03 Jan 2003 02:33:17 -0700 From: Saurabh Arora [EMAIL PROTECTED] Reply-To: Tomcat Users List [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: RE: Memory Usage and Garbage Collection Just wanted to know, does the current implementation of tomcat 4.1.18 also has the same problem of keeping the jsp's in memory. or it was only present in 4.0.4 It's not a *problem* -- it's a *feature* :-). This is one of the keys to maintaining good performance on repeatedly requested pages. Yes, Tomcat 4.1.x maintains a reference to every JSP page that has ever been requested (same as every servlet that has ever been requested) until that webapp is reloaded or removed, or you shut down Tomcat. Given this, designing webapps where you auto-generate hundreds of different JSP pages (which was the choice of the originator of this message thread) is not what you really want to do. Instead, you'd want to use a single JSP page for each basic *style* of output (essentially the JSP page would be a formatting template) that pulls in the unique information for a particular report (from the database, from XML, or whatever) dynamically. Then, a given webpp would likely have 5-10 JSP pages, instead of hundreds. Just as an example, assume that your application back-end gave you the data you need in some XML format, and you want to offer your user the chance to format this data in ten different ways. If you create an XSLT stylesheet to transform the data for each of the ten formats, you can do this all with a *single* JSP page that takes an XML data source and an XSLT stylesheet, applies the transformation, and renders the result. (JSTL has a tag that will do all the grunt work for you.) If you really really want to auto-generate all the reports ahead of time, go ahead and generate static HTML pages -- don't waste your time generating JSP that then has to get compiled, loaded, and executed. As a side benefit, the output will get served a little faster because there is less overhead in serving static files. If you really really really want to generate hundreds of JSP pages, then plan on buying enough memory to hold them all and be done with it. Fortunately, this is not usually a break the bank decision (I just upgraded my development PC to a gigabyte of memory for less than $100 :-). If you really really really really want to generate hundreds of JSP pages, and don't (or can't) afford the memory to hold them all, you only have yourself to blame for the results. saurabh Craig -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Memory Usage and Garbage Collection
From: Brandon Cruz [EMAIL PROTECTED] Sent: Friday, January 03, 2003 2:23 PM Subject: RE: Memory Usage and Garbage Collection 1)For every single request to a servlet or JSP page, a new instance of that class is created? For example, if there is one JSP page and ten people access that one page over the course of a day, 10 separate instances of the same class are created and will never be gc'd until the webapp or tomcat is restarted? No no no. Ever so confusing. Here's the rub. First, consider that JSP == Servlet. Second, Servlet == Java Class. When a request comes in for a Servlet, the Servlet class is loaded. Then (assuming we're not using a Single Threaded Model Servlet), a new instance of that Servlet is created to handle the request. These instances of the Servlet will inevitably be GC'd in time. However, what will NOT be GC'd is the CLASS of the Servlet. Once the class is loaded, the class stays around until restart. This is because the ClassLoader for the Servlet hangs on to it. For most applications this is not a problem, as Servlets are roughly equivalent to CGI programs. However, where Servlets are similar to CGI programs, some are equating JSPs with HTML files (or, perhaps better, SHTML files). Most normal sites would have very few CGI programs, but may have loads of HTML or SHTML files. But, since JSPs are actually Servlets in cheap clothing, the JSP == HTML file is not a valid assumption to make. Whereas Servlets are usually mostly just logic, JSPs tend to be mostly content. So, when the server loads the Servlet class generated by the JSP, it loads and caches more content than logic. If Apache remembered and cached every HTML file that went through it, you'd end up potentially caching your entire web tree in RAM. If you happen to have enough RAM to support this, it's not a problem. But if your content is growing every day, and old data doesn't go away, you will eventially run out of RAM and Bad Things will happen. Our site has ~1200 JSPs but all told they only add up to about 6MB, and they're static. So, if all of those managed to get sucked into RAM, the space they would take wouldn't even make a 256MB Tomcat instance blink, so it's not a problem for us. But another fella was generating dynamic JSPs, and would thereby eventually starve out his heap because Tomcat wasn't expiring Servlets. The real question is whether JSPs should be considered Different Enough from normal Servlets to warrant adding code to scavenge them. Regards, Will Hartung ([EMAIL PROTECTED]) -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Memory Usage and Garbage Collection
On Fri, 3 Jan 2003, Brandon Cruz wrote: Date: Fri, 3 Jan 2003 16:23:24 -0600 From: Brandon Cruz [EMAIL PROTECTED] Reply-To: Tomcat Users List [EMAIL PROTECTED], [EMAIL PROTECTED] To: Tomcat Users List [EMAIL PROTECTED] Subject: RE: Memory Usage and Garbage Collection Craig, From what you have been saying... 1)For every single request to a servlet or JSP page, a new instance of that class is created? NO! It's exactly the opposite -- the same instance gets reused every time. For example, if there is one JSP page and ten people access that one page over the course of a day, 10 separate instances of the same class are created and will never be gc'd until the webapp or tomcat is restarted? 2)If this is true, it looks to me like any java application in the world eventually has to be restarted as more and more people access it. Buying more memory would prolong the time to restart the application, but eventually all the instances created will take up all the available RAM. Is this correct? The point I was trying to make is that code you *call* from your servlets and JSPs can create memory leaks, and there's not necessarily anything that you (as the author of the servlet or JSP) page can do about it. You can't even tell that it's happening unless you have access to the source code of the classes you're calling. Assume that you implement something like the complex example from my previous mail, and every call to the getOtherObject() method specifies a different id value. The old OtherObject instances will *not* be GC'd, because there are live references to them -- even if they are not in your servlet, they still exist in the JVM. And the fact that there is only one instance of your servlet is not relevant to this memory leak, because it is not your servlet instances that are being accumulated. It is not good enough to just release references in your servlet when you are through with an object. Brandon Craig -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Memory Usage and Garbage Collection
The same servlet gets called everytime? Isn't this container implementation specific (Although functionally it SHOULD appear to be the same servlet)? For example, couldn't a container do pooling or load balancing. Craig R. McClanahan wrote: On Fri, 3 Jan 2003, Brandon Cruz wrote: Date: Fri, 3 Jan 2003 16:23:24 -0600 From: Brandon Cruz [EMAIL PROTECTED] Reply-To: Tomcat Users List [EMAIL PROTECTED], [EMAIL PROTECTED] To: Tomcat Users List [EMAIL PROTECTED] Subject: RE: Memory Usage and Garbage Collection Craig, From what you have been saying... 1)For every single request to a servlet or JSP page, a new instance of that class is created? NO! It's exactly the opposite -- the same instance gets reused every time. For example, if there is one JSP page and ten people access that one page over the course of a day, 10 separate instances of the same class are created and will never be gc'd until the webapp or tomcat is restarted? 2)If this is true, it looks to me like any java application in the world eventually has to be restarted as more and more people access it. Buying more memory would prolong the time to restart the application, but eventually all the instances created will take up all the available RAM. Is this correct? The point I was trying to make is that code you *call* from your servlets and JSPs can create memory leaks, and there's not necessarily anything that you (as the author of the servlet or JSP) page can do about it. You can't even tell that it's happening unless you have access to the source code of the classes you're calling. Assume that you implement something like the complex example from my previous mail, and every call to the getOtherObject() method specifies a different id value. The old OtherObject instances will *not* be GC'd, because there are live references to them -- even if they are not in your servlet, they still exist in the JVM. And the fact that there is only one instance of your servlet is not relevant to this memory leak, because it is not your servlet instances that are being accumulated. It is not good enough to just release references in your servlet when you are through with an object. Brandon Craig -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- = = Management is doing things right; leadership is doing the = = right things.- Peter Drucker= =___= = http://www.sun.com/service/sunps/jdc/javacenter.pdf = = www.sun.com | www.javasoft.com | http://wwws.sun.com/sunone = = -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Memory Usage and Garbage Collection
Instead, you'd want to use a single JSP page for each basic *style* of output (essentially the JSP page would be a formatting template) that pulls in the unique information for a particular report (from the database, from XML, or whatever) dynamically. For example, with the web site for The Mahogany Man (http://www.the-mahogany-man.com), the entire catalog is a single JSP page. There are 100s of items in the catalog. --- Noel -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Memory Usage and Garbage Collection
There is still a live reference to each OtherObject instance sitting in the static HashMap cache. there is no way to ***ever*** GC this instance Another example of a similar memory leak is the File.deleteOnExit method. It should not be used without extreme care and understanding in a server application, since the system has to hold onto memory related to deleting the file until the JVM shuts down. --- Noel -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Memory Usage and Garbage Collection
On Thu, 2 Jan 2003, Brandon Cruz wrote: Date: Thu, 2 Jan 2003 16:16:23 -0600 From: Brandon Cruz [EMAIL PROTECTED] Reply-To: Tomcat Users List [EMAIL PROTECTED], [EMAIL PROTECTED] To: Tomcat Users List [EMAIL PROTECTED] Subject: Memory Usage and Garbage Collection Do loaded jsp pages and/or class files ever get garbage collected when tomcat is running? It's legal for servlet containers to destroy and release servlets and JSP pages while the server is running, but Tomcat doesn't currently do so. Once a servlet or JSP is loaded, it stays loaded until you reload that particular webapp or you shut Tomcat down. We have a production server with several hundred virtual hosts per host, each with a fair share of jsp pages and with moderate to low traffic per host. As time goes on, the amount of memory being used constantly grows. It starts off around 60MB, then goes higher and higher, getting up to around 100MB after a couple days. The regular GC seems to usually clean up around 2MB ([GC 99493K-97502K(204544K), 0.0243521 secs]) and the Full GC seems to clean up less than that ([Full GC 97388K-97187K(204544K), 2.4269915 secs]). Since I have the -Xmx and -Xms set to 200MB, the 204544K number never gets resized, but the number before the - seems to slowly and steadily rise. Full GC seems to run quite often, every few seconds, GC runs once in a while, but spits out about 50 lines at once every time it runs. Is this normal? Shouldn't Full GC only run once in a while? I am starting to think that as classes and jsp's are loaded, they stay in memory and are never released until tomcat is restarted, which means that there is eventually a point where all the classes will load and I just need to have enough memory to support that without having to use swap space. It's not just the classes -- it's the object instances created from those classes that take up space (the bytecodes of the class itself exist only once). The problem occurs when the memory usage number before the - gets up to about 130. The system is using swap space and eventually out of memory errors start showing up. Any ideas? More Ram, more tuning, different site architecture? If you're using swap space, you probably have your max heap size (-Xmx) too large for the amount of physical memory that is available. I'd definitely start by either reducing -Xmx or increasing the amount of physical RAM. If reducing -Xmx gives you OutOfMemoryException errors, then increasing RAM is the only option. The second thing I'd do is review my applications for places where they might be maintaining references to data in between requests, either in instance variables of the servlet or JSP class or by keeping too many things in the user's session for too long. If there are such references, your user data objects cannot be GC'd and you'll end up with exactly the pattern you describe (slowly increasing memory use). Thanks in advance? Brandon Craig -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Memory Usage and Garbage Collection
Craig, Thanks for your comments, I still have a few clarification questions. 1)It's not just the classes -- it's the object instances created from those classes that take up space (the bytecodes of the class itself exist only once). ---does this mean that every object instance is never garbage collected, or are these instances collected? 2)What about instances of the classes, does every instance stay in memory forever? Are they loaded into the sessions, or are they pooled somehow? What about the instance variables of these classes, I assume they get collected after the class instances would be collected. If class instances stay in memory forever, I would think there is no possible way to ever keep the system running without a restart. Brandon -Original Message- From: Craig R. McClanahan [mailto:[EMAIL PROTECTED]] Sent: Thursday, January 02, 2003 6:12 PM To: Tomcat Users List; [EMAIL PROTECTED] Subject: Re: Memory Usage and Garbage Collection On Thu, 2 Jan 2003, Brandon Cruz wrote: Date: Thu, 2 Jan 2003 16:16:23 -0600 From: Brandon Cruz [EMAIL PROTECTED] Reply-To: Tomcat Users List [EMAIL PROTECTED], [EMAIL PROTECTED] To: Tomcat Users List [EMAIL PROTECTED] Subject: Memory Usage and Garbage Collection Do loaded jsp pages and/or class files ever get garbage collected when tomcat is running? It's legal for servlet containers to destroy and release servlets and JSP pages while the server is running, but Tomcat doesn't currently do so. Once a servlet or JSP is loaded, it stays loaded until you reload that particular webapp or you shut Tomcat down. We have a production server with several hundred virtual hosts per host, each with a fair share of jsp pages and with moderate to low traffic per host. As time goes on, the amount of memory being used constantly grows. It starts off around 60MB, then goes higher and higher, getting up to around 100MB after a couple days. The regular GC seems to usually clean up around 2MB ([GC 99493K-97502K(204544K), 0.0243521 secs]) and the Full GC seems to clean up less than that ([Full GC 97388K-97187K(204544K), 2.4269915 secs]). Since I have the -Xmx and -Xms set to 200MB, the 204544K number never gets resized, but the number before the - seems to slowly and steadily rise. Full GC seems to run quite often, every few seconds, GC runs once in a while, but spits out about 50 lines at once every time it runs. Is this normal? Shouldn't Full GC only run once in a while? I am starting to think that as classes and jsp's are loaded, they stay in memory and are never released until tomcat is restarted, which means that there is eventually a point where all the classes will load and I just need to have enough memory to support that without having to use swap space. It's not just the classes -- it's the object instances created from those classes that take up space (the bytecodes of the class itself exist only once). The problem occurs when the memory usage number before the - gets up to about 130. The system is using swap space and eventually out of memory errors start showing up. Any ideas? More Ram, more tuning, different site architecture? If you're using swap space, you probably have your max heap size (-Xmx) too large for the amount of physical memory that is available. I'd definitely start by either reducing -Xmx or increasing the amount of physical RAM. If reducing -Xmx gives you OutOfMemoryException errors, then increasing RAM is the only option. The second thing I'd do is review my applications for places where they might be maintaining references to data in between requests, either in instance variables of the servlet or JSP class or by keeping too many things in the user's session for too long. If there are such references, your user data objects cannot be GC'd and you'll end up with exactly the pattern you describe (slowly increasing memory use). Thanks in advance? Brandon Craig -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Memory Usage and Garbage Collection
Looking at the jasper source of tomcat 4.0.4 releasing jsp's seems to be reasonable easy to implement: The Jsp's classloader, the class and the actual jsp-servlet instance are all put together in a JspServletWrapper-Object which itself is stored in the JspServlet (the Servlet used to executing jsps) using a Hashtable. One could replace the hashtable with a LRU-Cache or anything. Since each jsp is loaded using a separate classloader, removing the Wrapper removes the reference to the instance, it's class and it's loader, which should enable the class garbage collector to remove the class. Do you think this approach is reasonable? Does this part of the implementation differ with Jasper2? This is a feature I could really use well. llap, julian - Original Message - From: Craig R. McClanahan [EMAIL PROTECTED] To: Tomcat Users List [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Friday, January 03, 2003 1:12 AM Subject: Re: Memory Usage and Garbage Collection On Thu, 2 Jan 2003, Brandon Cruz wrote: Date: Thu, 2 Jan 2003 16:16:23 -0600 From: Brandon Cruz [EMAIL PROTECTED] Reply-To: Tomcat Users List [EMAIL PROTECTED], [EMAIL PROTECTED] To: Tomcat Users List [EMAIL PROTECTED] Subject: Memory Usage and Garbage Collection Do loaded jsp pages and/or class files ever get garbage collected when tomcat is running? It's legal for servlet containers to destroy and release servlets and JSP pages while the server is running, but Tomcat doesn't currently do so. Once a servlet or JSP is loaded, it stays loaded until you reload that particular webapp or you shut Tomcat down. We have a production server with several hundred virtual hosts per host, each with a fair share of jsp pages and with moderate to low traffic per host. As time goes on, the amount of memory being used constantly grows. It starts off around 60MB, then goes higher and higher, getting up to around 100MB after a couple days. The regular GC seems to usually clean up around 2MB ([GC 99493K-97502K(204544K), 0.0243521 secs]) and the Full GC seems to clean up less than that ([Full GC 97388K-97187K(204544K), 2.4269915 secs]). Since I have the -Xmx and -Xms set to 200MB, the 204544K number never gets resized, but the number before the - seems to slowly and steadily rise. Full GC seems to run quite often, every few seconds, GC runs once in a while, but spits out about 50 lines at once every time it runs. Is this normal? Shouldn't Full GC only run once in a while? I am starting to think that as classes and jsp's are loaded, they stay in memory and are never released until tomcat is restarted, which means that there is eventually a point where all the classes will load and I just need to have enough memory to support that without having to use swap space. It's not just the classes -- it's the object instances created from those classes that take up space (the bytecodes of the class itself exist only once). The problem occurs when the memory usage number before the - gets up to about 130. The system is using swap space and eventually out of memory errors start showing up. Any ideas? More Ram, more tuning, different site architecture? If you're using swap space, you probably have your max heap size (-Xmx) too large for the amount of physical memory that is available. I'd definitely start by either reducing -Xmx or increasing the amount of physical RAM. If reducing -Xmx gives you OutOfMemoryException errors, then increasing RAM is the only option. The second thing I'd do is review my applications for places where they might be maintaining references to data in between requests, either in instance variables of the servlet or JSP class or by keeping too many things in the user's session for too long. If there are such references, your user data objects cannot be GC'd and you'll end up with exactly the pattern you describe (slowly increasing memory use). Thanks in advance? Brandon Craig -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Memory Usage and Garbage Collection
On Thu, 2 Jan 2003, Brandon Cruz wrote: Date: Thu, 2 Jan 2003 19:04:55 -0600 From: Brandon Cruz [EMAIL PROTECTED] To: Tomcat Users List [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: RE: Memory Usage and Garbage Collection Craig, Thanks for your comments, I still have a few clarification questions. 1)It's not just the classes -- it's the object instances created from those classes that take up space (the bytecodes of the class itself exist only once). ---does this mean that every object instance is never garbage collected, or are these instances collected? Instances can be garbage collected IF AND ONLY IF there are no live references to that object in a static/instance/local variable of some other object that is also in memory. Only instances that are no longer referenced from other object instances can be recycled. In the case at hand, Tomcat (obviously) has references to all the servlets that it has loaded. Therefore, those servlet instances cannot be garbage collected. Furthermore, any object that is referenced by static or instance variables of your servlet class can *also* not be garbage collected, because live references still exist. Same thing for session attributes. In the very early days of Java, classes themselves could be GC'd if there were no live instances of that class. However, this caused more grief than it was worth, so that went away (about JDK 1.1 or so). In today's world, the only way to throw away a class instance is to throw away the class loader that loaded it (which is how Tomcat implements webapp reloading). 2)What about instances of the classes, does every instance stay in memory forever? Are they loaded into the sessions, or are they pooled somehow? What about the instance variables of these classes, I assume they get collected after the class instances would be collected. As above, instances ALWAYS stay in memory as long as there are live references. If there are no live references, the GC is free to clean them up if and when it feels like it. If class instances stay in memory forever, I would think there is no possible way to ever keep the system running without a restart. As above, you can throw away references to a ClassLoader, and that will ultimately cause all the instances to be collected -- but ONLY if there are not any references to any instances of classes loaded by that ClassLoader somewhere else. Phew, that doesn't make sense -- can we describe a sample use case? Sure. Consider the fact that Tomcat provides more than one class loader (see http://jakarta.apache.org/tomcat/tomcat-4.1-doc/class-loader-howto.html). The common and shared class loaders are never thrown away, so any classes loaded from there will stay in memory for the lifetime of Tomcat. But wait, there's more. Assume that you've got a class, loaded from a library in common/lib, that maintains a collection as a static variable. Now, assume you've called a method on this class, and passed it a reference to a bean (or something) that is loaded from your webapp (i.e. it's in WEB-INF/classes or WEB-INF/lib), and this reference gets added to the static collection. Now, ask Tomcat to reload this application. What happens? Tomcat dutifully throws away its reference to the webapp class loader. Normally, that means everything loaded from that class loader is now garbage and can be collected. HOWEVER, because there is still a live reference to one of the objects from your old webapp in the static collection. Therefore, GC cannot process: * The instance of your bean class that was referenced * The class of your bean * The webapp class loader * Any other objects referenced by the webapp class loader. In short, the above scenario just created a memory leak. The best thing you can do to avoid problems like this is to make your webapps self contained, and to always release references to objects you don't need any longer. Brandon Craig -Original Message- From: Craig R. McClanahan [mailto:[EMAIL PROTECTED]] Sent: Thursday, January 02, 2003 6:12 PM To: Tomcat Users List; [EMAIL PROTECTED] Subject: Re: Memory Usage and Garbage Collection On Thu, 2 Jan 2003, Brandon Cruz wrote: Date: Thu, 2 Jan 2003 16:16:23 -0600 From: Brandon Cruz [EMAIL PROTECTED] Reply-To: Tomcat Users List [EMAIL PROTECTED], [EMAIL PROTECTED] To: Tomcat Users List [EMAIL PROTECTED] Subject: Memory Usage and Garbage Collection Do loaded jsp pages and/or class files ever get garbage collected when tomcat is running? It's legal for servlet containers to destroy and release servlets and JSP pages while the server is running, but Tomcat doesn't currently do so. Once a servlet or JSP is loaded, it stays loaded until you reload that particular webapp or you shut Tomcat down. We have a production server with several hundred virtual hosts per host, each with a fair share of jsp pages and with moderate to low traffic per host. As time goes
Re: Memory Usage and Garbage Collection
On Fri, 3 Jan 2003, Julian Löffelhardt wrote: Date: Fri, 3 Jan 2003 02:01:58 +0100 From: Julian Löffelhardt [EMAIL PROTECTED] Reply-To: Tomcat Users List [EMAIL PROTECTED] To: Tomcat Users List [EMAIL PROTECTED] Subject: Re: Memory Usage and Garbage Collection Looking at the jasper source of tomcat 4.0.4 releasing jsp's seems to be reasonable easy to implement: The Jsp's classloader, the class and the actual jsp-servlet instance are all put together in a JspServletWrapper-Object which itself is stored in the JspServlet (the Servlet used to executing jsps) using a Hashtable. One could replace the hashtable with a LRU-Cache or anything. Since each jsp is loaded using a separate classloader, removing the Wrapper removes the reference to the instance, it's class and it's loader, which should enable the class garbage collector to remove the class. Do you think this approach is reasonable? Does this part of the implementation differ with Jasper2? You'd best examine the sources to figure that out :-). But Jasper2 is radically different than Jasper1. But remember, it's not just a matter of throwing away the reference to the compiled servlet class. You also need to ensure that the destroy() method gets called as the servlet API requires -- all the while ensuring that no additional requests start getting processed through the service method. And, don't forget that this will harm performance for the vast majority of users who *do* have adequate memory on their servers, so nothing like this should be enabled by default. This is a feature I could really use well. llap, julian Craig - Original Message - From: Craig R. McClanahan [EMAIL PROTECTED] To: Tomcat Users List [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Friday, January 03, 2003 1:12 AM Subject: Re: Memory Usage and Garbage Collection On Thu, 2 Jan 2003, Brandon Cruz wrote: Date: Thu, 2 Jan 2003 16:16:23 -0600 From: Brandon Cruz [EMAIL PROTECTED] Reply-To: Tomcat Users List [EMAIL PROTECTED], [EMAIL PROTECTED] To: Tomcat Users List [EMAIL PROTECTED] Subject: Memory Usage and Garbage Collection Do loaded jsp pages and/or class files ever get garbage collected when tomcat is running? It's legal for servlet containers to destroy and release servlets and JSP pages while the server is running, but Tomcat doesn't currently do so. Once a servlet or JSP is loaded, it stays loaded until you reload that particular webapp or you shut Tomcat down. We have a production server with several hundred virtual hosts per host, each with a fair share of jsp pages and with moderate to low traffic per host. As time goes on, the amount of memory being used constantly grows. It starts off around 60MB, then goes higher and higher, getting up to around 100MB after a couple days. The regular GC seems to usually clean up around 2MB ([GC 99493K-97502K(204544K), 0.0243521 secs]) and the Full GC seems to clean up less than that ([Full GC 97388K-97187K(204544K), 2.4269915 secs]). Since I have the -Xmx and -Xms set to 200MB, the 204544K number never gets resized, but the number before the - seems to slowly and steadily rise. Full GC seems to run quite often, every few seconds, GC runs once in a while, but spits out about 50 lines at once every time it runs. Is this normal? Shouldn't Full GC only run once in a while? I am starting to think that as classes and jsp's are loaded, they stay in memory and are never released until tomcat is restarted, which means that there is eventually a point where all the classes will load and I just need to have enough memory to support that without having to use swap space. It's not just the classes -- it's the object instances created from those classes that take up space (the bytecodes of the class itself exist only once). The problem occurs when the memory usage number before the - gets up to about 130. The system is using swap space and eventually out of memory errors start showing up. Any ideas? More Ram, more tuning, different site architecture? If you're using swap space, you probably have your max heap size (-Xmx) too large for the amount of physical memory that is available. I'd definitely start by either reducing -Xmx or increasing the amount of physical RAM. If reducing -Xmx gives you OutOfMemoryException errors, then increasing RAM is the only option. The second thing I'd do is review my applications for places where they might be maintaining references to data in between requests, either in instance variables of the servlet or JSP class or by keeping too many things in the user's session for too long. If there are such references, your user data objects cannot be GC'd and you'll end up with exactly the pattern you describe (slowly increasing memory use). Thanks in advance? Brandon Craig
RE: Memory usage?
you using JDBC? Head of Operations AsiaPac elata Level 30 6 Battery Road Singapore 049909 Office : +65 65509723 Mobile : +65 91117814 Fax: +65 65509725 [EMAIL PROTECTED] http://www.elata.com This e-mail is intended solely for the above mentioned recipient(s) and it may contain confidential information. If you have received this e-mail in error, please notify us immediately and delete the e-mail from your system. Copying, distribution or other use of the information contained in this e-mail is strictly prohibited. Nothing in this e-mail amounts to a contractual commitment, or is otherwise legally binding on elata unless confirmed by an authorised representative independently of this e-mail. Registered in England, number 1961405 -Original Message- From: Schnitzer, Jeff [mailto:[EMAIL PROTECTED]] Sent: 04 December 2002 12:59 To: [EMAIL PROTECTED] Subject: Memory usage? This is probably a more general java question: My long-running Tomcat processes become huge. I have the max heap set to -Xmx512m, yet after a day or so the virtual size of java reaches upwards of 2GB, and the resident size sometimes exceeds 1GB. Shouldn't I get OutOfMemoryErrors sooner? If it's not heap, what is in all that extra space? I'm pretty certain that I just need to reduce my session timeout (it's way too long, and we get a _lot_ of traffic). But the JVM behavior surprises me. This is with the Sun JDK 1.4.1_01 on Linux. Thanks, Jeff Schnitzer [EMAIL PROTECTED] The Sims Online -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Memory usage?
Ah, yes, of course - the oracle oci drivers have a native code component. Yuck. Thanks! Jeff Schnitzer [EMAIL PROTECTED] The Sims Online -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Sent: Tuesday, December 03, 2002 11:00 PM To: Tomcat Users List Subject: RE: Memory usage? you using JDBC? Head of Operations AsiaPac elata Level 30 6 Battery Road Singapore 049909 Office : +65 65509723 Mobile : +65 91117814 Fax: +65 65509725 [EMAIL PROTECTED] http://www.elata.com This e-mail is intended solely for the above mentioned recipient(s) and it may contain confidential information. If you have received this e-mail in error, please notify us immediately and delete the e-mail from your system. Copying, distribution or other use of the information contained in this e-mail is strictly prohibited. Nothing in this e-mail amounts to a contractual commitment, or is otherwise legally binding on elata unless confirmed by an authorised representative independently of this e-mail. Registered in England, number 1961405 -Original Message- From: Schnitzer, Jeff [mailto:[EMAIL PROTECTED]] Sent: 04 December 2002 12:59 To: [EMAIL PROTECTED] Subject: Memory usage? This is probably a more general java question: My long-running Tomcat processes become huge. I have the max heap set to -Xmx512m, yet after a day or so the virtual size of java reaches upwards of 2GB, and the resident size sometimes exceeds 1GB. Shouldn't I get OutOfMemoryErrors sooner? If it's not heap, what is in all that extra space? I'm pretty certain that I just need to reduce my session timeout (it's way too long, and we get a _lot_ of traffic). But the JVM behavior surprises me. This is with the Sun JDK 1.4.1_01 on Linux. Thanks, Jeff Schnitzer [EMAIL PROTECTED] The Sims Online -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:tomcat-user- [EMAIL PROTECTED] For additional commands, e-mail: mailto:tomcat-user- [EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: memory usage by webapp
Hi, Good luck ;) Try running tomcat with one webapp at a time, i.e. un-deploy the others. If they're all running within the same JVM, I don't know how you'd distinguish them. Also, be careful to distinguish between top and/or the task manager, and java's Runtime.totalMemory() and .freeMemory() calls. The java Runtime ones will always be less, as the top/task manager include OS overhead memory. But if you're performance tuning with the java heap, the java Runtime is what you tune for. Yoav Shapira Millennium ChemInformatics -Original Message- From: Will Glass-Husain [mailto:[EMAIL PROTECTED]] Sent: Wednesday, July 10, 2002 5:57 PM To: [EMAIL PROTECTED] Subject: memory usage by webapp Hi, Is there any way to tell how much memory a particular webapp is using? I know I can get the memory usage for the Tomcat's JVM as a whole with top in Linux and the Task Manager in Windows. (I'm running Windows, I must confess).But I have multiple webapps and would like to see how much memory each one is using. Thanks in advance, WiLL ___ Forio Business Simulations Will Glass-Husain (415) 440-7500 phone (415) 235-4293 mobile [EMAIL PROTECTED] www.forio.com -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: memory usage (longish)
I cannot help you on the real problem, but i think both kinds of error are the same. The missing memory in your free output seems to be gone into linux' file system buffers and cache (cache: 1082072, nearly 1GB). So almost every file on your hard drive most likely has been cached ;-). If any other real process needs memory, linux automatically reduces its cache. So don't worry too much about low memory, until the cache usage is high in the output of free. I don't think, that this is a tomcat issue, but a jvm problem. On our servers we usually use the IBM jdk 1.3, which for my experience is more stable in a server environment (while for client applications with swing i always use a sun jdk) and does not produce these annoying server stops on garbage collection, if your application uses many little objects. It uses more memory on startup of the server, but then usually grows slower. Jens Stutte Simon Juden Simon.Juden@ProQuestATo: '[EMAIL PROTECTED]' lison.com[EMAIL PROTECTED] cc: 08/07/2002 12.04 Subject: memory usage (longish) Please respond to Tomcat Users List Got a funny problem with memory usage. Initially assumed likely to be a linux issue. Had the problem on RedHat 6.2, upgraded to RedHat 7.3, still have the problem. Not sure now if it's a linux or tomcat issue. Set-up/environment: Red Hat (now 7.3, with ext3), 1xi686 processor, 1.5Gb memory, Apache 1.3.26, Tomcat 3.2.4, JVM 1.3.1_01 (for the curious there are plans to upgrade these latter three elements but not yet). There are four of these in a webserver farm (hardware-accelerated SSL and loadbalancing happens before traffic gets near the farm). The problem happens on two of the four boxes occasionally, on one fairly often and on the fourth almost every other day. There are two ways the problem manifests itself. The most usual is as follows. Run webapp in tomcat (max heap size set to 500Mb). After some time Tomcat falls over with a an OutOfMemoryError. When it does this it is only using about 150Mb total (so in particular heap well under 500mb max) reported under ps, top etc. However the box reports all but a few megs of the 1.5Gb in use. It reports all this as still in use when every single java process (and every process my clients wrote) is shut down. There's about 60 Mb-worth of usage from the CPU processes and that's all I can account for. There is virtually no swap space usage though there's plenty available. The output of free (after tomcat and all non-canonical processes shut down) is: [root@prodfarm3 logs]# free total used free sharedbuffers cached Mem: 15480841351560 196524 0 1069001082072 -/+ buffers/cache: 1625881385496 Swap: 538136 0 538136 Load averages are not high throughout any of this (1.6-1.7 or so). I know the DMA can take memory (but surely not this much and not for so long). I can't for the life of me think what could be using all the rest. The other way the problem manifests itself is that Tomcat falls over with an OutOfMemoryError but there are still several hundred megs still available on the linux box. The webapp does not allocate huge objects - I can fully load it on the test box with a bunch of (robot) users and it uses about 200 megs or so. So how it finds itself out of memory in this instance I don't know. I'm not sure if this is the same problem or a different one. I've written a few robots and bombarded a test box (identical configuration, except less physical memory, only 250Mb) with a bunch of concurrent user sessions. Different phenomena totally: load average soars (to about 8-9) but java correctly handles its memory and the thing doesn't die. However after an extended run turning tomcat off again leaves 248 of 250Mb reported in use (but this doesn't seem to be a problem when rerunning stuff). But my point is this isn't happening because
RE: memory usage (longish)
Thanks Jens - yes what you say about the memory makes sense (there's not that much in the cache when the thing's running btw ;-). Has anyone else had this kind of issue using tomcat 3.2.4 with a Sun JVM (specifically 1.3.1_01 on Red Hat Linux 7.3 (Valhalla)) - and if so what fixed it? Thanks S -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Sent: 08 July 2002 13:26 To: Tomcat Users List Subject: Re: memory usage (longish) I cannot help you on the real problem, but i think both kinds of error are the same. The missing memory in your free output seems to be gone into linux' file system buffers and cache (cache: 1082072, nearly 1GB). So almost every file on your hard drive most likely has been cached ;-). If any other real process needs memory, linux automatically reduces its cache. So don't worry too much about low memory, until the cache usage is high in the output of free. I don't think, that this is a tomcat issue, but a jvm problem. On our servers we usually use the IBM jdk 1.3, which for my experience is more stable in a server environment (while for client applications with swing i always use a sun jdk) and does not produce these annoying server stops on garbage collection, if your application uses many little objects. It uses more memory on startup of the server, but then usually grows slower. Jens Stutte - Got a funny problem with memory usage. Initially assumed likely to be a linux issue. Had the problem on RedHat 6.2, upgraded to RedHat 7.3, still have the problem. Not sure now if it's a linux or tomcat issue. Set-up/environment: Red Hat (now 7.3, with ext3), 1xi686 processor, 1.5Gb memory, Apache 1.3.26, Tomcat 3.2.4, JVM 1.3.1_01 (for the curious there are plans to upgrade these latter three elements but not yet). There are four of these in a webserver farm (hardware-accelerated SSL and loadbalancing happens before traffic gets near the farm). The problem happens on two of the four boxes occasionally, on one fairly often and on the fourth almost every other day. There are two ways the problem manifests itself. The most usual is as follows. Run webapp in tomcat (max heap size set to 500Mb). After some time Tomcat falls over with a an OutOfMemoryError. When it does this it is only using about 150Mb total (so in particular heap well under 500mb max) reported under ps, top etc. However the box reports all but a few megs of the 1.5Gb in use. It reports all this as still in use when every single java process (and every process my clients wrote) is shut down. There's about 60 Mb-worth of usage from the CPU processes and that's all I can account for. There is virtually no swap space usage though there's plenty available. The output of free (after tomcat and all non-canonical processes shut down) is: [root@prodfarm3 logs]# free total used free sharedbuffers cached Mem: 15480841351560 196524 0 1069001082072 -/+ buffers/cache: 1625881385496 Swap: 538136 0 538136 Load averages are not high throughout any of this (1.6-1.7 or so). I know the DMA can take memory (but surely not this much and not for so long). I can't for the life of me think what could be using all the rest. The other way the problem manifests itself is that Tomcat falls over with an OutOfMemoryError but there are still several hundred megs still available on the linux box. The webapp does not allocate huge objects - I can fully load it on the test box with a bunch of (robot) users and it uses about 200 megs or so. So how it finds itself out of memory in this instance I don't know. I'm not sure if this is the same problem or a different one. I've written a few robots and bombarded a test box (identical configuration, except less physical memory, only 250Mb) with a bunch of concurrent user sessions. Different phenomena totally: load average soars (to about 8-9) but java correctly handles its memory and the thing doesn't die. However after an extended run turning tomcat off again leaves 248 of 250Mb reported in use (but this doesn't seem to be a problem when rerunning stuff). But my point is this isn't happening because the app's getting overloaded (threadpool for tomcat has max size of 200 but it's never used more than 120-130 threads). Not to put too fine a point on it: help ;-) Are there any FMs I should be R'ing but haven't found (I've tried my favourite metamanual (Google) and the red hat and tomcat list archives)? Are there configuration settings that could affect/cause this kind of behaviour? I'm kind of running out of ideas... _ ProQuest Alison Please note Alison Associates is now ProQuest Alison - this is purely a change of name to bring us in line with the rest of the ProQuest group. As a result our e-mail domain has changed to proquestalison.com. We
Re: Memory usage
Yaogeng - That is normal for any java application running on Linux. Just java native threads showing up as multiple processes, but its actually mostly shared memory. Do a 'top' to confirm. jeff Yaogeng Cheng wrote: Hi: I am using TomCat version 3.2.1 in Linux, and I found there are a lot of java apps running after I started the tomcat. They used a lot of memory. Does newer version TomCat use much less memory than 3.2.1. If there is, which version should I use? Thanks, Yaogeng -- Jeffrey Bonevich Ann Arbor, Michigan [EMAIL PROTECTED] http://www.bonevich.com Hwæt! Wë Gär-Dena in geär-dagum, peod-cyninga, prym gefrünon, hü ða aepelingas ellen fremedon! -- To unsubscribe: mailto:[EMAIL PROTECTED] For additional commands: mailto:[EMAIL PROTECTED] Troubles with the list: mailto:[EMAIL PROTECTED]
RE: Memory usage
Jeff: Thanks for the replying. The total memory usage of Apache and tomcat is 14464k. Is that normal? Thanks a lot! Yaogeng -Original Message- From: Jeffrey Bonevich [mailto:[EMAIL PROTECTED]] Sent: Monday, April 08, 2002 6:55 PM To: Tomcat Users List Subject: Re: Memory usage Yaogeng - That is normal for any java application running on Linux. Just java native threads showing up as multiple processes, but its actually mostly shared memory. Do a 'top' to confirm. jeff Yaogeng Cheng wrote: Hi: I am using TomCat version 3.2.1 in Linux, and I found there are a lot of java apps running after I started the tomcat. They used a lot of memory. Does newer version TomCat use much less memory than 3.2.1. If there is, which version should I use? Thanks, Yaogeng -- Jeffrey Bonevich Ann Arbor, Michigan [EMAIL PROTECTED] http://www.bonevich.com Hwæt! Wë Gär-Dena in geär-dagum, peod-cyninga, prym gefrünon, hü ða aepelingas ellen fremedon! -- To unsubscribe: mailto:[EMAIL PROTECTED] For additional commands: mailto:[EMAIL PROTECTED] Troubles with the list: mailto:[EMAIL PROTECTED] -- To unsubscribe: mailto:[EMAIL PROTECTED] For additional commands: mailto:[EMAIL PROTECTED] Troubles with the list: mailto:[EMAIL PROTECTED]
Re: Memory usage
Pretty normal, yes. You can affect that number using command line directives: $ java -Xms64m -Xmx128m blah where -Xms specifies the intial heap size, and -Xmx specifies the max. You would have to alter the startup script to make this effective. Typically you only want to use -Xms if you *know* you will exceed the default initial heap size (no clue what that is, arch dependent); and you only really use -Xmx if you want to impose a more arbitrary upper limit (i.e. please do not use up all resources on my server before crashing and burning). jeff Yaogeng Cheng wrote: Jeff: Thanks for the replying. The total memory usage of Apache and tomcat is 14464k. Is that normal? Thanks a lot! Yaogeng -Original Message- From: Jeffrey Bonevich [mailto:[EMAIL PROTECTED]] Sent: Monday, April 08, 2002 6:55 PM To: Tomcat Users List Subject: Re: Memory usage Yaogeng - That is normal for any java application running on Linux. Just java native threads showing up as multiple processes, but its actually mostly shared memory. Do a 'top' to confirm. jeff Yaogeng Cheng wrote: Hi: I am using TomCat version 3.2.1 in Linux, and I found there are a lot of java apps running after I started the tomcat. They used a lot of memory. Does newer version TomCat use much less memory than 3.2.1. If there is, which version should I use? Thanks, Yaogeng -- Jeffrey Bonevich Ann Arbor, Michigan [EMAIL PROTECTED] http://www.bonevich.com Hwæt! Wë Gär-Dena in geär-dagum, peod-cyninga, prym gefrünon, hü ða aepelingas ellen fremedon! -- To unsubscribe: mailto:[EMAIL PROTECTED] For additional commands: mailto:[EMAIL PROTECTED] Troubles with the list: mailto:[EMAIL PROTECTED]
RE: Memory usage
I found this behaviour on Linux was cured by using hotspot. I don't know how to use hotspot under windows, but I think its a seperate executable (in the JDK) -Original Message-From: Garry De Toffoli [mailto:[EMAIL PROTECTED]]Sent: 03 May 2001 13:34To: [EMAIL PROTECTED]Subject: Memory usage Hi to all, I havein troublewith the memory usage with Tomcat 3.21, on WinNt 2000 and Jdk 1.3 of Sun. the problem is that any operation does not release the memory occuped; to control the memory usage I use the Task Manager; when Tomcat start, the memory used from theprocess Javais of 9608 K; when I request a Jsp page thathas an error, like a variable not declared, the memory used is11868K; if I wait for 1 ay also, this value does not change, so the memory used is not released, running a correct Jsp page, the memory used increase, and this is not released yet; I have written a log on the finalize method of my class, and this is called, so the garbage collector release all my object. This behavoir is normal? Probably changing the version of Tomcat this problem may be corrected. What doyou think about this? Thank you.
Re: Memory usage
Newer versions of Java (1.3 and 1.2.2) have different GC algorithms that might also aid in the clean-up process. JK Courtney, James wrote: Actually, setting a Java object to null (assuming that there are no other references to that object) is the normal way of telling the VM that the object may be garbage collected. The garbage collection takes place asynchronously however and at the discretion of the VM in a background thread. The act of deleting all references to an object does not free the memory associated with the object until the garbage collector cleans up the object. -Jamey -Original Message- From: Jurrius, Mark [mailto:[EMAIL PROTECTED]] Sent: Thursday, May 03, 2001 7:43 AM To: [EMAIL PROTECTED] Subject: RE: Memory usage Correct me if I'm wrong. If for instance I want a bean removed knowing that System.gc() does not happen immediately, would setting the bean equal to null force the bean to be removed from memory right away and not have to rely on the garbage collection to eventually take place? Mark -Original Message- From: William Kaufman [mailto:[EMAIL PROTECTED]] Sent: Thursday, May 03, 2001 10:07 AM To: '[EMAIL PROTECTED]' Subject:RE: Memory usage That your finalize method is called, doesn't mean that the garbage collector has released your objects. The only way to be shure that this happens, is to explicitly run System.gc(). Even that's not sufficient: it just suggests to the VM that garbage-collecting might be a good idea right now. Any actual garbage collection would take place later, in another thread. And, even when it does happen, that doesn't mean all the memory will necessarily be released to the OS: the VM will hold on to some so that it won't need to go back to the OS on the next allocation. You might want to get a memory profiler (like JProbe) and see where the memory is going. At the very least, try doing something like, Runtime rt = Runtime.getRuntime(); System.err.println(Free=+rt.freeMemory()+, total=+rt.totalMemory()); often, to see how much memory is actually in use, and how much is just allocated from the OS. -- Bill K. -Original Message- From: Ralph Einfeldt [mailto:[EMAIL PROTECTED]] Sent: Thursday, May 03, 2001 5:51 AM To: '[EMAIL PROTECTED]' Subject: AW: Memory usage That your finalize method is called, doesn't mean that the garbage collector has released your objects. The only way to be shure that this happens, is to explicitly run System.gc(). Otherwise it's up to the VM when it will free the memory. (Sun's JDK per default only releases memory if otherwise an OutOfMemoryError would occur, so unless you reach this border the VM will constanly grow) See also the options for the JVM: -verbose:gc (Any VM) -Xincgc (Sun SDK 1.3.*) -Xms (Sun + IBM) -Xmx (Sun + IBM) -Ursprüngliche Nachricht- Von: Garry De Toffoli [mailto:[EMAIL PROTECTED]] Gesendet: Donnerstag, 3. Mai 2001 14:34 An: [EMAIL PROTECTED] Betreff: Memory usage snip/ I have in trouble with the memory usage with Tomcat 3.21, WinNt 2000 and Jdk 1.3 of Sun. the problem is that any operation does not release the memory occuped; to control the memory usage I use the Task Manager; when Tomcat start, the memory used from the process Java is of 9608 K; when I request a Jsp page that has an error, like a variable not declared, the memory used is 11868K; if I wait for 1 ay also, this value does not change, so the memory used is not released, running a correct Jsp page, the memory used increase, and this is not released yet; I have written a log on the finalize method of my class, and this is called, so the garbage collector release all my object. This behavoir is normal? Probably changing the version of Tomcat this problem may be corrected. snip/
Re: Memory usage
On Thu, 3 May 2001, Garry De Toffoli wrote: | What do you think about this? How's the long run behaviour? It might be that tomcat is initializing itself (creates servlets and the like) as you go along, and that after some time things will even out and go up and down just a little... -- Mvh, Endre
RE: Memory usage
That your finalize method is called, doesn't mean that the garbage collector has released your objects. The only way to be shure that this happens, is to explicitly run System.gc(). Even that's not sufficient: it just suggests to the VM that garbage-collecting might be a good idea right now. Any actual garbage collection would take place later, in another thread. And, even when it does happen, that doesn't mean all the memory will necessarily be released to the OS: the VM will hold on to some so that it won't need to go back to the OS on the next allocation. You might want to get a memory profiler (like JProbe) and see where the memory is going. At the very least, try doing something like, Runtime rt = Runtime.getRuntime(); System.err.println(Free=+rt.freeMemory()+, total=+rt.totalMemory()); often, to see how much memory is actually in use, and how much is just allocated from the OS. -- Bill K. -Original Message- From: Ralph Einfeldt [mailto:[EMAIL PROTECTED]] Sent: Thursday, May 03, 2001 5:51 AM To: '[EMAIL PROTECTED]' Subject: AW: Memory usage That your finalize method is called, doesn't mean that the garbage collector has released your objects. The only way to be shure that this happens, is to explicitly run System.gc(). Otherwise it's up to the VM when it will free the memory. (Sun's JDK per default only releases memory if otherwise an OutOfMemoryError would occur, so unless you reach this border the VM will constanly grow) See also the options for the JVM: -verbose:gc (Any VM) -Xincgc (Sun SDK 1.3.*) -Xms (Sun + IBM) -Xmx (Sun + IBM) -Ursprüngliche Nachricht- Von: Garry De Toffoli [mailto:[EMAIL PROTECTED]] Gesendet: Donnerstag, 3. Mai 2001 14:34 An: [EMAIL PROTECTED] Betreff: Memory usage snip/ I have in trouble with the memory usage with Tomcat 3.21, WinNt 2000 and Jdk 1.3 of Sun. the problem is that any operation does not release the memory occuped; to control the memory usage I use the Task Manager; when Tomcat start, the memory used from the process Java is of 9608 K; when I request a Jsp page that has an error, like a variable not declared, the memory used is 11868K; if I wait for 1 ay also, this value does not change, so the memory used is not released, running a correct Jsp page, the memory used increase, and this is not released yet; I have written a log on the finalize method of my class, and this is called, so the garbage collector release all my object. This behavoir is normal? Probably changing the version of Tomcat this problem may be corrected. snip/
Re: Memory usage
Hei, i had the the error with Tomcat 3.2.2b2 and I've started the VM with -verbose:gc, so it shows me if the Garbage Collector will work. his Work was Ok, but doesn't release the memory. I have change ther Version of TC to 3.2.2b3 and the memory rising has stopped, and he gives memory back after using ! So try the TC3.2.2b3 or b4 Greetings, Wolle Garry De Toffoli wrote: Hi to all, I have in trouble with the memory usage with Tomcat 3.21, on WinNt 2000 and Jdk 1.3 of Sun. the problem is that any operation does not release the memory occuped; to control the memory usage I use the Task Manager; when Tomcat start, the memory used from the process Java is of 9608 K; when I request a Jsp page that has an error, like a variable not declared, the memory used is 11868K; if I wait for 1 ay also, this value does not change, so the memory used is not released, running a correct Jsp page, the memory used increase, and this is not released yet; I have written a log on the finalize method of my class, and this is called, so the garbage collector release all my object. This behavoir is normal? Probably changing the version of Tomcat this problem may be corrected. What do you think about this? Thank you.
RE: Memory usage
Correct me if I'm wrong. If for instance I want a bean removed knowing that System.gc() does not happen immediately, would setting the bean equal to null force the bean to be removed from memory right away and not have to rely on the garbage collection to eventually take place? Mark -Original Message- From: William Kaufman [mailto:[EMAIL PROTECTED]] Sent: Thursday, May 03, 2001 10:07 AM To: '[EMAIL PROTECTED]' Subject:RE: Memory usage That your finalize method is called, doesn't mean that the garbage collector has released your objects. The only way to be shure that this happens, is to explicitly run System.gc(). Even that's not sufficient: it just suggests to the VM that garbage-collecting might be a good idea right now. Any actual garbage collection would take place later, in another thread. And, even when it does happen, that doesn't mean all the memory will necessarily be released to the OS: the VM will hold on to some so that it won't need to go back to the OS on the next allocation. You might want to get a memory profiler (like JProbe) and see where the memory is going. At the very least, try doing something like, Runtime rt = Runtime.getRuntime(); System.err.println(Free=+rt.freeMemory()+, total=+rt.totalMemory()); often, to see how much memory is actually in use, and how much is just allocated from the OS. -- Bill K. -Original Message- From: Ralph Einfeldt [mailto:[EMAIL PROTECTED]] Sent: Thursday, May 03, 2001 5:51 AM To: '[EMAIL PROTECTED]' Subject: AW: Memory usage That your finalize method is called, doesn't mean that the garbage collector has released your objects. The only way to be shure that this happens, is to explicitly run System.gc(). Otherwise it's up to the VM when it will free the memory. (Sun's JDK per default only releases memory if otherwise an OutOfMemoryError would occur, so unless you reach this border the VM will constanly grow) See also the options for the JVM: -verbose:gc (Any VM) -Xincgc (Sun SDK 1.3.*) -Xms (Sun + IBM) -Xmx (Sun + IBM) -Ursprüngliche Nachricht- Von: Garry De Toffoli [mailto:[EMAIL PROTECTED]] Gesendet: Donnerstag, 3. Mai 2001 14:34 An: [EMAIL PROTECTED] Betreff: Memory usage snip/ I have in trouble with the memory usage with Tomcat 3.21, WinNt 2000 and Jdk 1.3 of Sun. the problem is that any operation does not release the memory occuped; to control the memory usage I use the Task Manager; when Tomcat start, the memory used from the process Java is of 9608 K; when I request a Jsp page that has an error, like a variable not declared, the memory used is 11868K; if I wait for 1 ay also, this value does not change, so the memory used is not released, running a correct Jsp page, the memory used increase, and this is not released yet; I have written a log on the finalize method of my class, and this is called, so the garbage collector release all my object. This behavoir is normal? Probably changing the version of Tomcat this problem may be corrected. snip/
RE: Memory usage
setting the bean to null just marks the object as ready to be collected calling System.gc() requests to the vm when you are ready, please do your stuff. But gc only occurs when nothing else is happening ... it is a LOW priority thread. So as long as you have requests, GC will probably not happen but, this is vm implementation dependant ... so maybe it will :) depends on the vendor. -Original Message- From: Jurrius, Mark [mailto:[EMAIL PROTECTED]] Sent: Thursday, May 03, 2001 11:43 AM To: [EMAIL PROTECTED] Subject: RE: Memory usage Correct me if I'm wrong. If for instance I want a bean removed knowing that System.gc() does not happen immediately, would setting the bean equal to null force the bean to be removed from memory right away and not have to rely on the garbage collection to eventually take place? Mark -Original Message- From: William Kaufman [mailto:[EMAIL PROTECTED]] Sent: Thursday, May 03, 2001 10:07 AM To: '[EMAIL PROTECTED]' Subject: RE: Memory usage That your finalize method is called, doesn't mean that the garbage collector has released your objects. The only way to be shure that this happens, is to explicitly run System.gc(). Even that's not sufficient: it just suggests to the VM that garbage-collecting might be a good idea right now. Any actual garbage collection would take place later, in another thread. And, even when it does happen, that doesn't mean all the memory will necessarily be released to the OS: the VM will hold on to some so that it won't need to go back to the OS on the next allocation. You might want to get a memory profiler (like JProbe) and see where the memory is going. At the very least, try doing something like, Runtime rt = Runtime.getRuntime(); System.err.println(Free=+rt.freeMemory()+, total=+rt.totalMemory()); often, to see how much memory is actually in use, and how much is just allocated from the OS. -- Bill K. -Original Message- From: Ralph Einfeldt [mailto:[EMAIL PROTECTED]] Sent: Thursday, May 03, 2001 5:51 AM To: '[EMAIL PROTECTED]' Subject: AW: Memory usage That your finalize method is called, doesn't mean that the garbage collector has released your objects. The only way to be shure that this happens, is to explicitly run System.gc(). Otherwise it's up to the VM when it will free the memory. (Sun's JDK per default only releases memory if otherwise an OutOfMemoryError would occur, so unless you reach this border the VM will constanly grow) See also the options for the JVM: -verbose:gc (Any VM) -Xincgc (Sun SDK 1.3.*) -Xms (Sun + IBM) -Xmx (Sun + IBM) -Ursprüngliche Nachricht- Von: Garry De Toffoli [mailto:[EMAIL PROTECTED]] Gesendet: Donnerstag, 3. Mai 2001 14:34 An: [EMAIL PROTECTED] Betreff: Memory usage snip/ I have in trouble with the memory usage with Tomcat 3.21, WinNt 2000 and Jdk 1.3 of Sun. the problem is that any operation does not release the memory occuped; to control the memory usage I use the Task Manager; when Tomcat start, the memory used from the process Java is of 9608 K; when I request a Jsp page that has an error, like a variable not declared, the memory used is 11868K; if I wait for 1 ay also, this value does not change, so the memory used is not released, running a correct Jsp page, the memory used increase, and this is not released yet; I have written a log on the finalize method of my class, and this is called, so the garbage collector release all my object. This behavoir is normal? Probably changing the version of Tomcat this problem may be corrected. snip/
RE: Memory usage
Nope. If you _didn't_ null out the reference, you're guaranteed that it _won't_ get garbage-collected; but if you _do_ null it out, you're only making it _available_ for garbage collection. The actual garbage collection only happens when the VM runs out of memory, or some unspecified time after calling System.gc(). Or, when the VM just plain wants to--the JLS isn't specific about this. -- Bill K. -Original Message- From: Jurrius, Mark [mailto:[EMAIL PROTECTED]] Sent: Thursday, May 03, 2001 7:43 AM To: [EMAIL PROTECTED] Subject: RE: Memory usage Correct me if I'm wrong. If for instance I want a bean removed knowing that System.gc() does not happen immediately, would setting the bean equal to null force the bean to be removed from memory right away and not have to rely on the garbage collection to eventually take place? Mark -Original Message- From: William Kaufman [mailto:[EMAIL PROTECTED]] Sent: Thursday, May 03, 2001 10:07 AM To: '[EMAIL PROTECTED]' Subject: RE: Memory usage That your finalize method is called, doesn't mean that the garbage collector has released your objects. The only way to be shure that this happens, is to explicitly run System.gc(). Even that's not sufficient: it just suggests to the VM that garbage-collecting might be a good idea right now. Any actual garbage collection would take place later, in another thread. And, even when it does happen, that doesn't mean all the memory will necessarily be released to the OS: the VM will hold on to some so that it won't need to go back to the OS on the next allocation. You might want to get a memory profiler (like JProbe) and see where the memory is going. At the very least, try doing something like, Runtime rt = Runtime.getRuntime(); System.err.println(Free=+rt.freeMemory()+, total=+rt.totalMemory()); often, to see how much memory is actually in use, and how much is just allocated from the OS. -- Bill K. -Original Message- From: Ralph Einfeldt [mailto:[EMAIL PROTECTED]] Sent: Thursday, May 03, 2001 5:51 AM To: '[EMAIL PROTECTED]' Subject: AW: Memory usage That your finalize method is called, doesn't mean that the garbage collector has released your objects. The only way to be shure that this happens, is to explicitly run System.gc(). Otherwise it's up to the VM when it will free the memory. (Sun's JDK per default only releases memory if otherwise an OutOfMemoryError would occur, so unless you reach this border the VM will constanly grow) See also the options for the JVM: -verbose:gc (Any VM) -Xincgc (Sun SDK 1.3.*) -Xms (Sun + IBM) -Xmx (Sun + IBM) -Ursprüngliche Nachricht- Von: Garry De Toffoli [mailto:[EMAIL PROTECTED]] Gesendet: Donnerstag, 3. Mai 2001 14:34 An: [EMAIL PROTECTED] Betreff: Memory usage snip/ I have in trouble with the memory usage with Tomcat 3.21, WinNt 2000 and Jdk 1.3 of Sun. the problem is that any operation does not release the memory occuped; to control the memory usage I use the Task Manager; when Tomcat start, the memory used from the process Java is of 9608 K; when I request a Jsp page that has an error, like a variable not declared, the memory used is 11868K; if I wait for 1 ay also, this value does not change, so the memory used is not released, running a correct Jsp page, the memory used increase, and this is not released yet; I have written a log on the finalize method of my class, and this is called, so the garbage collector release all my object. This behavoir is normal? Probably changing the version of Tomcat this problem may be corrected. snip/
Re: Memory usage
Hi Mark! I don't think so. When you set a bean equal to null, you just erase a reference to it. Any other references left around would make it linger in memory, and there might be a few. Are you talking about EJBs? Anyway, if you set to null the only existing reference, you'll have to wait for the next gc cycle. If you call System.gc() explicitly, you're forcing this cycle and the object might go away. Un saludo, Alex. Jurrius, Mark wrote: Correct me if I'm wrong. If for instance I want a bean removed knowing that System.gc() does not happen immediately, would setting the bean equal to null force the bean to be removed from memory right away and not have to rely on the garbage collection to eventually take place? Mark -Original Message- From: William Kaufman [mailto:[EMAIL PROTECTED]] Sent: Thursday, May 03, 2001 10:07 AM To: '[EMAIL PROTECTED]' Subject:RE: Memory usage That your finalize method is called, doesn't mean that the garbage collector has released your objects. The only way to be shure that this happens, is to explicitly run System.gc(). Even that's not sufficient: it just suggests to the VM that garbage-collecting might be a good idea right now. Any actual garbage collection would take place later, in another thread. And, even when it does happen, that doesn't mean all the memory will necessarily be released to the OS: the VM will hold on to some so that it won't need to go back to the OS on the next allocation. You might want to get a memory profiler (like JProbe) and see where the memory is going. At the very least, try doing something like, Runtime rt = Runtime.getRuntime(); System.err.println(Free=+rt.freeMemory()+, total=+rt.totalMemory()); often, to see how much memory is actually in use, and how much is just allocated from the OS. -- Bill K. -Original Message- From: Ralph Einfeldt [mailto:[EMAIL PROTECTED]] Sent: Thursday, May 03, 2001 5:51 AM To: '[EMAIL PROTECTED]' Subject: AW: Memory usage That your finalize method is called, doesn't mean that the garbage collector has released your objects. The only way to be shure that this happens, is to explicitly run System.gc(). Otherwise it's up to the VM when it will free the memory. (Sun's JDK per default only releases memory if otherwise an OutOfMemoryError would occur, so unless you reach this border the VM will constanly grow) See also the options for the JVM: -verbose:gc (Any VM) -Xincgc (Sun SDK 1.3.*) -Xms (Sun + IBM) -Xmx (Sun + IBM) -Ursprüngliche Nachricht- Von: Garry De Toffoli [mailto:[EMAIL PROTECTED]] Gesendet: Donnerstag, 3. Mai 2001 14:34 An: [EMAIL PROTECTED] Betreff: Memory usage snip/ I have in trouble with the memory usage with Tomcat 3.21, WinNt 2000 and Jdk 1.3 of Sun. the problem is that any operation does not release the memory occuped; to control the memory usage I use the Task Manager; when Tomcat start, the memory used from the process Java is of 9608 K; when I request a Jsp page that has an error, like a variable not declared, the memory used is 11868K; if I wait for 1 ay also, this value does not change, so the memory used is not released, running a correct Jsp page, the memory used increase, and this is not released yet; I have written a log on the finalize method of my class, and this is called, so the garbage collector release all my object. This behavoir is normal? Probably changing the version of Tomcat this problem may be corrected. snip/
Re: Memory usage
Hello, i have tested the Sun VM JDK1.30_02 as Server VM. When I start my servlets and use the VM with the option -verbose:gc, it shows, that the gc will do his work ervery second when you work with the VM. Sometimes (?) it makes a FULL GC, that gives more memory free, but I don't know exactly the difference (perhaps it will call finalize first). I have also testet to make explizit calls like System.gc() or System.runFinalization(), it becomes no difference to the memory usage without that call. Set the TOMCAT_OPTS variable to -verbose:gc and you'll see. Btw you could set the default start option of the SUN VM in /jre/jvm.cfg. Greetings, Wolle William Kaufman wrote: Nope. If you _didn't_ null out the reference, you're guaranteed that it _won't_ get garbage-collected; but if you _do_ null it out, you're only making it _available_ for garbage collection. The actual garbage collection only happens when the VM runs out of memory, or some unspecified time after calling System.gc(). Or, when the VM just plain wants to--the JLS isn't specific about this. -- Bill K. -Original Message- From: Jurrius, Mark [mailto:[EMAIL PROTECTED]] Sent: Thursday, May 03, 2001 7:43 AM To: [EMAIL PROTECTED] Subject: RE: Memory usage Correct me if I'm wrong. If for instance I want a bean removed knowing that System.gc() does not happen immediately, would setting the bean equal to null force the bean to be removed from memory right away and not have to rely on the garbage collection to eventually take place? Mark -Original Message- From: William Kaufman [mailto:[EMAIL PROTECTED]] Sent: Thursday, May 03, 2001 10:07 AM To: '[EMAIL PROTECTED]' Subject: RE: Memory usage That your finalize method is called, doesn't mean that the garbage collector has released your objects. The only way to be shure that this happens, is to explicitly run System.gc(). Even that's not sufficient: it just suggests to the VM that garbage-collecting might be a good idea right now. Any actual garbage collection would take place later, in another thread. And, even when it does happen, that doesn't mean all the memory will necessarily be released to the OS: the VM will hold on to some so that it won't need to go back to the OS on the next allocation. You might want to get a memory profiler (like JProbe) and see where the memory is going. At the very least, try doing something like, Runtime rt = Runtime.getRuntime(); System.err.println(Free=+rt.freeMemory()+, total=+rt.totalMemory()); often, to see how much memory is actually in use, and how much is just allocated from the OS. -- Bill K. -Original Message- From: Ralph Einfeldt [mailto:[EMAIL PROTECTED]] Sent: Thursday, May 03, 2001 5:51 AM To: '[EMAIL PROTECTED]' Subject: AW: Memory usage That your finalize method is called, doesn't mean that the garbage collector has released your objects. The only way to be shure that this happens, is to explicitly run System.gc(). Otherwise it's up to the VM when it will free the memory. (Sun's JDK per default only releases memory if otherwise an OutOfMemoryError would occur, so unless you reach this border the VM will constanly grow) See also the options for the JVM: -verbose:gc (Any VM) -Xincgc (Sun SDK 1.3.*) -Xms (Sun + IBM) -Xmx (Sun + IBM) -Ursprüngliche Nachricht- Von: Garry De Toffoli [mailto:[EMAIL PROTECTED]] Gesendet: Donnerstag, 3. Mai 2001 14:34 An: [EMAIL PROTECTED] Betreff: Memory usage snip/ I have in trouble with the memory usage with Tomcat 3.21, WinNt 2000 and Jdk 1.3 of Sun. the problem is that any operation does not release the memory occuped; to control the memory usage I use the Task Manager; when Tomcat start, the memory used from the process Java is of 9608 K; when I request a Jsp page that has an error, like a variable not declared, the memory used is 11868K; if I wait for 1 ay also, this value does not change, so the memory used is not released, running a correct Jsp page, the memory used increase, and this is not released yet; I have written a log on the finalize method of my class, and this is called, so the garbage collector release all my object. This behavoir is normal? Probably changing the version of Tomcat this problem may be corrected. snip/
RE: Memory usage
Actually, setting a Java object to null (assuming that there are no other references to that object) is the normal way of telling the VM that the object may be garbage collected. The garbage collection takes place asynchronously however and at the discretion of the VM in a background thread. The act of deleting all references to an object does not free the memory associated with the object until the garbage collector cleans up the object. -Jamey -Original Message- From: Jurrius, Mark [mailto:[EMAIL PROTECTED]] Sent: Thursday, May 03, 2001 7:43 AM To: [EMAIL PROTECTED] Subject: RE: Memory usage Correct me if I'm wrong. If for instance I want a bean removed knowing that System.gc() does not happen immediately, would setting the bean equal to null force the bean to be removed from memory right away and not have to rely on the garbage collection to eventually take place? Mark -Original Message- From: William Kaufman [mailto:[EMAIL PROTECTED]] Sent: Thursday, May 03, 2001 10:07 AM To: '[EMAIL PROTECTED]' Subject:RE: Memory usage That your finalize method is called, doesn't mean that the garbage collector has released your objects. The only way to be shure that this happens, is to explicitly run System.gc(). Even that's not sufficient: it just suggests to the VM that garbage-collecting might be a good idea right now. Any actual garbage collection would take place later, in another thread. And, even when it does happen, that doesn't mean all the memory will necessarily be released to the OS: the VM will hold on to some so that it won't need to go back to the OS on the next allocation. You might want to get a memory profiler (like JProbe) and see where the memory is going. At the very least, try doing something like, Runtime rt = Runtime.getRuntime(); System.err.println(Free=+rt.freeMemory()+, total=+rt.totalMemory()); often, to see how much memory is actually in use, and how much is just allocated from the OS. -- Bill K. -Original Message- From: Ralph Einfeldt [mailto:[EMAIL PROTECTED]] Sent: Thursday, May 03, 2001 5:51 AM To: '[EMAIL PROTECTED]' Subject: AW: Memory usage That your finalize method is called, doesn't mean that the garbage collector has released your objects. The only way to be shure that this happens, is to explicitly run System.gc(). Otherwise it's up to the VM when it will free the memory. (Sun's JDK per default only releases memory if otherwise an OutOfMemoryError would occur, so unless you reach this border the VM will constanly grow) See also the options for the JVM: -verbose:gc (Any VM) -Xincgc (Sun SDK 1.3.*) -Xms (Sun + IBM) -Xmx (Sun + IBM) -Ursprüngliche Nachricht- Von: Garry De Toffoli [mailto:[EMAIL PROTECTED]] Gesendet: Donnerstag, 3. Mai 2001 14:34 An: [EMAIL PROTECTED] Betreff: Memory usage snip/ I have in trouble with the memory usage with Tomcat 3.21, WinNt 2000 and Jdk 1.3 of Sun. the problem is that any operation does not release the memory occuped; to control the memory usage I use the Task Manager; when Tomcat start, the memory used from the process Java is of 9608 K; when I request a Jsp page that has an error, like a variable not declared, the memory used is 11868K; if I wait for 1 ay also, this value does not change, so the memory used is not released, running a correct Jsp page, the memory used increase, and this is not released yet; I have written a log on the finalize method of my class, and this is called, so the garbage collector release all my object. This behavoir is normal? Probably changing the version of Tomcat this problem may be corrected. snip/
RE: Memory usage
System.gc(); will force the garbage collector to run. if your objects doesn't have any references to it, it will get collected. Filip ~ Namaste - I bow to the divine in you ~ Filip Hanik Software Architect [EMAIL PROTECTED] www.filip.net -Original Message- From: Courtney, James [mailto:[EMAIL PROTECTED]] Sent: Thursday, May 03, 2001 11:35 AM To: '[EMAIL PROTECTED]' Cc: '[EMAIL PROTECTED]' Subject: RE: Memory usage Actually, setting a Java object to null (assuming that there are no other references to that object) is the normal way of telling the VM that the object may be garbage collected. The garbage collection takes place asynchronously however and at the discretion of the VM in a background thread. The act of deleting all references to an object does not free the memory associated with the object until the garbage collector cleans up the object. -Jamey -Original Message- From: Jurrius, Mark [mailto:[EMAIL PROTECTED]] Sent: Thursday, May 03, 2001 7:43 AM To: [EMAIL PROTECTED] Subject: RE: Memory usage Correct me if I'm wrong. If for instance I want a bean removed knowing that System.gc() does not happen immediately, would setting the bean equal to null force the bean to be removed from memory right away and not have to rely on the garbage collection to eventually take place? Mark -Original Message- From: William Kaufman [mailto:[EMAIL PROTECTED]] Sent: Thursday, May 03, 2001 10:07 AM To: '[EMAIL PROTECTED]' Subject: RE: Memory usage That your finalize method is called, doesn't mean that the garbage collector has released your objects. The only way to be shure that this happens, is to explicitly run System.gc(). Even that's not sufficient: it just suggests to the VM that garbage-collecting might be a good idea right now. Any actual garbage collection would take place later, in another thread. And, even when it does happen, that doesn't mean all the memory will necessarily be released to the OS: the VM will hold on to some so that it won't need to go back to the OS on the next allocation. You might want to get a memory profiler (like JProbe) and see where the memory is going. At the very least, try doing something like, Runtime rt = Runtime.getRuntime(); System.err.println(Free=+rt.freeMemory()+, total=+rt.totalMemory()); often, to see how much memory is actually in use, and how much is just allocated from the OS. -- Bill K. -Original Message- From: Ralph Einfeldt [mailto:[EMAIL PROTECTED]] Sent: Thursday, May 03, 2001 5:51 AM To: '[EMAIL PROTECTED]' Subject: AW: Memory usage That your finalize method is called, doesn't mean that the garbage collector has released your objects. The only way to be shure that this happens, is to explicitly run System.gc(). Otherwise it's up to the VM when it will free the memory. (Sun's JDK per default only releases memory if otherwise an OutOfMemoryError would occur, so unless you reach this border the VM will constanly grow) See also the options for the JVM: -verbose:gc (Any VM) -Xincgc (Sun SDK 1.3.*) -Xms (Sun + IBM) -Xmx (Sun + IBM) -Ursprüngliche Nachricht- Von: Garry De Toffoli [mailto:[EMAIL PROTECTED]] Gesendet: Donnerstag, 3. Mai 2001 14:34 An: [EMAIL PROTECTED] Betreff: Memory usage snip/ I have in trouble with the memory usage with Tomcat 3.21, WinNt 2000 and Jdk 1.3 of Sun. the problem is that any operation does not release the memory occuped; to control the memory usage I use the Task Manager; when Tomcat start, the memory used from the process Java is of 9608 K; when I request a Jsp page that has an error, like a variable not declared, the memory used is 11868K; if I wait for 1 ay also, this value does not change, so the memory used is not released, running a correct Jsp page, the memory used increase, and this is not released yet; I have written a log on the finalize method of my class, and this is called, so the garbage collector release all my object. This behavoir is normal? Probably changing the version of Tomcat this problem may be corrected. snip/