Lets not kid around, Oracle EPM is a beast. Any environment that has more than 2 users is probably going to require some performance tuning. Fortunately there are a lot suggestions on what to do should you encounter memory problems. Unfortunately though much of that information is just that suggestions or examples, they don't really explain what settings do.
I started writing this post well over a year ago. At the time I was at a client where the installing consultants had setup a new environment and had tuned the environment. This seemed odd because the install team wasn't ever told how many applications were being built and sometime after they were gone the number of users increased by several hundred. In any case I was asked to take a look since services were having to be rebooted daily if not multiple times a day and some would pause randomly. In this particular install the services were all configured similarly which is generally a bad sign. Almost ever service (Ex. Planning, EAS and Calculation Manger) was configured to have a 4GB heap. That will work in smaller environments but its a waste of resources for some services (EAS) and not enough for others (Planning).
I highly recommend taking a look at the EPM Infrastructure Tuning Guide. Keep in mind though it is only a guide and that most environments will deviate in one way or another but many of the settings are spot on.
The heap is an area of protected memory that the JVM allocates for running an application. In the case of EPM this would be Weblogic applications like Planning or Foundation Services.
Alexander, Alvin provides very good simplified technical explanation.
"The Java Virtual Machine Has a Heap That Is Shared among All Java Virtual Machine Threads. The Heap Is the Runtime Data Area from Which Memory for All Class Instances and Arrays Is Allocated.
The Heap Is Created on Virtual Machine Start-up. Heap Storage for Objects Is Reclaimed by an Automatic Storage Management System (known as a Garbage Collector); Objects Are Never Explicitly Deallocated.
The Heap May Be of a Fixed Size or May Be Expanded as Required by the Computation and May Be Contracted If a Larger Heap Becomes Unnecessary. The Memory for the Heap Does Not Need to Be Contiguous.
A Java Virtual Machine Implementation May Provide the Programmer or the User Control over the Initial Size of the Heap, as Well As, If the Heap Can Be Dynamically Expanded or Contracted, Control over the Maximum and Minimum Heap Size."
Web log post. Alvin Alexander. N.p., 6 June 2014. Web. 8 Jan. 2015. Java stack and heap definitions.
Xms and Xmx
Java uses these parameters to define heap size. Keep in mind this does not define how much memory that a java application will use but how much heap it will allocate in addition to the memory requirements of the java application.
- Xms: this value defines how much memory to allocate to the heap when the appliaction starts.
- Xmx: this value defines the total amount of memory the application is allowed to allocate to the heap.
Some people claim that its best to synchronize these values. I won't say that's wrong but I in my personal option all that does is slow down the start up of the services. This instructs the JVM to pre-allocate all the heap memory in some applications this can be a considerable performance gain. Particularly applications where lots of memory are allocated very quickly. A good example of where this works well is using Jython instead of Python to run the essbase-xml-otl-compare.py. By pre-allocating memory the JVM doesn't have to perform memory allocations on the fly.
The problem with this with regards to EPM is that you end up with a ton of memory being pre-allocated that might never be used. EPM outside of FDMEE and Reporting and Analysis rarely if ever allocate large amounts of memory quickly and even if they do its generally only for a short period of time. So in most instances this just makes services start slower. Sometimes having too much memory can lead to long pauses due to GC (Garbage Collection) especially if an application has memory leaks (I am not saying Oracle EPM does.)
As a rule of thumb I generally use the following as my recommendations for sizing:
|>512MB & <1.5GB||3:2|
|>1.5GB & <6GB||2:1|
Out of Memory Errors are always the Heap
About a year ago I was on a project where the server was throwing out of memory errors. The people there kept increasing the Xmx and Xms but still the errors persisted. The issue was that not all out of memory errors are regarding the heap. At this particular client the issue was the Thread Local Area (TLA) was running out of memory. The TLA is a portion of the heap that is reserved exclusively for each thread. Once we increased the TLA sizes the service stabilized and we found we could actually reduce the size of the heap (Xms and Xmx.)
Its not just a website sometimes, rarely (I've only used this once at a client with a large planning user base) it can be beneficial to increase the size of the Java stack. Increasing the size of the stack can prevent StackOverflowError's and I have heard increase performance under some workloads. The setting for this is
-Xss=<value> and generally the values range between 64k and 4MB. One thing to keep in mind with the stack is that this determines the size of the stack for each thread not for the service. So if you have a Xss=512k but the service is using 15 threads then combined stack size would be 30MB.