On 17.08.2017 11:21, Fady Haikal wrote:
Team,
Please i need some help her
Maybe start here ? http://lmgtfy.com/?q=analyse+tomcat+heap+dump
(and this looks like it might help you :
http://docs.oracle.com/javase/7/docs/technotes/tools/share/jhat.html)
To restate the obvious :
- this list here is manned by volunteers, who donate their time trying to
help people who have problems with Tomcat, and who are doing their best,
but
- the list works best with people who also help themselves
- we do not have access to your system, and we do not know your
applications
- we can only try to help, on the base of the information which you
provide
- there are 3 (possible) components to your problem :
a) the Java JVM which runs Tomcat
b) Tomcat itself, which runs your applications
c) the applications themselves
Of these :
a) is controlled entirely by you, and is in fact the one which
ultimately uses all that memory (but we do not know why either). Below
you
are showing the startup parameters of the JVM. They are not the default
settings. So where do these parameters come from, and do you understand
them ? (if you don't, you first need help with Java, not with Tomcat)
b) That is really the focus of this list. And we know that Tomcat, by
itself, does not use 60GB or 10GB of memory, nor anywhere near it
c) we know nothing about, but it is likely that it is something there,
which causes Tomcat (and Java) to use all that memory
And about (c), maybe it is normal that it/they use this gigantic amount
of
memory. Maybe one of the applications allocates some gigantic array of
data
over time. Maybe one of these applications is really badly programmed and
causes enormous "memory leaks". How would we know ? Are these your
applications ? If not, have you contacted the people responsible for
these
applications, and described your problem to them ?
(because again, with 99& probability, that is where the problem is)
Try to collect some more specific data, and when you have it, post it
here, and maybe someone will have an idea. But as it is, the only thing
known so far is that on your system, the Java JVM which runs tomcat is
using up a lot of memory, increasingly over time, and that it ends up
crashing with an OOM.
That is not enough information for us to be able to help you.
If you are desperate and in a hurry, maybe you need first to find a Java
JVM specialist, who can help you poinpoint the problem more specifically.
Regards,
On Thu, Aug 17, 2017 at 9:46 AM, Fady Haikal <[email protected]>
wrote:
@Suvendu,
I took a heap dump from Java VisualVM but honestly i didnt know how i
should analyse it, please some help here
also please find below the java configuration i used:
-XX:PermSize=10240m
-XX:MaxPermSize=10240m
-XX:ReservedCodeCacheSize=512m
-XX:+UseParNewGC
-XX:+UseConcMarkSweepGC
-XX:+CMSParallelRemarkEnabled
-XX:TargetSurvivorRatio=90
Initial and Max Memory Pool: 100000MB
Regards,
Fady
On Wed, Aug 16, 2017 at 5:46 PM, Suvendu Sekhar Mondal <
[email protected]>
wrote:
Hi Fady,
On Aug 16, 2017 7:04 PM, "Fady Haikal" <[email protected]> wrote:
Dear Team,
I'm facing an issue that tomcat from task manager is consuming around
60
GB
of memory while from Oracle Java Mission Control is showing maximum 10
GB
(Attached screenshots), and from time to time the server hang due to
insufficent memory.
can you please advise why the above is showing like that? and why the
memory of the server is not reducing?
Tomcat Version: 8.0.30
JDK: 1.7.0_67
I couldn't find the screenshot. Anyway, the issue you mentioned is
very
interesting. Usually I saw some difference(in MB) between task manager
data
and JMC data...but not like this. Can you please let us know about
the
Java Heap, Permgen and thread stack size configuration?
For starter, I will suggest to take a heap dump and look into it. It
will
show you which objects are live and holding the memory. Also it will
be
awesome if you can enable Native Memory Tracking for your TC instance.
Thanks!
Suvendu
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
