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