Each process (program) running on the server has the ability to lock for its exclusive use a chunk of swap space or virtual memory. If enough processes lock enough space, the next attempted lock will fail, and that process will terminate abnormally with a memory allocation error. Because there are so many variables involved, it is difficult to calculate or predict how much swap space or virtual memory will be the maximum amount needed. We recommend that virtual memory or swap space be set between two and three times installed physical RAM as a reasonable guess.
For example, if 4 GB RAM is installed in the server, swap space or virtual memory should be set for a minimum of 8 GB, and 12 GB is preferred, if there is sufficient disk space available. We also recommend that resource-intensive applications, such as relational databases, be moved to separate servers and not be co-located with Essbase.
Another important memory-related metric to track is the amount of memory consumed by each ESSSVR process. Each ESSSVR process is a running Essbase application, and on 32bit Essbase, none can ever use more than about 2 GB of memory address space (4 GB on Solaris; 1.7 GB on HP-UX). If ESSSVR tries to consume more than this amount, memory allocation errors and perhaps data corruption can occur.
The remedy is to
1. Reduce the number of databases defined for the application.
2. Within the database, reduce the amount of memory allocated for caches.
3. Reduce the blocksize.
4. Reduce the number of members in the outline.