Re: Is it Normal for Tomcat 8 to Use 20-80% More Memory Than Tomcat 6?

[Suvendu Sekhar Mondal]

On Thu, Dec 28, 2017 at 3:36 PM, Olaf Kock  wrote:
>
> On 27.12.2017 23:16, Eric Robinson wrote:
>>>
>>> I mean A is java8 and tomcat8.. so make a C that is tomcat6 and java8
>>
>> I don't think so. This is a requirement of the software company whose
>> application solution we use. They are requiring us to move to tomcat 8 with
>> jdk 1.8. If we try to mix tomcat8 with jdk 1.6, supposedly we would have
>> problems. I guess all this is being driven by the need to switch to TLS 1.2.
>> I'm not sure if that would be a function of tomcat or java.
>
> As you were looking for the reason of the increased footprint, this would
> help you tremendously to get to the root cause, even if you don't intend to
> use it in production. Assume that a similar behavior already appears when
> you run tomcat6 with Java8 - in this case there might be little reason to
> continue to dig in tomcat, and assume that it's the Java implementation that
> caused your increased footprint.
>
> Tomcat 8 with Java 6 won't work (apart from the outdated implementation) as
> it requires at least Java7 (which is also outdated).
>
> And then there's yet another aspect: The memory footprint increased way
> below the price decrease for memory, so just adding this much memory could
> be filed away as a reasonable assumption within 7.5 years (JDK 1.6.21 was
> released July 2010, I'm assuming that this is the age of the hardware as
> well (because why would you have installed this version on newer hardware,
> when newer releases existed)
>
> I'm assuming that you have enough aspects to inspect - if you're really
> interested in finding the root cause, you'll need to come up with more
> specific measurements, e.g. profiler data, compare thread dumps and set up
> Tomcat 6 with Java 8 to have a third reference point.
>
> Olaf
>

How about turning on Native Memory Tracking for both Tomcat8+JDK1.8
and Tomcat6+JDK1.6 combination and compare the results? It will give
you details about internal memory consumption of the JVM. If you see
increase there, you will also able to find out which component's
memory footprint has increased. You can turn NMT on by adding
following JVM arguments:

-XX:+UnlockDiagnosticVMOptions
-XX:NativeMemoryTracking=summary

After turning on NMT and running Tomcat, when you see there is rise in
memory usage, use JCMD to dump native memory consumption details for
analysis. You can find more details about NMT here:
https://docs.oracle.com/javase/8/docs/technotes/guides/troubleshoot/tooldescr007.html

IMO, if you see there is not much difference between native memory
consumption of JDK1.6 and JDK1.8, then you need to focus on Tomcat.

Thanks!
Suvendu

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: Are Symbol files of Tomcat DLLs publicly available?

[Suvendu Sekhar Mondal]

On Tue, Dec 5, 2017 at 4:19 PM, Mark Thomas  wrote:
> On 05/12/17 06:47, Suvendu Sekhar Mondal wrote:
>> On Tue, Dec 5, 2017 at 1:28 AM, Mark Thomas  wrote:
>>> On 04/12/17 11:12, Suvendu Sekhar Mondal wrote:
 Hello Everyone,

 I am investigating a Tomcat crash. Actually, JRE crashed due to
 "access violation" error. It created a Windows memory dump file. I am
 trying to analyze it win WinDbg. Problem I am facing is that lots of
 Symbols (of tomcat7, jvm, java, tcnative-1, nio DLLs) are not
 available to me. As a result WinDbg is giving me a Stack filled up
 with DLL names and HEX values.

 In order to get some of them - mostly JRE related, I have already
 reached out to Java forum:
 https://community.oracle.com/thread/4102753. No response so far :(.

 Can someone please tell me how can I get Symbol files of Tomcat DLLs
 like tomcat7 and tcnative-1? Are they publicly available?
>>>
>>> Exactly which versions do you need?
>>
>> Sorry, Mark. I should have provide that information upfront. I am using:
>>
>> Tomcat 7.0.55
>> JRE version: Java(TM) SE Runtime Environment (8.0_92-b14) (build 
>> 1.8.0_92-b14)
>> OS version: Windows Server 2012 R2
>>
>>> I produced the binaries for the most recent of those and I probably
>>> still have the necessary files sat on a VM if they are recent(ish).
>>>
>>> Mark
>>
>> Yeah, I know it's not that recent. Still, if you have it please let me know.
>
> Those versions don't help. I need to know the exact version of
> tomcat7.exe and the tcnative-1.dll.
>
> Mark
>
>
>
>>
>> We tried to create PDB files for Java specific DLLs from OpenJDK, but
>> as you can see below, WinDbg rejected it.
>>
>> * Symbol Loading Error Summary **
>> Module nameError
>> tomcat7No header information available :
>> srv*c:\mss*http://msdl.microsoft.com/download/symbols
>> jvmSignature does not match :
>> srv*c:\mss*http://msdl.microsoft.com/download/symbols
>> tcnative-1 No header information available :
>> srv*c:\mss*http://msdl.microsoft.com/download/symbols
>>
>>
>> Thanks!
>> Suvendu
>>
>> -
>> 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
>

Resurrecting this thread to provide some update.

First of all, sorry for this superb delayed response. I was out for vacation.

Good news is that we have found what is causing all those JVM crashes.
Client has created a huge Java class which contains 32000+ methods
(yes, we gave them a weapon and they have used it to hurt themselves
:( ). Our APM tool was trying to retrieve the stack frame for a method
which has something to do with those large number of methods in that
class. That is the point JVM crashed. We can recreate the issue with
OpenJDK, Java 8 and Java 9. It was found we can get around of it by
increasing stack size(-Xss) but that is not an optimal solution. We
have asked client to reduce the number of methods and also reported
this bug to Oracle. Let's see how it works.

And Happy New Year to all of you!!! :)

Thanks!
Suvendu

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: Is it Normal for Tomcat 8 to Use 20-80% More Memory Than Tomcat 6?

[Olaf Kock]

On 27.12.2017 23:16, Eric Robinson wrote:

I mean A is java8 and tomcat8.. so make a C that is tomcat6 and java8

I don't think so. This is a requirement of the software company whose 
application solution we use. They are requiring us to move to tomcat 8 with jdk 
1.8. If we try to mix tomcat8 with jdk 1.6, supposedly we would have problems. 
I guess all this is being driven by the need to switch to TLS 1.2. I'm not sure 
if that would be a function of tomcat or java.
As you were looking for the reason of the increased footprint, this 
would help you tremendously to get to the root cause, even if you don't 
intend to use it in production. Assume that a similar behavior already 
appears when you run tomcat6 with Java8 - in this case there might be 
little reason to continue to dig in tomcat, and assume that it's the 
Java implementation that caused your increased footprint.


Tomcat 8 with Java 6 won't work (apart from the outdated implementation) 
as it requires at least Java7 (which is also outdated).


And then there's yet another aspect: The memory footprint increased way 
below the price decrease for memory, so just adding this much memory 
could be filed away as a reasonable assumption within 7.5 years (JDK 
1.6.21 was released July 2010, I'm assuming that this is the age of the 
hardware as well (because why would you have installed this version on 
newer hardware, when newer releases existed)


I'm assuming that you have enough aspects to inspect - if you're really 
interested in finding the root cause, you'll need to come up with more 
specific measurements, e.g. profiler data, compare thread dumps and set 
up Tomcat 6 with Java 8 to have a third reference point.


Olaf

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org