> 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. :) 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
