Recommendations for Application Servers of type All
This topic offers guidance on appropriate settings for the configuration parameters for a single-purpose BMC Server Automation Application Server (type ALL). This topic includes the following sections:
An Application Server of type ALL is a general-purpose Application Server that provides the combined services of all of the single-purpose Application Servers. The type ALL is the default type if a type is not explicitly chosen at deployment.
To obtain sizing values for Application Servers of type All, you must combine all of the parameter recommendations for the single-purpose servers, usually by adding recommended values for the same parameter for all of the Application Server types. For more information, see the recommendations for the other types of Application Servers:
- Recommendations for Application Servers of type Configuration
- Recommendations for Application Servers of type Job
- Recommendations for Application Servers of type NSH_Proxy
For details about using the blasadmin tool to control the configuration parameters, see Changing the basic Application Server settings.
To monitor the performance of the Java process of your BMC Server Automation Application Server, you can use the BladeLogic JConsole (bljconsole) tool, as described in Using the BladeLogic JConsole to monitor performance of the Application Server.
About Java memory
Effective operation of a large Java system like the BMC Server Automation Application Server depends critically on the availability of sufficient heap memory. This section provides an overview of some considerations for correctly sizing Java memory for BMC Server Automation.
Process space, Java heap, and native heap
A Java process comprises two distinct memory areas: the Java heap and the native heap. Both heaps, together with the Java executable code itself, must fit within the footprint of a single process. Increasing the maximum size of the Java heap necessarily decreases the maximum possible size of the native heap that can fit within a certain process size.
The java heap contains Java objects and accounts for most of the memory required by a running Application Server. The Java heap is managed by the Java garbage collector (GC), and so is sometimes called GC heap.
The native heap (also sometimes called the C heap) contains thread stacks, file handles, and other objects not managed by the Java garbage collector.
If the maximum Java heap size is set too low, it is possible to run out of Java heap memory. If the maximum Java heap size is set too high, it is possible to run out of native heap memory. To complicate matters further, peak memory use for either the Java heap or the native heap depends on the precise workload being considered, as well as timing effects between concurrently operating threads. Therefore, the recommendations that follow are merely that: recommendations, not guarantees or absolute limits.
A process running under any 32-bit operating system is limited to 4 GB of virtual address space, from which the operating system must reserve a significant portion for itself. For example, 32-bit Windows divides the entire address space in half, allowing an application process only 2 GB total private process space. For large Java applications like Application Servers, this process space limit imposes a ceiling on the number of threads that can be accommodated within a single Application Server.
A process running under a 64-bit operating system has access to a much larger virtual address space. Compared to a 32-bit Java process performing equivalent work, a 64-bit Java process also requires a larger Java heap, typically 50% or more larger than the 32-bit Java process. For an example, see http://users.elis.ugent.be/~leeckhou/papers/SPE06.pdf.
Recommended Java heap settings
This section describes recommended Java heap sizes for Application Servers running under different operating systems. These are recommendations only and must be adjusted in light of observed conditions, especially out-of-memory errors.
- For 32-bit processes, BMC recommends operating system-specific Java heap size values according to the table below. Due to memory constraints, job servers using 32-bit processes should be configured to use no more than 50 work item threads.
- For 64-bit processes, BMC recommends that the Java heap size be increased as indicated in the table, if there is sufficient physical memory to support this setting.
The following table provides details about the relevant
Description and Recommendation
Specifies the maximum heap size for this Application Server.
About thread pools
An Application Server maintains several thread pools, each dedicated to a specific purpose. Selecting appropriate sizes for each of the various thread pools is one of the most important configuration choices for an Application Server.
Each thread consumes resources, especially memory, even when idle. Java threads may also consume operating system resources such as thread handles. While executing, a thread consumes even more memory. Regardless of additional performance considerations, available process size limits the number of threads available in an Application Server.
Threads within the same process share certain data structures, especially caches, which are not shared between threads in different processes. Increasing the number of threads within a single process, especially threads within a particular thread pool, has two consequences:
- Serendipity: Because there are more threads contributing to the process-wide caches, any given item request from any thread is more likely to be fulfilled from the cache, because another thread is more likely to have already placed the element in the cache. This phenomenon has a mildly positive effect on overall performance as the number of threads increases.
- Contention: Because some operations on some data structures require exclusive access, as the number of threads increases, there is a greater likelihood of one thread having to wait for another thread's exclusive access to conclude. This effect degrades per-thread performance as the number of threads increases; that is, increasing the number of threads is subject to diminishing returns, sometimes sharply so.
As the number of threads in a process grows, the negative contention effects grow more rapidly than do the positive serendipity effects. Doubling the number of threads in a pool improves performance, but does not double it. Each additional thread provides a smaller and smaller net benefit, while still consuming as much memory and other resources as any other thread.
About database connections
Connections between an Application Server and the database are managed in three connection pools, with each pool devoted to a different purpose. Each connection pool allows the configuration of a minimum and maximum number of connections, although BMC recommends leaving the minimum value at zero for all connection pools.
Configuring a database pool's maximum size to be too high wastes resources, and for large installations, may risk exceeding the total capacity of the database server. You must also ensure that the database server has sufficient capacity to service all the connections from all the connection pools for all the Application Servers in the environment. BMC recommends working with the DBA and database vendor to ensure that you have this capacity, particularly for very large installations.
Conversely, configuring a database pool with a maximum size that is too low can degrade performance, as a thread requesting a database connection from an empty connection pool blocks until a connection becomes available.
For details on estimating data storage requirements for a BMC Server Automation installation, see and the sizing and scalability recommendations in Storage sizing recommendations and also the BMC Server Automation Sizing Guide available from BMC Communities.
Where to go from here
For more information, see the recommendations for the other types of Application Servers: