-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 André,
On 3/24/15 10:24 AM, André Warnier wrote: > Christopher Schultz wrote: >> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 >> >> André, >> >> On 3/23/15 11:26 AM, André Warnier wrote: >>> Christopher Schultz wrote: >>>> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 >>>> >>>> Chuck, >>>> >>>> On 3/23/15 10:33 AM, Caldarale, Charles R wrote: >>>>>> From: Christopher Schultz >>>>>> [mailto:ch...@christopherschultz.net] Subject: Re: Tomcat >>>>>> 7 (7.0.54) memory consuption is very high(3 times) than >>>>>> Tomcat 6 (6.0.28) Really? The Tomcat ROOT web application >>>>>> is taking up 3 times as much heap space in Tomcat 6 as >>>>>> Tomcat 7? >>>>> Just remember that the numbers out of top are at best >>>>> approximations, and, as Rainer pointed out, not taking >>>>> measurements immediately after a GC is a guarantee of an >>>>> apples versus oranges comparison. >>>>> >>>>> The appropriate tools (e.g., VisualVM) must be used for >>>>> any rational analysis. >>>> +1 >>>> >>>> The output of "top" and "ps" are completely irrelevant. The >>>> very minimum would be the output of "jmap -heap", and only >>>> after a full GC were to have been run. >>>> >>> The appropriate java-specific tools must certainly be used to >>> find out /what/ is using this memory inside the JVM. >>> >>> But qualifying the output of "top" or "ps" as "irrelevant" is >>> probably a bit over the top. After all, they do indicate how >>> much the JVM is (approximately) using from an OS perspective, >>> and that is probably not totally irrelevant here. >> >> With no heap size hints, you will get the JVM's default for that >> environment. Tomcat's memory usage profile may have changed >> between versions, and the JVM is under no contract to do things >> exactly the same way every time when it comes to GC activity. >> Just because the process is taking 512MiB of virtual memory >> doesn't mean that Tomcat is using all of that heap. If you look, >> you may find that the heap is 90% empty. In that case, the output >> of top/ps is irrelevant. >> >> If you want to make sure that the JVM doesn't take more than a >> certain amount of memory, you have to tell it that. >> >>> I wanted to see the respective startup commands to check if >>> there wasn't some change in the default startup script switches >>> (like -Xms/-Xmx) which would explain the difference. But >>> apparently not. >>> >>> Even if a GC would make the two look less different, the >>> question would remain as to why one Tomcat would need a GC for >>> that, and the other not. >> >> It depends upon how many minor GCs happen and when: some >> relatively short-lived objects may be promoted to the old >> generation more quickly in Tomcat 7. >> >> One particular thing I can think of that changed was the way >> annotation and SCI scanning is done: that produces a TON of >> garbage on startup. >> > > I understand all that. But the basic view, from a sysadmin's point > of view is this : > > Tomcat 6(6.0.28) Virtual Memory: 6772 MB Resident Memory: 81 MB > > Tomcat 7(7.0.54) Virtual Memory: 6778 MB Resident Memory: 148 MB > > Presumably, the above numbers are taken some time (minutes ?) after > the respective Tomcat starts, with only the basic standard ROOT > application. So whatever it is due to in Java, as a sysadmin one > could legitimately wonder why Tomcat 7 seems to need some 70 MB > more resident memory than Tomcat 6, no ? It's a reasonable question but the answer is complicated. As far as the OS is concerned, the Java process has used all that memory. As far as Java is concerned, however, the heap may be (nearly) entirely empty. If Tomcat 7 generates a lot more garbage on startup than Tomcat 6 and the JVM feels like it's got plenty of room to expand the heap (say, there is a whole gig out there untouched, but which it's allowed to grab), then the heap will continue expand. If a full GC doesn't occur, then long-lived objects that are only necessary during startup will still "use up" heap space, etc. For most JVMs, even a full GC won't actually shrink the total size of the heap: once the memory has been requested from the OS, it's there forever. I believe newer JVMs have options to allow that memory to be returned to the OS, but I haven't done very much investigation into those features. Re-sizing the heap is an expensive operation, which is why most of us recommend that -Xmx == -Xms because if you're going to allow the JVM to take that much memory eventually, you may as well do yourself a favor and allocate it all at once on JVM launch. > And it is the same platform and the same Java JVM, so the startup > defaults of the JVM themselves should be the same. And there are > no "heap size hints" in one case or the other. Correct. I suspect that the OP has no idea that the heap will be allowed to grow to whatever its default max size is. Without capping the heap size, it's no wonder the memory seems to climb without bound. I think this is a fundamental ignorance about the way the a JVM claims and manages memory. > I mean, we are talking about 70 million bytes per instance here, > not just some little bit of garbage left and right. Does figuring > this out really require going through the heap dump taking/analysis > scenario ? In my naive view, I would have imagined that if there > was such a jump between one version and the other (neither of them > really young), it would have been obvious already to someone else, > and the explanation would have been known already. > > I guess maybe the fundamental question here is : is the above > "normal and expected", or is there some as-yet mysterious reason > for which this happens on the OP's system and nowhere else ? If it were me, the first thing I'd do is set a maximum heap size and see what happens. Say, 80MiB. Then start Tomcat 7 and see if it OOME's or stops at (roughly) 80MiB. I suspect Tomcat will run just fine in it's newly-constrained environment. - -chris -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org iQIcBAEBCAAGBQJVEbcwAAoJEBzwKT+lPKRYlTwP/jpbc+eMVaNq3DRPxYojKCXs k4qxpZoNw8JfHz48cMmpG0wQN3ZPjRo/MwFt53fI48gyPwC9v/exmePYbetBsskx 9R79BThTRbHznTe02tzEbUlYfYH3wotSpOj0tKTXJNqC/TfpFWN+tRc7OpTu+1XX 5RjW8YBUgFzG1vfUGUIfVB7GnPNGWFNdwwXsDV+D/hKbi+U0KrJCfwqTxWjkdrRo xBBosBGMa3dcq12TmE7cCkUtUyfgJPXEAyCAOwpycMkhzY0Au684mUxOctecacox Ki4dqO8NFRZW7ZtP9lmO5w2LY5esHrL/7W9k4jBJ5mqmqWoeiSeMyhTLhnfWtCoJ m38lGECwLatmRPnAfSFhvwCSS1lCVs9gTnVpi/guLWwpeLsDr5cub28lO6iSkgpF tN+lNf722wC8uzujzjMY3ya4SMLZ45mOSKolllL/EcKbmzTpnTzONdkwt2GL4bn3 TR8gGF+1xPtWbZWy3kmzGGwyckSbKq97FA5p7UH728AQdthjJOEEipb0KT6TmNYG jIz3kesPnStg49A/pSFTYnmSpLsVasR2usFVRDOFXnoof8DbgmC10azr+/XEEiuQ a5w1WsLHozjV6rO45XbEL73/GQVwpr3SkxwxBgCKAbJrhUKL04VDZwKFCE7R7U9X lygHqCulVfwBYCubxwlt =V7t7 -----END PGP SIGNATURE----- --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
