Chris, First of all thanks for the infor. On Wed, Apr 17, 2013 at 11:31 PM, Christopher Schultz < ch...@christopherschultz.net> wrote:
> -----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/. > Every spread sheet is of 64MB. So around 24 spread sheets at a time. > > >>>> 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. > Agreed on this point but as per my observation pauses has been reduced after implementing CMS. > > >>>> 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. > Agree > > >>>> 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. > We are in the plan of upgrading the tomcat with the JVM version. It is in process but before that we need to stablize it on Tomcat 6 > > - -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 > > Vidyadhar
