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 ?
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.
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 ?
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
