Chris, On Wed, Apr 17, 2013 at 1:11 AM, Christopher Schultz < ch...@christopherschultz.net> wrote:
> -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA256 > > 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. > > > 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. > > > 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. > > > 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. > > - -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/ > > iQIcBAEBCAAGBQJRbalsAAoJEBzwKT+lPKRY1/kP/isK8UjCkC3PB1WCgSp9aDNI > iOomoVHiXlL/0m4YTp/mxveB+8rs5edxrJPSeWJkpJAEs/4MU3MXVflapC2a90ij > FhcXd0QvR1Cf0KE97wWiwXWRTtn60wOErutvOqZ9/HnaVwWRBZhczlJ+ZEwQ9ms1 > vcFQMFsoOVFpFQT1rh4T+1ruRO+qorT1ybl7gkIPXNb4mkdgqrxkCiSwI2eB0w/p > b2Ig1ugx9wNB9petyfhVpOffl7jbl/18KdJXj5N1hKQ2tAfzOCSf6nTNeFluG+zd > J9/Wa6nOePgGf8+OzeIbvHS96u4SBOYt3NR1d/Vz1eIk1dvAxkp5aiBTvtv3l+Js > /TogUoHSjXILfH+zzutvoucHCFcAOtDD4O658z/BcfROnRBpz6TYoEhtGob3d+Zp > TFDM3N3WUt+566pKwNQtJfrOGJjq5IM7iBZKeofDiZGmJ1FiL89gdCWuHNpzvCX8 > sV8xuwBVEWXQwz+VuLW2FB9PaTSOUBqOMBjbt3sjjuY7Uw6lMEszDhXP7nAhlYEj > EsF9uXoWZBWMJZF+1p9KhjD3qNBhTKgB21TSzq59Mjw7FvhZE5pKDOqhYP/uyxi8 > nigqrjKJbKATBztpOiR8bjvb+LSJy0hvf6bNhvAZY6S4qRU6K2kWkFfPz3v6QIiz > GmxHvSCPXNHhx+X7S+3t > =YmSW > -----END PGP SIGNATURE----- > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > > Regards, Vidyadhar
