Hi Anthony Have you turned debug logging on to see what it is picking up as modified?
On Wed, 09 Oct 2019, 22:24 Rhuberg,Anthony, <anthony.rhub...@cerner.com.invalid> wrote: > Thanks for your responses. > > I understand that re-reading the static files is not optimal, but how does > reading files from the jar affect them being reloaded... In Tomcat 7, that > seemed to prevent the jars from being reloaded since the accessTime was > changed; in Tomcat 8, it seems the modified() method uses the file modified > time - not sure what we are doing to cause the modified time to change - > the files on the filesystem are not changing - unless there is something > happening in the classes folder. > > Thanks > > -----Original Message----- > From: Mark Thomas <ma...@apache.org> > Sent: Wednesday, October 09, 2019 3:56 PM > To: users@tomcat.apache.org > Subject: Re: Performance test with Tomcat 9 shows increased cpu/disk usage > because of repeated opening/closing of jars in WEB-INF/lib > > On 09/10/2019 20:08, Rhuberg,Anthony wrote: > > On the other thread: Is this genuine class loading (in which case the > > response below is correct) or is the application reading the .class > files as if they were resources (in which case a different answer applies)? > > Mostly, we are talking about the default class loader; however, the > application does read resources from the jar files - mostly static files > that are stored within the package structure are read (for example: log4j, > property files, other static content). Would this affect the reload of the > jar files? > > If an application was reading the same resource from a JAR over and over > again, that may have a performance impact. Increasing the TTL for cached > resources would probably address that although, arguably, the better > solution in that case would be to fix the app to load it once and cache it. > > > -----Original Message----- > > From: Rhuberg,Anthony > > Sent: Wednesday, October 09, 2019 2:53 PM > > To: Tomcat Users List <users@tomcat.apache.org> > > Subject: RE: Performance test with Tomcat 9 shows increased cpu/disk > > usage because of repeated opening/closing of jars in WEB-INF/lib > > > > Just noticed another thread on this topic: RE: Tomcat discards and > reloads the jar files from the webapps folder. > > > > Setting the Engine attribute backgroundProcessorDelay to 90s does reduce > the open/close cycle of the jars. > > Thanks for the confirmation. > > > The other thread also mentioned a potential configuration to keep the > jars open longer by default. This could be helpful - not sure we need to > close them at all. > > If the JARs aren't closed it can cause file locking issues. We could > include a disable option if we did make the Jar unload frequency > configurable. > > > Alternatively, would there be any gain to 'explode' the jars into class > files on the filesystem? > > Maybe. Best bet it to try it for your app and see. > > Mark > > > > -----Original Message----- > > From: Rhuberg,Anthony <anthony.rhub...@cerner.com.INVALID> > > Sent: Wednesday, October 09, 2019 2:17 PM > > To: users@tomcat.apache.org > > Subject: Performance test with Tomcat 9 shows increased cpu/disk usage > > because of repeated opening/closing of jars in WEB-INF/lib > > > > Background: > > In the last few months we migrated our web application from Tomcat > 7.0.55 to Tomcat 9.0.19 (26). That transition was relatively > straightforward until we reviewed the results of our performance tests. > Those tests showed an increase in CPU usage and disk I/O on our Windows > 2012 server. When we switch back to Tomcat 7, the metrics for CPU/disk > usage were significantly lower (similar to previous tests). > > > > As we investigated the cause of the increase in cpu/disk usage we found > the tomcat process was repeatedly opening and closing the jars of our web > application. The process profile showed all the jars in WEB-INF/lib being > closed and reopened within seconds while the application was processing > requests (and to some extent when quite). Now we are trying to determine > why. > > > > We have a general understanding that the WebappClassLoaderBase.java > implementation changed in Tomcat 8.5. The Tomcat 7 implementation provided > for the configuration of jarOpenInterval (which we used the default = > 90s). The latest implementation appears to track the jar modification times > with a hash map called jarModificationTimes, but we are unable to find a > similar time-to-live configuration or what triggers the lifecycle listener > to close the jars (what calls WebappClassLoaderBase.modified() or > destroy()) - assuming we understand this lifecycle behavior. > > > > The server is configured mostly with default settings. The Context > reloadable property is NOT set. We have tried increasing the cache time of > the Resources cacheTtl property as the default of 5s seemed close to the > time the jars were reloaded. We have not been successful. > > > > Question: > > What is the cause of the repeated reloading of our web application jars? > What can trigger the class loader to close all the file handles related to > the jars in the web application WEB-INF/lib directory - and then open them > again within a few seconds? > > > > > > > > CONFIDENTIALITY NOTICE This message and any included attachments are > from Cerner Corporation and are intended only for the addressee. The > information contained in this message is confidential and may constitute > inside or non-public information under international, federal, or state > securities laws. Unauthorized forwarding, printing, copying, distribution, > or use of such information is strictly prohibited and may be unlawful. If > you are not the addressee, please promptly delete this message and notify > the sender of the delivery error by e-mail or you may call Cerner's > corporate offices in Kansas City, Missouri, U.S.A at (+1) (816)221-1024. > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > > For additional commands, e-mail: users-h...@tomcat.apache.org > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > > For additional commands, e-mail: users-h...@tomcat.apache.org > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > >
