RE: Tag Handler pool eating up Memory (and enablePooling is set to false)
Chris: Yeah, it's possible (and probable) that the TagHandlerPool maintains a reference back to the ServletContext in which it lives. That might kew your results. I'm sure that the TagHandlerPool isn't actually taking up that much memory. This is strange. When I created a heap dump from my server just now, it does not have any instances of TagHandlerPool in the heap dump. That is what I expected before, but I still had them in my last dump. Do you have any of your own tag libraries, or are you using only 3rd-party taglibs? If you are using your own, check to see if you are holding on to references or something like (anything like shared objects between tags -- that kind of thing). We are not using any 3rd party tag libraries. We are using our our tag library. I will look into that. If you have a profiler handy (something more robust that the heap dumper), check to see how many instances of various types there are. For example, if you are using org.foo.bar.taglib, then filter the object list by org.foo.bar.taglib and take a look at how many instances there are. If you find that there are thousands of references to tag handlers, then something is probably wrong with Tomcat. Otherwise, several hundred references doesn't sound horrible. It's possible that they haven't been GC'd yet. Doing a quick grep on my summary results from the new heap dump, I get this result: 60256,1076,com/slsideas/pagegen/tags/SetPropertyTag 31296,652,com/slsideas/pagegen/tags/ValueTag 23088,481,com/slsideas/pagegen/tags/ProcessTag 13008,271,com/slsideas/pagegen/tags/IfNotNullTag 9888,206,com/slsideas/pagegen/tags/IfNullTag 9600,200,com/slsideas/pagegen/tags/IfEqTag 5616,117,com/slsideas/pagegen/tags/IfExistTag 4992,104,com/slsideas/pagegen/tags/IfNotEqTag 3216,67,com/slsideas/pagegen/tags/IncludeTag 3136,49,com/slsideas/pagegen/tags/LoopTag 960,20,com/slsideas/pagegen/tags/IfNotExistTag 608,2,class com/slsideas/pagegen/tags/ValueTag 608,2,class com/slsideas/pagegen/tags/SetPropertyTag$Converter 608,2,class com/slsideas/pagegen/tags/SetPropertyTag 608,2,class com/slsideas/pagegen/tags/ProcessTag 608,2,class com/slsideas/pagegen/tags/IncludeTag 608,2,class com/slsideas/pagegen/tags/IfNotExistTag 608,2,class com/slsideas/pagegen/tags/IfExistTag 608,2,class com/slsideas/pagegen/tags/BaseTag 304,1,class com/slsideas/pagegen/tags/LoopTag 304,1,class com/slsideas/pagegen/tags/IfNullTag 304,1,class com/slsideas/pagegen/tags/IfNotNullTag 304,1,class com/slsideas/pagegen/tags/IfNotEqTag 304,1,class com/slsideas/pagegen/tags/IfLoopTag 304,1,class com/slsideas/pagegen/tags/IfGreaterThanTag 304,1,class com/slsideas/pagegen/tags/IfGreaterOrEqTag 304,1,class com/slsideas/pagegen/tags/IfEqTag 304,1,class com/slsideas/pagegen/tags/EscapeValueTag 56,1,com/slsideas/pagegen/tags/IfLoopTag The first column is the total bytes held by the instance inself (not including references), the second column is the number of instances that were present in the heap dump, and the last column is the type of the object. I find it very hard to believe that we have over 2500 active instances of our tags. This seems to imply they are not being garbage collected. I also noticed that you are using JDK 1.4.1. I've heard that this version (it might only be the Sun distro -- can someone confirm?) has an implementation of StringBuffer that has a terrible memory leak. You might want to consider upgrading to 1.4.2 if that's possible. I ran some code to count all of the instances of java/lang/StringBuffer and the total bytes they hold both in themselves and their references. I got 2,925,512 bytes in 15,914 instances of java/lang/StringBuffer. The heap dump shows 174,740,832 total bytes used in 892,512 total instances. I don't belive the StringBuffer is the cause of my problems. Thanks, Neil. -- Neil Aggarwal, JAMM Consulting, (972)612-6056, www.JAMMConsulting.com FREE! Valuable info on how your business can reduce operating costs by 17% or more in 6 months or less! = http://newsletter.JAMMConsulting.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tag Handler pool eating up Memory (and enablePooling is set to false)
Neil, This is strange. When I created a heap dump from my server just now, it does not have any instances of TagHandlerPool in the heap dump. That is what I expected before, but I still had them in my last dump. That is weird. However, you still have a bunch of tag handler instances, I see... Doing a quick grep on my summary results from the new heap dump, I get this result: 60256,1076,com/slsideas/pagegen/tags/SetPropertyTag 31296,652,com/slsideas/pagegen/tags/ValueTag The first column is the total bytes held by the instance inself (not including references), the second column is the number of instances that were present in the heap dump, and the last column is the type of the object. So you have 60k in SetPropertyTag objects? If you use them a lot (without pooling), then you'll get a lot of them on the heap at any given time. Can you observe that the number keeps going up, and never goes down? I find it very hard to believe that we have over 2500 active instances of our tags. This seems to imply they are not being garbage collected. Not necessarily. It might just be that they are taking a while to get GC'd. Again, what do you observe over time? I don't belive the StringBuffer is the cause of my problems. Okay, that's good. -chris - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Tag Handler pool eating up Memory (and enablePooling is set to false)
are you sure this is a tomcat reference holding on to it? it could be one of your classes as well, you need to run it through a memory profile in order to find out Filip -Original Message- From: Neil Aggarwal [mailto:[EMAIL PROTECTED] Sent: Monday, December 01, 2003 2:53 PM To: 'Tomcat-User' Subject: Tag Handler pool eating up Memory (and enablePooling is set to false) Hello: We have several tomcat servers running an application. The servers slow down after a few hours of uptime. Looking at the memory usage on the servers, we noticed that the servers seem to be accumulating memory and finally they slow down when the memory utilization becomes high. We are using the IBM JDK 1.4.1 SR1 with Tomcat 4.1.24 on RedHat 9. Using the heapdump utility from the IBM JDK, I generated a heap dump from one of the servers after it had been up for a while. From that output, I see these pieces of infromation: There were a total of 509,235 objects in memory taking up 67,992,688 bytes. There were 436 instances of org/apache/jasper/runtime/TagHandlerPool. Tracing all of the references from these TagHandlerPool object, they reference a total of 65,010,600 bytes. This means that almost 97% of the memory usage of Tomcat is being referenced from the TagHandlerPool objects. I have enablePooling set to false in the Tomcat's web.xml in the conf directory. It seems that the enablePooling setting is not preventing Tomcat from pooling the tag handlers and they are referencing a lot of memory. Does that setting work in Tomcat 4.1.24? Is there any other reason why Tomcat would behave this way? Thanks, Neil -- Neil Aggarwal, JAMM Consulting, (972)612-6056, www.JAMMConsulting.com FREE! Valuable info on how your business can reduce operating costs by 17% or more in 6 months or less! = http://newsletter.JAMMConsulting.com - 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: Tag Handler pool eating up Memory (and enablePooling is set to false)
Neil, are you sure this is a tomcat reference holding on to it? it could be one of your classes as well, you need to run it through a memory profile in order to find out Yeah, it's possible (and probable) that the TagHandlerPool maintains a reference back to the ServletContext in which it lives. That might kew your results. I'm sure that the TagHandlerPool isn't actually taking up that much memory. Do you have any of your own tag libraries, or are you using only 3rd-party taglibs? If you are using your own, check to see if you are holding on to references or something like (anything like shared objects between tags -- that kind of thing). If you are using 3rd-party only, check their bug lists to see if there are memory leaks listed as bugs. If you have a profiler handy (something more robust that the heap dumper), check to see how many instances of various types there are. For example, if you are using org.foo.bar.taglib, then filter the object list by org.foo.bar.taglib and take a look at how many instances there are. If you find that there are thousands of references to tag handlers, then something is probably wrong with Tomcat. Otherwise, several hundred references doesn't sound horrible. It's possible that they haven't been GC'd yet. I also noticed that you are using JDK 1.4.1. I've heard that this version (it might only be the Sun distro -- can someone confirm?) has an implementation of StringBuffer that has a terrible memory leak. You might want to consider upgrading to 1.4.2 if that's possible. Hope that helps. -chris - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Tag Handler pool eating up Memory (and enablePooling is set to false)
Filip: Thanks for the suggestion. I have been profiling it and I don't see any references from our code, but I will keep checking. Thanks, Neil -- Neil Aggarwal, JAMM Consulting, (972)612-6056, www.JAMMConsulting.com FREE! Valuable info on how your business can reduce operating costs by 17% or more in 6 months or less! = http://newsletter.JAMMConsulting.com -Original Message- From: Filip Hanik [mailto:[EMAIL PROTECTED] Sent: Monday, December 01, 2003 6:37 PM To: Tomcat Users List Subject: RE: Tag Handler pool eating up Memory (and enablePooling is set to false) are you sure this is a tomcat reference holding on to it? it could be one of your classes as well, you need to run it through a memory profile in order to find out Filip -Original Message- From: Neil Aggarwal [mailto:[EMAIL PROTECTED] Sent: Monday, December 01, 2003 2:53 PM To: 'Tomcat-User' Subject: Tag Handler pool eating up Memory (and enablePooling is set to false) Hello: We have several tomcat servers running an application. The servers slow down after a few hours of uptime. Looking at the memory usage on the servers, we noticed that the servers seem to be accumulating memory and finally they slow down when the memory utilization becomes high. We are using the IBM JDK 1.4.1 SR1 with Tomcat 4.1.24 on RedHat 9. Using the heapdump utility from the IBM JDK, I generated a heap dump from one of the servers after it had been up for a while. From that output, I see these pieces of infromation: There were a total of 509,235 objects in memory taking up 67,992,688 bytes. There were 436 instances of org/apache/jasper/runtime/TagHandlerPool. Tracing all of the references from these TagHandlerPool object, they reference a total of 65,010,600 bytes. This means that almost 97% of the memory usage of Tomcat is being referenced from the TagHandlerPool objects. I have enablePooling set to false in the Tomcat's web.xml in the conf directory. It seems that the enablePooling setting is not preventing Tomcat from pooling the tag handlers and they are referencing a lot of memory. Does that setting work in Tomcat 4.1.24? Is there any other reason why Tomcat would behave this way? Thanks, Neil -- Neil Aggarwal, JAMM Consulting, (972)612-6056, www.JAMMConsulting.com FREE! Valuable info on how your business can reduce operating costs by 17% or more in 6 months or less! = http://newsletter.JAMMConsulting.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
