JVM configuration best practices
When you configure a Java Virtual Machine (JVM) as the application server for Pega 7-based business solutions, how you tune the JVM depends on a variety of factors and changes over time based on advancements in JVM technology.
The number of JVMs needed for a particular business solution depends on the following factors:
- Total number of service requests
- Total number of Decision requests
- Total number of estimated concurrent users
- Total number of estimated concurrent occasional users (percentage of occasional users that might be concurrent during a peak hour)
- Estimated clipboard size
The best practices for JVM configuration are the same for both development and production environments. You might need to re-evaluate the JVM configuration for an application after you deploy the application, complete load testing, and monitor the JVM behavior. Wait to tune your JVM configuration until after you resolve any performance issues and memory bottlenecks in the application.
Remember the following points when configuring a JVM:
- User-based JVMs are configured for response time.
- Agent and batch-based JVMs are configured for throughput.
- The total duration for garbage collection should not exceed 2% of the overall JVM time.
- Isolate the System Management application and Autonomic Event Services on low volume or dedicated JVMs.
This article provides guidance about:
- Pega 7 applications, users, and agent memory
- JVM heap size
- Memory requirements for a requestor Clipboard
- Agent and batch-based JVMs
- Memory for third-party monitoring utilities
In addition, the following articles provide information about the best practices for specifying the JVM configuration options for IBM WebSphere Application Server and Oracle Java HotSpot Virtual Machine:
JVM options for Oracle Java HotSpot Virtual Machine
JVM properties for IBM WebSphere Application Server
Pega 7 applications, users, and agent memory
Consider the following size ranges for memory when planning for JVM configuration.
| Memory size range | Memory component | Notes |
|---|---|---|
500 MB to 1 GB | Pega 7 | Memory used for the Pega 7 engine and applications. This range includes the memory needed for Pega 7 caches (150 MB to 250 MB). |
| 2 GB | JVM native and PermGen memory | JVM native memory includes the following metadata:
The IBM WebSphere Application Server information refers to JVM native memory as native. The Oracle information for Java HotSpot Virtual Machine uses the term PermGen space. |
| Remaining heap memory | Effective user memory | The remaining heap memory is for all concurrent requestors, any background agents that are not high processing, or agents that consume high volumes of memory. |
| Effective agent memory | The typical agent requestor pool size is 10, and the typical agent heap size is 2 GB. However, agent requestor pool size depends on the type and amount of work that is targeted for the agent. Therefore, agent requestor pool size is variable. You can validate memory requirements during load and scale testing. |
JVM heap size
The heap size for a 64-bit JVM might start at 8 GB but can be larger. Larger JVM heap sizes are beneficial in development environments as developers learn to optimize application designs.
Recent IBM and Oracle enhancements to compression reduce the overhead of 64-bit processing, which helps to support the implementation of larger JVM heap sizes. For example, IBM WebSphere Application Server uses compressed references to support compression on heap sizes up to 28 GB. Oracle Java HotSpot Virtual Machine uses compressed ordinary object pointers and supports compression for heap sizes up to 32 GB.
In addition, because memory is inexpensive, cost is not a factor that prevents organizations from deploying sufficient amounts of memory for application servers.
The following table provides an example of the heap size that is required for an estimated number of concurrent developers. In this example, assume that the size of the developer Clipboard is 50 MB. The expected clipboard size determines how many users can reside in a JVM heap. After factoring in 10 percent overhead for 64-bit processing, you can calculate the estimated number of concurrent users by dividing the target heap size by the expected clipboard size.
| JVM heap size | Heap size minus 10% overhead for 64-bit processing | Estimated number of concurrent users (90%) |
|---|---|---|
| 8 GB | 7.2 GB | 130 |
| 12 GB | 10.8 GB | 194 |
| 16 GB | 14.4 GB | 259 |
Estimating memory requirements for a requestor Clipboard
When you plan for JVM configuration, consider the memory requirements for both the developer and production user clipboards.
A clipboard is a hierarchically structured, temporary Java object used to hold and name property values for a user session. The clipboard data structure is called a page. Pages can contain embedded pages that can also contain embedded pages.
To estimate the memory footprint for an application, use the following methods:
| Clipboard type | Available methods |
|---|---|
| For the developer Clipboard, multiply the clipboard size by the peak number of concurrent users. |
|
| For a production user Clipboard, multiply the clipboard size by the peak number of users. |
|
Agent and batch-based JVMs
For both IBM WebSphere Application Server and Oracle Java HotSpot Virtual Machine, a best practice is to deploy background agents and batch processing on their own JVM. Using a dedicated JVM ensures that users and agents do not compete for memory and CPU time. You can identify the optimum ratio of agents per JVM during load and scale testing for the transition phase of a project.
Memory for third-party monitoring utilities
Third-party monitoring utilities run with the application in every JVM. These monitoring utilities are deployed within the user and agent effective memory. If the third-party monitoring utility is configured correctly, memory usage is negligible.
Previous topic How to use SMA to identify amount of data on requestor clipboards Next topic JVM options for Oracle Java HotSpot Virtual Machine