-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Vidyadhar,
On 4/17/13 10:56 AM, Techienote com wrote: > Chris, > > On Wed, Apr 17, 2013 at 1:11 AM, Christopher Schultz < > ch...@christopherschultz.net> wrote: > > Vidyadhar, > > On 4/16/13 1:14 PM, Techienote com wrote: >>>> With default setting we were getting frequent OOM errors. >>>> After analyzing the heap dump we found >>>> org.apache.poi.hssf.usermodel.HSSFSheet is accumulating more >>>> heap memory. As per the application development this is the >>>> normal behavior and have suggested to increase the maximum >>>> heap size to 2048MB > > So, you keep lots of spreadsheets in memory for some reason? I > can't imagine that loading a Microsoft Excel document into memory > and keeping it in what POI calls "horrible spreadsheet format" is > the best way to keep that information around. I suppose only /you/ > know you requirements. > > Just how many spreadsheets do you need to keep in memory? > >> Out of 2048 MB, 1536 MB is getting used by HSSFSheet. I am saying >> it after seeing the heap dump. I am not a developer and I do have >> only basic knowledge about Java. ...but you should know how many spreadsheets you intend to have loaded. Is that a single spreadsheet taking-up 1.5GiB? I'm trying to find out why that object is in memory /at all/. >>>> After increasing the max heap size we were seeing some large >>>> GC pauses for the same we tried to change the JVM policy to >>>> CMS and added following parameters >>>> >>>> -XX:+UseConcMarkSweepGC -XX:+UseParNewGC >>>> -XX:+CMSParallelRemarkEnabled > > Did you enable verbose GC logging before/after you enabled those > options? Did it help anything? Do you have any idea *why* your GCs > were taking so long, or did you just Google for "java gc is taking > a long time" and enable those options because they were > "recommended" by someone? > >> I have enabled GC logging before doing any changes. After >> observing the GC i have changed the GC policy to CMS as it is >> best for throughput. Also after changing it to CMS pauses has >> been reduced. You might try reading about CMS "goals" of pause-time is a problem. Given that the stop-the-world pauses should be short, I'm curious as to why you are experiencing pauses at all. A GC run, even if it takes 2 minutes to complete, shouldn't stop-the-world for 2 whole minutes. >>>> Since then the long pauses reduced from 112 seconds to 90 >>>> seconds. > > Without seeing your data, I would guess that it's only a > coincidence that your pauses have decreased in duration: you have > likely not had any improvement by changing the GC configuration. > > >> Earlier user is complaining about Application slowness. After >> changing the algorithm we have not observed any slowness issues. >> Earlier at the time of slowness issue we have observed GC pauses. >> I am saying this because at the time of issue there were many >> Minor GC call have been observed in GC logs. Note I am not expert >> in this I am just saying it after seeing the data. Minor GCs should happen all the time: it's completely normal. They should also be very fast because they are only dealing with the young generation of objects. The tenured generations do take longer to collect as a) they are usually bigger and b) they usually have a greater percentage of objects surviving the GC operation. >>>> Also we have seeing regular permanent generation concurrent >>>> mark failure which got reduced after changing NewSize to >>>> 512MB. > > Well, the NewSize shouldn't have any bearing on anything happening > in PermGen, other than maybe allowing OutOfMemoryErrors to occur if > you overfill PermGen. But that's not happening, here. > >>>> -Dsun.rmi.dgc.client.gcInterval=3600000 >>>> -Dsun.rmi.dgc.server.gcInterval=3600000 >>>> -XX:+DisableExplicitGC > > If I understand correctly (and I don't claim to be a GC ergonomics > expert), those options are mutually-exclusive. Disabling explicit > GC should disable the RMI's use of .. explicit garbage-collection. > So, if you really are using RMI, disabling explicit > garbage-collection can ruin everything. [See > > http://www.oracle.com/technetwork/java/gc-tuning-5-138395.html#1.1.Other%20Considerations|outline > > ]. > > Have you tried with a supported version of a Java VM? > > >> Will check the same and update accordingly. Before you spend a lot of time debugging GC on an old version of Java, I recommend that you test your app against a newer version. It may be that you are exercising a bug in the JVM and that Java 7, for instance, runs in an out-of-the-box configuration with none of the ill effects you describe above. - -chris -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCAAGBQJRbuNfAAoJEBzwKT+lPKRYdqwP+wTgXpfCxiN0d6Soo2FROC15 MXG/PMmcfnQaBFnngpY5Gc580AHA+jLu39SvENzpfa2/OEKS38PUuV9swtkN1F5d s5a2JQh3lDfYYSukEuxiMgE8O/ZpzdgVzPJIfHvSlm//513q2yBi/YXTJ0/Bn7WP Q7FFs3kgV2W+FHOHVEErWA+exeY66iYcdBhFVflmS9Gu85c/IIujNfC19VUVFTYk NIaaJAm5YzyQiyOsSMFfhTNTH1bInhi1yyZMN4O8yClMJnRBcXP+mBOFAIZf5x3/ mmgEvdidjl238+CJhpIOoC6Uv+cJovwl7fvR7+RUdEnoR694p0M9ykcAg0vCr0H6 9vSV9ykTaByi25U2bLEGhn2InvXqjcjUu8fVumpZGv68wA/+O13PYGlTPGywFVUL Adl4OJa/fpPqLaP/pHli41mObCf2BkGiNe4SFGg+Pkz2BPDjwz/7Tq2gXvcqWAGo 2XG0ANyw7WOD5+rTz4uT/ncrzX9WfH9nZHu9S1r30O2YA211n1O3vYAUWaMpOmg4 hcfcSr1zCFgDACtkIe6+Ed6LMtjTXZbBnY28h8BmemfQYr9qoVAllG3zrc1/F5r/ 9/YPrymipuPsiweFzlWAsukv5tpQKmPHYapfbRHw00D8ZTX+De1PKkwe4Ri1Z18B EVpqp++ckROrd+AN8Wkc =2ylH -----END PGP SIGNATURE----- --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
