Full gc will always pause the app. The different methods of gc attempt to mitigate this with different strategies, but only take you sobfar. The 75 second pausesbibsaw were with parnewgc and cms with 6gb min and max heap on a 1.6 jdk. On Feb 18, 2014 10:39 AM, "Carl Wilson" <[email protected]> wrote:
> ** > > Hi, > > The pauses are based on your GC settings, so you can mitigate this with > the correct settings for GC so you do not do a full collection and minimize > the pauses which will be less < 1 minute - without proper tuning then I > agree you will see pauses in excess of 1 minute. > > The number of available settings is quite large and BMC only provide a > small number of settings available. > > > > BMC actually now have a good write up on the JVM here: > > > > https://docs.bmc.com/docs/display/public/ars81/JVM+runtime+analysis > > > > Another good article is here: > > > > http://www.infoq.com/articles/G1-One-Garbage-Collector-To-Rule-Them-All > > > > JVM tuning is becoming somewhat of an art form now and there are many > references available to help. > > > ------------------------------ > > > > Kind Regards, > > > > *Carl Wilson* > > > > http://www.missingpiecessoftware.com/ > > > > *From:* Action Request System discussion list(ARSList) [mailto: > [email protected]] *On Behalf Of *Axton > *Sent:* 18 February 2014 15:48 > *To:* [email protected] > *Subject:* Re: 8.1 Mid Tier Issues Resolved > > > > ** > > The cost of allocating memory is negligible compared to the cost of huge > full garbage collections resulting from an fixed/over-sized heap. Watch > the GC statistics when setting them mix/max to high values equal to one > another. I guarantee at 6gb you will see pause times > 1 minute. The > frequency of that pause will be driven by the activity on the mid-tier > server. 1 minute pause times in the mid-tier will usability issues with > your application. This pause time will impact internal cache operations, > user request/response operations, session management operations, etc. > > > > On Mon, Feb 17, 2014 at 10:44 PM, Joe D'Souza <[email protected]> wrote: > > ** > > The reason behind that “used to be” (and probably still holds good), that > if you initiate your java virtual machine with the initial, and when it > requires more memory later, it actually chokes up a little when attempting > to grab that additional memory. Also in case some other process taken that > available memory at that time, you could have memory problems. That was the > justification to keep both the startup and maximum memory the same, wherein > you allocate the memory that you think your JVM requires right from the > start, and leave it at that, so irrespective of whether or not it does > require that much memory at any given point of time is irrelevant, as long > as its available for use when needed. > > > > With memory management being improvised with improved software and > hardware, this may probably be a redundant reason now, so worth looking at > whether or not having two different parameter values for MS and MX is worth > it. > > > > Joe > > > ------------------------------ > > *From:* Action Request System discussion list(ARSList) [mailto: > [email protected]] *On Behalf Of *Tauf Chowdhury > *Sent:* Monday, February 17, 2014 9:49 PM > *To:* [email protected] > *Subject:* Re: 8.1 Mid Tier Issues Resolved > > > > 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_ _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"
