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
