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_ _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org "Where the Answers Are, and have been for 20 years"
