-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Kevin,
On 5/29/12 3:50 PM, Kevin wrote: > On 5/29/12 11:09 AM, "Christopher Schultz" > <ch...@christopherschultz.net> wrote: >> It would be better to get a heap dump both before AND after the >> full GC, but that can ruin your performance if you enable those >> automated GC options. > > We can run this after our next code release in two days. Okay. >> Are you populating huge caches on startup or anything like that? >> Generational GC performance is related to the number of >> surviving objects that have to be moved from one generation to >> the next, so if you have a huge population of objects surviving >> each collection one after the other (which is what I might expect >> if you had an enormous cache being fulled all at once) then your >> performance will suck for a while until those objects are tenured >> enough to avoid periodic collections. > > This was our initial assumption however since we're using an in > memory EhCache we would expect this issue to re-accure when tomcat > is restarted. It doesn't. It'll only show up if we stop tomcat, > reload the WAR and clean the work directory. Have you tried re-starting your webapp without restarting Tomcat? Does EhCache do any kind of magic optimization on the disk, where the removal of the 'work' directory would have some direct consequence? >> Are you able to inspect the various generations before and after >> these pauses? I'd be interested to see if you have a huge >> population of objects being tenured at once and what types of >> objects they are (they might be something obvious like instances >> of our.big.fat.CacheEntry or something like that). > > We'll give it a try With any (relative) luck, you'll have another event where everything sucks for 2 hours, you'll get a huge full GC with heap dumps on either side of it, and then you can inspect them. Again, remember that full heap dumps around full GC's is going to murder the performance of your full GCs (yes, it can get worse). Unfortunately, that also means that disabling those options means another JVM restart which means another 2 hours of agony. The good news (I guess) is that you can do all these restarts during off-hours (do you have any off-hours) and not impact your users too much. - -chris -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk/FM3AACgkQ9CaO5/Lv0PCeQwCgl5XmoWGO5COKBa/XC/L596yA lX8An1va+s88s6jtkdUYVzAJBV6fqNJk =mwwO -----END PGP SIGNATURE----- --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
