What I am finding is this. 1)I startup tomcat. At context initialized, before any data is added to context, I take a memory heap snapshot 2) After login to our app, after memory has been added to context and session, I take a snapshot 3) At logout BEFORE memory has been removed from session and context, I take a snapshot 4) At context destroyed after all memory is wiped from context and session I take a snapshot
What I am seeing is heap size goes up in 1 and 2 and 3, then back down at 4. BUT, it does not return back down very far. In fact, it does not even go down to the heap size in snapshot 2. When I look at what is in Context and session, I find that there is no context or session for the snapshot taken during context startup (makes sense), and that there is no context during the snapshot taken in context destroyed - does not make sense as the context has not been destroyed till the end of this function???? There are also 2 sessions remaining at this point. Is this because of a session pool help by Tomcat, or what - by the time of contextDestroyed, I would have expected all sessions to be gone - especially since I already called and processed session.invalidate.??? Furthermore, when I compare snapshots 2 and 3, I find that org.apache.catalina.session.StandardSession for snap 2 is 6.36 megs, of which the attributes member is only 82 bytes (about what we added). At snap 3, the StandardSession is 8.44 megs, but the attribute member is still 82 bytes. It appears that the standard session stuff outside of attributes contains a lot of overhead. What is that stuff? why does it seem to grow during processing if the only place we are adding data is to session attributes? Is there a potential for a memory leak there? ALSO in looking at the snapshots, in every one, java.lang.string increased. Any ideas on how I can determine which of these strings (if any) may represent a memory leak in our system, and where the leak is occuring from? -----Original Message----- From: Filip Hanik - Dev Lists [mailto:[EMAIL PROTECTED] Sent: Wednesday, June 21, 2006 9:27 AM To: Tomcat Users List Subject: Re: Question about StandardSession and ApplicationContext the StandardSession is not big, I would go back and guess it is your application. The key is to read the profiling data correctly, that's where I would start. Tomcat has been optimized for memory and cpu usage, so 11MB session objects would have been discovered early on. John McClain wrote: > I am profiling our application in jprofiler. I have noticed that the deep > size of StandardSession object for each user is VERY large - ~ 11+mb. Yet I > know that we are not adding that much data. Where is all that memory coming > from? Is it truly non static data that is overhead for each session, or is > it static data that each session points to? > > Does anyone out there have a strategy for finding memory leaks in a Tomcat > application? I am not finding ours. > > John McClain > Senior Software Engineer > TCS Healthcare > [EMAIL PROTECTED] > (530)886-1700x235 > "Skepticism is the first step toward truth" > > > --------------------------------------------------------------------- > To start a new topic, e-mail: users@tomcat.apache.org > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > > -- Filip Hanik --------------------------------------------------------------------- To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
