We are having heap and GC errors also. Support suggested the following settings which we'll be putting on our MT servers this week. We also get caught exception errors but last weeks fix of has taken care of them so far.
Please add the following JAVA_OPTS parameters which will help resolve the 'java.lang.OutOfMemoryError: GC overhead limit exceeded' error: JAVA_OPTS="$JAVA_OPTS -XX:+UseConcMarkSweepGC"; export JAVA_OPTS JAVA_OPTS="$JAVA_OPTS -XX:+UseParNewGC"; export JAVA_OPTS JAVA_OPTS="$JAVA_OPTS -XX:NewRatio=3"; export JAVA_OPTS Keep the original values and add the above- it will look like: JAVA_OPTS="$JAVA_OPTS -Xms6144m"; export JAVA_OPTS JAVA_OPTS="$JAVA_OPTS -Xmx6144m"; export JAVA_OPTS JAVA_OPTS="$JAVA_OPTS -XX:PermSize=1024m"; export JAVA_OPTS JAVA_OPTS="$JAVA_OPTS -XX:+UseConcMarkSweepGC"; export JAVA_OPTS JAVA_OPTS="$JAVA_OPTS -XX:+UseParNewGC"; export JAVA_OPTS JAVA_OPTS="$JAVA_OPTS -XX:NewRatio=3"; export JAVA_OPTS Also, please make my earlier suggested change to armonitor.conf : /opt/jre/i586/jre1.7.0_25/bin/java -Xmx2048m -classpath /opt/bmc/ARSystem/pluginsvr change it to: /opt/jre/i586/jre1.7.0_25/bin/java -Xmx3072m -classpath /opt/bmc/ARSystem/pluginsvr LAST WEEK we did the following to take care of the plugin errors Based on the error in the arjavaplugin log, we would recommend increasing the heap value for the pluginsvr in the aromonitor.conf file (please make this change on both the servers): /opt/jre/i586/jre1.7.0_25/bin/java -Xmx2048m -classpath /opt/bmc/ARSystem/pluginsvr change it to: /opt/jre/i586/jre1.7.0_25/bin/java -Xmx3072m -classpath /opt/bmc/ARSystem/pluginsvr So far that is working. On Mon, Feb 17, 2014 at 8:48 PM, Tauf Chowdhury <[email protected]> wrote: > ** > Axton, > I echo your thoughts. That used to be a recommendation but in the newer > releases, it's no longer necessary to call all the memory up front. The > system should be able to use what his necessary. Was that a recommendation > from BMC? > > Sent from my iPhone > > On Feb 17, 2014, at 9:45 PM, Axton <[email protected]> wrote: > > ** > Why do you do this: "Set the Initial memory pool and Maximum memory pool > to be the same?" > > Axton Grams > > > On Mon, Feb 17, 2014 at 12:26 PM, Pierson, Shawn < > [email protected]> wrote: > >> ** >> >> Good afternoon, >> >> >> >> I wanted to come back and post some of the issues that we were running >> into and what solved them. Basically, we had three issues: >> >> 1) Mid Tier seemed to "slow down" for about 30 seconds every 15 >> minutes or so. >> >> 2) Tomcat would crash with memory issues. >> >> 3) Mid Tier would display "Caught exception" errors all over the >> place. >> >> >> >> There are many other ITSM 8.1 issues so don't get the idea that I think >> it's a great release out of the box but this is specifically about Mid Tier >> rather than a list of all the issues we ran into. Anyway, the solutions >> for the issues we ran into are: >> >> 1) It turned out someone had enabled Developer Cache Mode. That >> had to be turned off. Rather than blaming a developer, I suspect that one >> of the installers did it. >> >> 2) To resolve the memory issues, we had to change the JVM settings >> that Tomcat used to be something like this: >> >> a. Set the Initial memory pool and Maximum memory pool to be the >> same. >> >> b. Set the Java options to be something like this (excluding the >> sections that set default directories): >> >> -XX:+UseParallelGC >> >> -XX:-UseCompressedOops >> >> -XX:PermSize=1024m >> >> -XX:+HeapDumpOnOutOfMemoryError >> >> -Dorg.apache.tomcat.util.buf.UDecoder.ALLOW_ENCODED_SLASH=true >> >> 3) To get rid of the caught exception errors, I upgraded Tomcat to >> 6.0.37 and applied the February 8.1 Mid Tier patch linked to in an earlier >> thread. >> >> >> >> At this point, my Mid Tier is stable. Some users still have to delete >> their browser cache whenever we clear the cache on the Mid Tier, but it's >> not as bad as it was. One negative change is that we get 500 server errors >> now on rare occasions due to local cache being corrupted. Something not >> good but not terrible is that flushing the cache takes at least twice as >> long as it used to, but that's still manageable since we aren't changing >> code as often as we did right after putting ITSM 8.1 into production. >> Overall I think performance of 8.1 is slightly better than 7.6.4 over time, >> but the initial load (even with preloading turned on for common things) >> seems to take a bit longer. Also, we are still using IE9, which is >> extremely buggy and a factor as well. >> >> >> >> That's all I can think of for now but I hope someone else gets some >> benefit from this. >> >> >> >> Thanks, >> >> >> >> *Shawn Pierson * >> >> Remedy Developer | Energy Transfer >> >> >> Private and confidential as detailed >> here<http://www.energytransfer.com/mail_disclaimer.aspx>. >> If you cannot access hyperlink, please e-mail sender. >> _ARSlist: "Where the Answers Are" and have been for 20 years_ > > > _ARSlist: "Where the Answers Are" and have been for 20 years_ > > _ARSlist: "Where the Answers Are" and have been for 20 years_ > _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org "Where the Answers Are, and have been for 20 years"
