On 17.08.2017 14:21, Suvendu Sekhar Mondal wrote:
According to this however :
https://eclipsesource.com/blogs/2013/01/31/creating-tomcat-heap-dumps-on-windows/
jmap does not work under Windows, if Tomcat is running as a Service
(seems likely in the OP's case)
I don't know if that's true, have not checked it.

Andre, That is not correct. I use those jmap commands against our
Tomcat Windows services pretty frequently. Although I can not tell
about what it used to do in 2013. :)

Ok, well, that's good to know also, and forget my above comment.
That shows how Google is for many things a splendid search tool, but unfortunately in many cases it delivers a lot of noise. (Note that in this case, the page as a whole seems rather nice and helpful, except for this bit of outdated information thus).



On Thu, Aug 17, 2017 at 5:31 PM, André Warnier (tomcat) <a...@ice-sa.com> wrote:
On 17.08.2017 12:57, Leon Rosenberg wrote:

Fady, one thing,

analyzing heap dumps is hard especially a 10GB dump, you will need at
least
40 Gb of memory an about 10 hours to start jhat.
What is fast is analyzing a histogram. A histogram is a list of all
classes
in your JVM and amount of memory they use. It is very easy to use:

jmap -histo:live <pid> >outputfile


According to this however :
https://eclipsesource.com/blogs/2013/01/31/creating-tomcat-heap-dumps-on-windows/
jmap does not work under Windows, if Tomcat is running as a Service
(seems likely in the OP's case)
I don't know if that's true, have not checked it.


the :live parameter is important, otherwise you will see dead objects as
well. Keep in mind a major gc will be triggered.

The output looks like this:

   num     #instances         #bytes  class name
----------------------------------------------
     1:         98573       13165976  [C
     2:          4376       11325928  [B
     3:         96526        2316624  java.lang.String
     4:         40522        1296704  java.util.HashMap$Node
     5:         10954         807552  [Ljava.lang.Object;
     6:          7494         781480  java.lang.Class
     7:          6778         655464  [Ljava.util.HashMap$Node;
...

3103:             1             16
sun.util.locale.provider.TimeZoneNameUtility$TimeZoneNameGetter
3104:             1             16  sun.util.resources.LocaleData
3105:             1             16
sun.util.resources.LocaleData$LocaleDataResourceBundleControl
Total        456560       37330672

This won't point you to exact direction of memory leak or resource
consumption, but you will see what classes are consuming memory. So if you
find out that class foo.bar.XYZBean has 10.000.000 instances and occupies
2
gb of memory, you know where to look.

Keep in mind that only memory directly used by a class is counted, so
every
string will appear twice, as string and as byte array.

If you see that the used memory amount is growing, take multiple
histograms, every 10 minutes or so and analyse the differences. I wrote a
little script years ago for myself (

https://github.com/dvayanu/ldt/blob/c8b3c2b6f61de5c583db503f6fd5e2d8aa8b9aa0/java/ldt/histo/HistoDiffReader.java)
that takes two histograms and prints out the differences. This way you can
see if new instances of a specific class(es) are accumulated over time. In
this case you have a memory leak.

regards
Leon








On Thu, Aug 17, 2017 at 12:09 PM, André Warnier (tomcat) <a...@ice-sa.com>
wrote:

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 <fadyhai...@gmail.com>
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 <
suv3...@gmail.com>
wrote:

Hi Fady,


On Aug 16, 2017 7:04 PM, "Fady Haikal" <fadyhai...@gmail.com> 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: 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


---------------------------------------------------------------------
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

Reply via email to