-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Leon,
On 8/17/17 6:57 AM, 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 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/c8b3c2b6f61de5c583db503f6fd5e2d8aa 8b9aa0/java/ldt/histo/HistoDiffReader.java) > > that takes two histograms and prints out the differences. This way you c an > see if new instances of a specific class(es) are accumulated over > time. In this case you have a memory leak. The OP's report sounds more like a great disparity between native memory versus heap memory usage. The Java heap, of course, is only a part of the actual (virtual) RAM used by the process; there are plenty of non-heap memory resources required by the JVM for everything. I've not found a great tool for inspecting native memory spaces in a JVM. My recommendation would be that the OP make sure he/she has the latest possible version of the JVM available, just in case there is a memory leak in the JVM itself. The same should be done with all other libraries in case any memory leaks exist and have been fixed. - -chris -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAlmW7WAACgkQHPApP6U8 pFhd9RAAsjPO/BTFX2RRZH0SRry2b0Pb1tMlGwPBW0tEesQRnLn+zS5l3FaSrwJJ 7Ar9fJhcwIiGZdDq15hURg9vVJFoEEfh3jhhOTH8DafDFfjneEnwzrvUcdyyrlpL 8tyXByTpk0H51HPaEkhm0YJlSY6rSQuVOfVNOY+HrFSQiDxidqU5l5igUdnmczk1 0Z+AXuOB+oF1E1XkihPfDpX1TwsImuGKylBe7Rmng4KWA8J8d9Xo17bXH2DfgDOm zt0iSTYZ3Hus1T84zpO4qCm9NWvYvROMACcTweYJ8VsgXkjnacVZhSP4NA3vlGF4 TuzxnyUWngbB82ERoiD0BY99406fcxvAyyJ1H1EQ7Z76UlRWKaQgGWK3U/Fb4kI0 6ugXV9daNmGYGar9rHmSGccUzkyqzOnjinFOF3OYaAs8eyFPvXlB0TvXWbQUQESe Jx4YK+vmtGVIUlM/c4selCPPKpryOkRfjjqBdDOnrJYWbp6bYlMtRpzO19TpCOIA qve6SWCVhEhzviXbW+xs0GH2QQHuveDzc5XIZC7ysX3Y5kTdJlOvH0j9pWCeMaQ5 1tAKj2jiI/m9VirjsFpxC0hy8lRB1wqrJQdaIRwWtaMEO7zVy20igyEMrw/tXOcv 6K14O6hMQPqaE1ge8xFk+IzEzyceaCzmv3xw8C5FRlIntzlFFBM= =KFMx -----END PGP SIGNATURE----- --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
