Configuring the Application Server Heap Size

To get the most out of your TrueSight Server Automation infrastructure, you're going to want to make sure that you leverage the right amount of RAM for each Application Server instance that you are running. This page shows how to configure heap sizes for your instances, along with some various tuning guidelines.

• AppServer Launcher JVM Settings
• JVM parameters
• Heap Size Tunning
• Notes

AppServer Launcher JVM Settings

The JVM settings used by Bladelogic Application Server Launcher on Windows are stored in the following registry key:

HKEY_LOCAL_MACHINE\SOFTWARE\BladeLogic\Operations Manager\Application Server

On a Linux or Solaris Application Server, these JVM settings are located in the $NSHDIR/br/blappserv script.

The Application Server installer prompts you for a max heap setting and it is actually the launcher's heap that is being set there.  Any Application Server instances that are started will inherit the max heap set in the launcher unless the setting is overridden by the instance's configuration.  The Application Server Launcher's heap should be set to 512m.  This means during install or by manually editing the Registry or blappserv file you should set the Launcher heap to 512m.

JVM parameters

The JVM parameters for the Application Server can be set in 'blasadmin' or the Infrastructure Manager interface.  There are two settings to take note of:

• MaxHeap: This is the max heap for the Application Server deployment
• JVMArgs: This lets you pass arbitrary Java arguments to the Application Server JVM, for example to enable 3rd party JMX support or some particular java tuning settings.

For more information about sizing the JVM, see Sizing-and-scalability-considerations.

Heap Size Tunning

Some supplementary and possibly redundant information about the memory tuning found is now discussed.

The general rule of thumb for sizing is that you need a minimum of #MB + (X-factor) of "virtual memory" per Java process running on the box (where # is the max heap size of the process). We have also historically recommended that you have anywhere from .5 x - 1x times the "#MB" in reserve for our JNI code to execute.

I can't tell you what "X-factor" is as it's internal to Java (whatever additional memory Java needs internally to do its stuff).

Now JNI does not apply to the appserver launcher so you don't need to factor that into that process.

So a general rule of thumb would be something along the following lines:

The total memory recommended for a machine running 3 appservers would be:

So if you want to run with a 4GB heap size that would be

So at least 23 gigs of memory to run 3 App Servers at a 4GB heap size.

Notes

Some notes from emails with engineering about WIT, Heap, instances

Our recommendation to customers is 4G Jvm Heap w/ 100 work item threads. This is a more conservative estimate because above 150/200 work item threads we did see some jobs, in particular snapshot and audit where there was thread blocking and contention. We also found that running a high heap is costly in process forking for nsh script jobs so we spent a week in our project hardening and testing the process spawner as usage of this tremendously benefits nsh script jobs. This hardening and quality improvement involved significant changes and could not be back-ported to pre-8.1 product versions. Thus, we felt that the more conservative 4G heap was better in production for now as a recommendation.

We then switched all of our scale lab testing was done against 64bit to use this recommended setting.

Really the benefit of the above 4G would be only realized with the 100 work item threads with memory heavy work item threads such as DISA compliance or a compliance with a lot of rules, and even in those cases 4G would likely be enough. So you benefit more from going with another instance instead of increasing the heap more and scaling the threads horizontally in one app server instance.