>> For Ty's purposes, simply avoid JAR scanning entirely should eliminate >> the heap issues, right? Moving from Tomcat 6 means that JAR scanning >> is not required for correct operation of their application.
> Yes. http://wiki.apache.org/tomcat/HowTo/FasterStartUp has the details > of the configuration required. I might be missing something, if so please correct me, but it seems that there's a huge difference with Tomcat 8, even when JAR scanning is taken out of the picture (jarsToSkip=*). For my test case, Tomcat 8 has a heap size of ~1GB with JAR scanning enabled, and ~600MB with jarsToSkip=*. That's a 40% improvement by disabling JAR scanning, sure, but for comparison, same test case, Tomcat 6's heap is ~20MB while Tomcat 7's (with jarsToSkip=*) is ~70MB. We're still back to a 30x increase in heap utilization from Tomcat 6 to Tomcat 8, and a 10x increase from Tomcat 7 to Tomcat 8, without having JAR scanning in the mix. On Wed, Feb 17, 2016 at 6:14 PM Mark Thomas <ma...@apache.org> wrote: > On 18/02/2016 00:05, Christopher Schultz wrote: > > Mark, > > > > On 2/17/16 5:04 PM, Mark Thomas wrote: > >> On 17/02/2016 11:11, Mark Thomas wrote: > >>> On 16/02/2016 22:07, Ty wrote: > >>>>> Exactly which versions were you using when you ran your > >>>>> tests? > >>>> > >>>> According to my notes: 7.0.59, which should've been the most > >>>> recent version available at the time (about this time last > >>>> year). > >>>> > >>>> To clarify: that was the version we did a heap dump analysis > >>>> of, and noted the memory increase related to Manifest objects. > >>>> The version used for the test procedure in this thread's > >>>> original message -- last performed last week -- was 7.0.67 and > >>>> we did not do a heap analysis of it (only noting that at a > >>>> glance it resulted in approximately the same amount of heap > >>>> increase correlating with JAR scanning as we saw with last > >>>> year's version). > >>> > >>> Thanks for the version info. > >>> > >>> I've started looking at this. The bulk of the memory is used by > >>> JarResourceSet. It is caching a JarFileEntry object for each > >>> class in the JAR. > >>> > >>> I wrote this code but I don't recall why those entries were > >>> retained. I need to look back through svn to figure out what > >>> problem it was solving and then see if I can find a better > >>> solution. > > > >> Quick update. > > > >> There are two separate issues, both triggered by JAR scanning. > > > >> The JarResourceSet issue above accounts for ~50% of a 1GB heap. > >> There is also a WebappClassLoader issue that accounts for ~30% of > >> the same heap. > > > >> The WebappClassLoader issue is the easier to fix. I have fixed this > >> in trunk and am just waiting for the tests to confirm all is well. > >> I plan to back-port this to 8.0.x for the next release. > > > >> The JarResourceSet is going to be trickier. The code is the way it > >> is partly for performance, partly to avoid file locking on Windows. > >> It is going to take a little longer to put together a fix for this > >> one. > > > > For Ty's purposes, simply avoid JAR scanning entirely should eliminate > > the heap issues, right? Moving from Tomcat 6 means that JAR scanning > > is not required for correct operation of their application. > > Yes. http://wiki.apache.org/tomcat/HowTo/FasterStartUp has the details > of the configuration required. > > Mark > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > >
