On 16 Apr 2013, at 20:42, 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? > >> 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? > >> 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. > >> 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. +1 Did CMS in 1.5 actually collect in PermGen? (Genuinely don't know the answer to that) p > >> -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? > > - -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 > --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
